[HN Gopher] How Should Compilers Explain Problems to Developers?...
___________________________________________________________________
How Should Compilers Explain Problems to Developers? (2018) [pdf]
Author : zdw
Score : 39 points
Date : 2023-03-26 21:28 UTC (1 days ago)
(HTM) web link (static.barik.net)
(TXT) w3m dump (static.barik.net)
| WalterBright wrote:
| The most useful advance in error messages is that advent of spell
| checkers for undefined symbols. The one I wrote used the existing
| symbol table as the dictionary. It works so well (and is so
| simple) it evokes the "why didn't I do that decades ago!"
| thought.
| effnorwood wrote:
| [dead]
| TRiG_Ireland wrote:
| Languages do vary. PHP has some oddities, but its error messages
| mostly make good sense. It's much easier to debug than, for
| example, javascript.
| kccqzy wrote:
| I suppose the oddities you mention include
| T_PAAMAYIM_NEKUDOTAYIM
| ChancyChance wrote:
| I think RQ3 is interesting. It is the only proposition in the
| paper that references crowd-sourcing. I find that interesting
| because that immediately lends itself to ... god i hate myself
| ... ChatGPT. We've been asking GPT to write code, but has anyone
| asked it to debug code?
| 1-more wrote:
| I like what I see in the comparison table between Jikes and
| OpenJDK. Elm does a lot of this in its error messages, including
| hinting at possible typos in field names. What this lacks is a
| suggested next action for the developer.
| DesiLurker wrote:
| explaining the compiler error messages should really be the first
| application of LLMs like GPT-4. in fact you can take all the
| knowledge crap out and just train it on programming info from gcc
| source code/tests & StackOverflow/GitHub. thereafter have it
| explain what went wrong. This would be especially useful if you
| are dealing with template instances and the user explains in a
| few sentances what they are trying to achieve.
|
| I have multi-decade experience in coding C/C++ but its shameful
| how much time still gets wasted on these stupid compiler errors.
| mhh__ wrote:
| Or just fix the error message and add a hyperlink to an
| explanation...
|
| You don't need an AI you just need the right abstractions in
| the code.
|
| The AI could help you learn if you really don't understand but
| for just telling you what went wrong you don't need it. In fact
| the compiler can already fix a lot of these things for you if
| they bothered to implement it (see fixit in clang)
| chrsig wrote:
| Having a link to a detailed explanation would be amazing.
| Trying to even find the error message in a sea of c++
| template notes is challenging...Then trying to actually parse
| it while examining the types is...painful.
| remkop22 wrote:
| Exactly. Compiler developers wrote the logic for the errors
| you see, they (mostly) have the knowledge to explain the
| error, why do we need a language model trained on all this
| derived information, when it could be provided upfront
| together with context from your own source code.
| mpd wrote:
| Having good error messages is one of the important priorities for
| me in my compiler, so I made the commitment early and am using
| codespan_reporting[0] to report the errors, which is going well
| so far.
|
| 0: https://github.com/brendanzab/codespan
| jimwhite42 wrote:
| I thought this paper was very interesting on the topic: "Mind
| Your Language: On Novices' Interactions with Error Messages".
|
| One of the things that comes up, is that if the error message
| suggests a change, one of the risks is that such an edit can make
| the error go away, but the code will not be correct. By making a
| concrete suggestion, it tempts the programmer to just apply it
| without thinking.
|
| This is really interesting to me because it makes sense, and goes
| against many common ideas about how to make good error messages.
| hyperrail wrote:
| > _if the error message suggests a change, one of the risks is
| that such an edit can make the error go away, but the code will
| not be correct. [...]_
|
| "Error messages: diagnostic is preferable to prescriptive" [1]
| is a riff on a similar theme, though the author of that blog
| post is focusing on error messages for Microsoft's C# compiler,
| which are more likely to be intended for experienced
| professional developers, so he is coming at the problem from a
| different perspective than the student-focused one of the paper
| you mentioned.
|
| [1]
| https://web.archive.org/web/20060720004516/http://blogs.msdn...
| nuancebydefault wrote:
| Today I was again amazed by the simplistic-ness of the
| description of a linking failure by a c++ compiler/linker. It was
| complaining about an undefined reference without stating where
| said reference resided. Compiler makers must hate us developers
| or think we are intelligent enough to have enough with just half
| a word.
| tester756 wrote:
| >Compiler makers must hate us developers
|
| I think that C or C++ were just written by people who never
| gave a single damn about UX until competition appeared and then
| things started improving,
| marginalia_nu wrote:
| The abysmal compile time for these languages may also have
| encouraged this fairly bare-bones UX philosophy.
| tester756 wrote:
| >fairly bare-bones UX philosophy.
|
| What do you mean?
| marcosdumay wrote:
| C was created by people that didn't have any extra resource
| to spend on UX. Just another day there was an article here
| about emulating the computer C was written for in a RP2040
| (the Raspbery Pi "competitor" for the Arduino), and yes, it
| has plenty of space for that.
|
| C++ had more of a choice about it.
| tester756 wrote:
| >C was created by people that didn't have any extra
| resource to spend on UX
|
| How many years have passed since that time?
| marcosdumay wrote:
| Oh, enough to improve things several times (to answer, 5
| decades). People did some improvements, but clearly
| didn't keep-up with the times (and degraded some things
| too, UB being the elephant in the room).
|
| But large things almost never keep-up with the times.
| nuancebydefault wrote:
| Something else must be playing here and I'm pretty sure
| most of the annoyences did not get solved, mostly because
| of backward compatability guarantees. It is really a
| pitty that c/c++ did not get pushed away by competing
| languages that do/did not have so much of a legacy of
| sub-par development tooling. Friendlier and better
| designed languages like C#, Rust or even Python still
| seem to have some disadvantages that prevented that from
| happening.
| JonChesterfield wrote:
| C++ essentially killed C. Counterexamples exist but
| they're hard to find and sometimes involve there being no
| C++ compiler on the target.
|
| D didn't replace C++. I wonder if that was related to the
| single proprietary implementation. The language seems
| more sensible to me.
|
| Rust is aimed at replacing C and C++. There are others in
| the same field in various stages of development. Zig and
| carbon come to mind.
|
| There's an uphill battle where lots of existing code is
| in C++ and people fear changing it. C was partly
| dismantled by C++ compilers promising better error
| diagnostics and being able to compile most C with minimal
| patching.
|
| I personally think the end is in sight for C++ but the
| consensus seems to be it'll live forever.
| WalterBright wrote:
| D is 100% Boost licensed.
| mhh__ wrote:
| (GC)C isn't that old, and in fact was part of a generation
| of tools that shunned ye olde' "line too long" type errors
| WalterBright wrote:
| I discovered back in the early 80's that it was easier to
| allocate bigger buffers than to have "line too long"
| messages and recovery.
| throw10920 wrote:
| > C was created by people that didn't have any extra
| resource to spend on UX
|
| This is irrelevant. The design of a language has little
| bearing on the quality of the error messages from any
| particular implementation. In particular, the constraints
| on C implementations in the '70s is irrelevant to
| constraints on implementations in 2023. There's absolutely
| nothing preventing the GCC/LLVM/ICC/MSVC developers from
| adding better error messages to their compilers, and the
| design of the language _certainly_ isn 't one.
| WalterBright wrote:
| > The design of a language has little bearing on the
| quality of the error messages
|
| Actually, it has a lot to do with it.
|
| https://www.digitalmars.com/articles/b47.html
| mhh__ wrote:
| In general, the linker is written by people different to the
| people who write the compiler.
|
| I don't hate you I just don't control the whole stack.
|
| Also linkers can tell you where the symbol was referenced if
| that place has a location in the code. This isn't universal but
| it's practically always been there for me.
| nuancebydefault wrote:
| Thanks for not hating me :p
|
| What i also find hard to understand is that generally linkers
| are "single pass" i.e. you need to feed them objects and libs
| in the correct order (callers prior to callees) for them to
| solve all links. Not sure if this requirement still is always
| there.
| WalterBright wrote:
| I've written linkers. This one pass thing was gone before
| the 1980s.
| JonChesterfield wrote:
| That requirement vhas been gone for decades if it ever
| existed, though static library semantics look a bit like
| that if you don't pass extra flags around them.
|
| Linkers are multiple pass if doing compiler optimisation
| things. Otherwise they're pretty close to cat + patch some
| pieces, single pass seems fair.
|
| It's not immediately obvious to me why linkers don't say
| which functions were making the undefined symbol call. A
| suspicion is that the linker may not know what the function
| name is for the corresponding instruction without digging
| it out of the debug info and the linker probably doesn't
| have the corresponding parser ready to hand. It probably
| could narrow it down to a source object file, though
| libraries make that difficult.
___________________________________________________________________
(page generated 2023-03-27 23:01 UTC)