4 ms·

You're talking about C++ issues here. Those are very specific to C++. No other languages besides C/C++ have such a broken import and dependency mechanism. No o

You're talking about C++ issues here. Those are very specific to C++. No other languages besides C/C++ have such a broken import and dependency mechanism. No other language than C++ has such broken "macros" like the template mechanism. Also I was explicitly talking about advanced type systems. C/C++ have a very shallow and simple type system. But OTOH C/C++ have the most advanced optimizers. So the whole picture gets quite bended when looking at it form that perspective. Scala for example has an IR called TASTy which can be stored along the compile artifacts. It's the AST after type checking (Typed Abstract Syntax Tree). Recompiling form that is very fast as it's (almost) only the relatively cheep code gen step. Also incremental compilation works differently for a lot of languages because those languages have small and independent compilation units. The situation in C/C++ is again a very specific mess as there are really no modules (until now). Usually you don't need to potentially recompile the world on every code change. > Features like "style sheets" for code are just linter and auto formatter config files. No, they aren't. If I "change the style of my code" the actual code gets changed! In case I would change the style sheet used for rendering only a local config value would get switched. The "binary code" on disc would stay exactly the same. (Still I could than have "Python with braces" after the switch if this is what I prefer to look at). > It may be useful to reuse the compiler internals for this, but in practice every tooling author eventually learns not to do that. Everybody involved in the "LSP revolution" would disagree, I think. The whole point of LSPs is to reuse the already existing tools (usually the compiler) built by the language devs.

duped 4y ago
I'm not talking about C++ at all! My entire point is that caching is hard and tightly coupled to the design of the language, and things like typechecking are not really that slow compared to the other work a compiler has to do. Choosing an in memory representation is not really a secret recipe for performance or utility, designing the way the cache gets updated and what it stores is. I think the idea of a core language with multiple syntaxes is interesting, but I'd contest that the system to implement it is any faster. > Everybody involved in the "LSP revolution" would disagree, I think. I reached this conclusion after writing a language server and researching other language servers. The tide is changing to where the primary compilers for languages are query-oriented compilers like Roslyn that allow for this kind of thing, but they aren't nearly as common as batch compilers so language server authors find themselves writing everything from scratch. Interestingly though, big portions like type checkers can be reused if they have stable input/output IRs because they're not slow (however, compiler authors are loathe to expose those details or make stability guarantees there).

duped 4y ago

I'm not talking about C++ at all! My entire point is that caching is hard and tightly coupled to the design of the language, and things like typechecking are not really that slow compared to the other work a compiler has to do. Choosing an in memory representation is not really a secret recipe for performance or utility, designing the way the cache gets updated and what it stores is. I think the idea of a core language with multiple syntaxes is interesting, but I'd contest that the system to implement it is any faster. > Everybody involved in the "LSP revolution" would disagree, I think. I reached this conclusion after writing a language server and researching other language servers. The tide is changing to where the primary compilers for languages are query-oriented compilers like Roslyn that allow for this kind of thing, but they aren't nearly as common as batch compilers so language server authors find themselves writing everything from scratch. Interestingly though, big portions like type checkers can be reused if they have stable input/output IRs because they're not slow (however, compiler authors are loathe to expose those details or make stability guarantees there).