Hacker News new | past | comments | ask | show | jobs | submit login

> 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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: