[Jtsummers]

(NB: Not a criticism of interpreted languages, they add a lot of value)

While long compilation times are incredibly annoying, compilation offers a first pass test on code: Is this code syntactically correct? Do (at least some of) the semantics make sense?

With an interpreted language, you may be able to test for syntactic correctness with a simple scan over the language, but you're approaching compilation at that point. More likely, syntactic correctness is verified by a test suite that's sufficient to provide 100% code coverage (which can be hard to build and maintain).

It's also harder to know if a reference to foo is valid at any point, until it's executed. Which is where the semantic validity and verification of compilation comes in handy. A tool which can do this for your interpreted language is most of the way to being a compiler, it's simply lacking the translation step.

The nice thing with interpreted languages is that you could put off a lot of this verification/validation, similar to the distinction between dynamic and static typing, until you actually need it. The debate is when you need it and how much value is added by putting it at the start. But languages like go and incremental compilation being adopted by more compiler/toolchain developers is at least cutting down on the time to reduce the time spent idling (as a developer) in the feedback loop.

[lordCarbonFiber]

Yeah, I laugh every time someone says interpreted languages remove the "compile time" step. Once you decide to start working at scale you have to come back and hack in all the static checks the compiler would have given you for free and in my experience those tend to be 10x slower. I know running the python linter + test suite on our basic enterprise CRUD takes longer than all but the biggest C++ projects I've ever seen.