How Should Compilers Explain Problems to Developers? (2018) [pdf]
static.barik.net
static.barik.net
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.
"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...
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.
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.
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.
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,
What do you mean?
C++ had more of a choice about it.
How many years have passed since that time?
But large things almost never keep-up with the times.
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.
D wasn't Boost licensed when I looked at it as a replacement for C++ about a decade ago. Wiki thinks the backend has been available since 2017. It looks like the source may have been available for longer than that but I missed the distinction between source available and open source if it was. That's how I ended up on the C++ path instead of the D one anyway, seems a credible risk others have the same experience.
We couldn't get the dmd backend open sourced until 2017, but everything else was open sourced.
As the office Rust shill, I'm actually pretty excited about a lot of Herb Sutter's work [1]; I think there's a reasonable argument to be made that a hypothetical C++29 will be as ergonomic as unsafe Rust, with the not inconsiderable benefit of being able to speak the C++ ABI. I don't think large projects like LLVM or Unreal would dream of rewriting to Rust in that time, so people will still be writing it in some form or another.
[1]: My top 3 would probably be cppfront's argument passing semantics, metaclasses, and deferred_heap, in that order. The latter two, IMO, are improvements on what Rust provides in the area.
But Rust brings you OOP-like structures without the C++ hidden machinery, generics (the two main reason people adopted C++), and a lot of code verification. And the language isn't much more complex than C. That combination is very enticing.
I do believe both languages are about to die (C and C++). It's just that when languages die, nobody notices for a decade or so. Even develovers keep getting more numerous for some time, and have their numbers slowly reduce through decades.
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.
Actually, it has a lot to do with it.
It's interesting that your specifically call out that putting source lines in is not good when most modern compilers seem to be moving the other direction and putting them in.
Do you think it could be a preference thing? Would it be good to have the option for the user to turn it on?
Also, thanks for the tip on the spell checker. That is something I'll add. You said they your just used the current symbol table as a dictionary in another comment; that is a great idea too.
I have multi-decade experience in coding C/C++ but its shameful how much time still gets wasted on these stupid compiler errors.
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)
"rustc error messages not only describe the error in the code, but for certain error patterns, suggest edits that may fix the problem. However, these edits are always local and don’t provide any high-level design feedback which may be helpful in making the mindshift."
In my experience, that thought is a bright neon sign telling you that you have a potentially killer product on your hands.