Maybe not the language choice, but the codegen of this compiler is terrible because of the single-pass shortcuts (for example, it unconditionally loads the result of all assignment operations back to the stack just in case you want to write `a = b = 1`, even though 99% of the time that load is immediately thrown away.)
> that doesn't take seconds to compile a single long-ish expression with floating point arithmetic
Or some complex Combine chains just hang forever and not compile at all with no indication what the problem is. Yet they keep adding language features that clearly the compiler can't deal with.
I agree with you on all points, but the parent sounded like he was relying on the compile-time checks to determine correctness. I was making the point that that is a bad idea.
I suppose this is one of those things where people’s experiences vary widely, but FWIW after 20 years of writing C/C++, I can count the number of times this has bitten me on one finger. And even then, I still think it was more likely just an optimizer bug in the god-awful compiler.
Especially if you compile without optimisations. The optimisations can introduce bugs (although most of the times are related to undefined behaviour in the code), but without it is rare…
I guess another problem would be that people often complain about how slow these kinds of compilers can be, and if you keep around enough to reconstruct good error messages it would probably make it that much slower.
The problem with the compiler is that it implements a language whose rules, applied to the code I just wrote, yield a bug. That this language is consistent with the spec makes it no less a problem.
Yep. Hearing that solution to the problem was just beyond reason. Its like they didn't just set some compile flags and constants for the architecture, but decided that their code had to calculate it every time the variable is needed. The line about finding if /dev/null moved was also pretty scary.
reply