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