It would’ve been helpful if the author showed some examples of the stunting that bootstrapping results in. Pattern-matching, for example, is useful in all kinds of places that aren’t just compilers.
I really want to agree with this article in a sort of general “Yeah! Fuck those PLT wonks! Up with the working dev!” way, but I just can’t see how to get there from here.
As we discussed on IRC, my main issue with the article (hereby shared with the wider community) is that complete absence of supportive data for the frankly quite bold claim. However, I also would like to criticize the notion of any “stunting” taking place at all, since we couldn’t find any example of such.
I felt the same way; I was interested by the beginning, but when your only example of bad design resulting from bootstrapping is pattern matching, which more and more languages are adding these days due to programmer demand…
The main argument in the OP is that compilers are not exactly “standard programs”, since they lack interactivity.
This talk talks about how modern compilers are actually quite the opposite, because of the high demand for IDE tooling.
You need some sort of incremental compiling, caching of parse results, etc. This is highly interactive (even a bit concurrent, due to how computers + a lot of file watches can turn out). So compilers (designed modernly) are actually a great example of a “typical program”.
An aside, but despite us knowing theoretically how to design good compilers for a while, we’re still super bad at it. Lots of leaky abstractions are present in big languages. Scala’s compiler was so bad it was deemed beyond redemption and a complete rewrite is happening instead.
So I disregard the premise and the conclusion! We don’t write good compilers, generally, and compilers are actually great examples of interactive programs when done “right”.
Interesting point. I feel that you would be able to test this by looking at popular self hosting languages and compare the robustness and strength of their parsing / lexing tools to other general purpose libraries.
It would’ve been helpful if the author showed some examples of the stunting that bootstrapping results in. Pattern-matching, for example, is useful in all kinds of places that aren’t just compilers.
I really want to agree with this article in a sort of general “Yeah! Fuck those PLT wonks! Up with the working dev!” way, but I just can’t see how to get there from here.
As we discussed on IRC, my main issue with the article (hereby shared with the wider community) is that complete absence of supportive data for the frankly quite bold claim. However, I also would like to criticize the notion of any “stunting” taking place at all, since we couldn’t find any example of such.
I felt the same way; I was interested by the beginning, but when your only example of bad design resulting from bootstrapping is pattern matching, which more and more languages are adding these days due to programmer demand…
A counterpoint: https://news.ycombinator.com/item?id=11685317
The main argument in the OP is that compilers are not exactly “standard programs”, since they lack interactivity.
This talk talks about how modern compilers are actually quite the opposite, because of the high demand for IDE tooling. You need some sort of incremental compiling, caching of parse results, etc. This is highly interactive (even a bit concurrent, due to how computers + a lot of file watches can turn out). So compilers (designed modernly) are actually a great example of a “typical program”.
An aside, but despite us knowing theoretically how to design good compilers for a while, we’re still super bad at it. Lots of leaky abstractions are present in big languages. Scala’s compiler was so bad it was deemed beyond redemption and a complete rewrite is happening instead.
So I disregard the premise and the conclusion! We don’t write good compilers, generally, and compilers are actually great examples of interactive programs when done “right”.
Interesting point. I feel that you would be able to test this by looking at popular self hosting languages and compare the robustness and strength of their parsing / lexing tools to other general purpose libraries.