> 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 thi

> 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.