> Because, as smart as we compiler designers think we are, you, dear programmer, know your program better than we do.
When you compile a file successfully, make an edit, then compilation fails, are there any compilers/IDEs that compare the before-and-after of the file to create better error messages? The compiler would have a lot of extra information this way because files usually change gradually and not all at once.
I'm thinking of cases where you're refactoring some code but miss out a bracket, the compiler says the missing bracket could be anywhere down the bottom of the whole file but anyone watching intuitively knows what block of code the missing bracket likely falls into, usually localised around what you just edited.
> elsif say_goodbye nd we_like_this_person:
> If the compiler tried to automatically add a colon, I’d have two colons and the code is even wronger.
Couldn't a smarter compiler guess that because "we_like_this_person" and "say_goodbye" are defined variables and there's no variables similar looking to "nd", that "nd" should probably be the "and" keyword?
I'm surprised by how unhelpful error messages still are for most tools. I'm curious how much this is because it's a very hard problem rather than it's a neglected area that developers accept as normal. I heard Elm is meant to be good here (where strong static typing allows for certain kinds of hints): https://elm-lang.org/news/compiler-errors-for-humans
> because files usually change gradually and not all at once.
As a counterexample, suppose you are checking out a new version of a file, or a new branch with many changes across many files. Identifying this usage would require the compiler to be aware of the version control system, and still wouldn't correctly identify that the version sent from $COWORKER via email for some weird reason isn't a gradual change.
For me personally, debugging is difficult enough without needing to worry that the compiler is going to maintain state across multiple runs. If I see an error message that is different at all, I assume that means I'm triggering a different failure mode, and debug accordingly.
Edit: That said, the Rust compiler is tremendous with error messages, without relying on time-dependent state. If a variable is misspelled, it will look for similarly named variables that are in scope, and ask if you meant one of them. But this behavior is still consistent for a given file and compiler version.
> For me personally, debugging is difficult enough without needing to worry that the compiler is going to maintain state across multiple runs.
Ooh, the idea makes me shudder.
I remember looking at a project's makefile which called a custom build script where the README said to run the buildscript twice-- once to generate some state, and a second time to compile stuff using that state.
Without any comments provided, the makefile called the custom buildscript three times in a row.
I can't even imagine the superstition and cargo culting that would arise from an IDE "helping out" by analyzing who has changed what, when, and in what order they changed it.
Please paste a new empty function named "momo" here before doing a release. Also make sure your blinds are closed before compiling.
Couldn't you just gate the comparison with compiler flags and define corresponding make targets? Flags could also identify the VCS and how the old file should be obtained.
> unhelpful error messages still are for most tools.
One thing that winds me up is error messages that tell you that some string can't be parsed or a file can't be read but they don't show you the string or the file path.
This is especially irritating for the actual end user because they generally do not have the opportunity, or knowledge, to run the program in a debugger or to examine the source code.
When you compile a file successfully, make an edit, then compilation fails, are there any compilers/IDEs that compare the before-and-after of the file to create better error messages? The compiler would have a lot of extra information this way because files usually change gradually and not all at once.
I'm thinking of cases where you're refactoring some code but miss out a bracket, the compiler says the missing bracket could be anywhere down the bottom of the whole file but anyone watching intuitively knows what block of code the missing bracket likely falls into, usually localised around what you just edited.
> elsif say_goodbye nd we_like_this_person:
> If the compiler tried to automatically add a colon, I’d have two colons and the code is even wronger.
Couldn't a smarter compiler guess that because "we_like_this_person" and "say_goodbye" are defined variables and there's no variables similar looking to "nd", that "nd" should probably be the "and" keyword?
I'm surprised by how unhelpful error messages still are for most tools. I'm curious how much this is because it's a very hard problem rather than it's a neglected area that developers accept as normal. I heard Elm is meant to be good here (where strong static typing allows for certain kinds of hints): https://elm-lang.org/news/compiler-errors-for-humans