4 ms·

> Dart, despite being a from-scratch, relatively modern language, ended up with three implementations (host AOT compiler, host IDE compiler (dart-analyzer), on-

> Dart, despite being a from-scratch, relatively modern language, ended up with three implementations (host AOT compiler, host IDE compiler (dart-analyzer), on-device JIT compiler). We also had an earlier analyzer written in Java that was mostly discarded and rewritten as well as two compilers to JavaScript that share less code than you would expect. Some of the redundancy is because, as the author correctly states, the needs of an IDE are quite different from the needs of a batch compiler. Likewise, an ahead-of-time whole program compiler has different constraints from a JIT compiler running a program from source. But a lot of the redundancy in Dart's case is incidental. We have a fairly large, distributed team with a lot of autonomy and sometimes that led to people doing their own thing instead of putting in the effort into coordinating and sharing more code. Also, the language changed radically from Dart 1.0 to 2.0. 1.0 was a dynamically typed scripting language designed to be run from source in a native VM directly embedded in a browser with a separate optional type system mostly used at dev time. Dart 2.0 is a fully statically-typed language with a more typical compilation process. That monumental change led to some duplication and technical debt that we are slowly paying down by sharing more and more of the front end over time. The path I see most new languages take is: 1. Start with a command-line batch mode compiler. 2. Eventually get popular enough that users clamor for real IDE support. 3. Cobble together an IDE plug-in based on the batch-mode compiler's front end. 4. Discover that the latency is horrific and slowly and painfully realize you need to write a new front end architected for IDE use. 5. Now you have two front ends. I believe the throughput loss of a front-end designed for interactive IDE use is less than people realize. So I suspect that a more efficient path for any new language is to design your front end for interactive IDE use from day one.

matklad 5y ago
> So I suspect that a more efficient path for any new language is to design your front end for interactive IDE use from day one. Maybe! One problem is that this is going to be harder than starting with a batch compiler: you might not get to 2. due to the lack of resources. Another plausible trajectory is the following: 1. you start with a non-self hosting batch compiler, whose explicit goals are simplicity, language-designer iteration speed, and short time horizon, and which has deliberately minimal capabilities when it comes to error messages and other user-facing niceties. 2. using this bootstrap compiler, get to the 1.0 of the language. 3. implement a second, self hosting compiler with a long-term focus, interactive capabilities and all that stuff. 4. either discontinue bootstrap compiler, or explicitly support it as a minimal implementation for the purposes of differential fuzzing and specification.

matklad 5y ago

> So I suspect that a more efficient path for any new language is to design your front end for interactive IDE use from day one. Maybe! One problem is that this is going to be harder than starting with a batch compiler: you might not get to 2. due to the lack of resources. Another plausible trajectory is the following: 1. you start with a non-self hosting batch compiler, whose explicit goals are simplicity, language-designer iteration speed, and short time horizon, and which has deliberately minimal capabilities when it comes to error messages and other user-facing niceties. 2. using this bootstrap compiler, get to the 1.0 of the language. 3. implement a second, self hosting compiler with a long-term focus, interactive capabilities and all that stuff. 4. either discontinue bootstrap compiler, or explicitly support it as a minimal implementation for the purposes of differential fuzzing and specification.