Potential of a compiler that creates the executable at once

rempas rempas at tutanota.com
Thu Feb 10 11:24:23 UTC 2022


On Thursday, 10 February 2022 at 10:38:05 UTC, Araq wrote:
>
>
> It's a very bad idea, it's in fact so bad that I wouldn't call 
> it a "design":
>
> - Since everything is recompiled all the time regardless, there 
> is no incentive for "modularity" in the language design. Nor is 
> there any incentive to keep the compiler's internals clean. 
> Soon everything in the compiler operates on an enormous mutable 
> graph internally, encouraging many, many bugs.
> - You'll likely run into memory management problems too as you 
> cannot free memory  as everything is connected to everything 
> else. Even if you are willing to use a GC the GC cannot help 
> you much as your liveset simply keeps growing.
> - Every compiler bugfix tends to add code to a compiler, so 
> it'll get slower over time.
> - The same is true for the memory consumption, it'll get worse 
> over time.
> - Every optimization you add to the compiler must not destroy 
> your lovely compile-times. So everything in the compiler is 
> speed-critical and has to be optimized. Almost anything you do 
> ends up being on the critical path.
> - This does not only affect optimizations (which can depend on 
> algorithms that are O(n^3) btw) but also all sorts of linting 
> phases. And static analysis gets more important over time too.
>
> In summary: People expect optimizers and static analysis to get 
> better too and demand more of their tools. Your "design" 
> doesn't allow for this. And in an IDE setting you might be able 
> to skip all the expensive optimization steps, but not the 
> static analyser steps.

Thank you for your reply! I suppose you are right and I'm glad I 
asked people with more experience than me. It would be fun to 
hear more negative thoughts to see all the things that I'm 
missing.


More information about the Digitalmars-d mailing list