I made a language design some years ago. More recently, I had Claude carry out some of the implementation to see if it would work. It did not. I tried again, hand-tailoring the IRs and many of the main algorithms, and it did better but the self-hosting compiler still violates many of the design principles and even behaviors in the design document. I have spent six months of free time reviewing and fixing it myself, and it's just a small pet project. I would not open-source that code any time soon.

I must imagine Mojo is in the same situation.

But this change did more than break things. It meant people using Elm in production had to abandon it, nearly immediately, as all future work would first require them to port the whole stack, in one fell swoop, to Elm (and this was before tail recursion modulo cons was implemented, but recursion was forced).

Imagine if, in Rust's infancy, it decided to remove the C FFI with the argument that people should instead, naturally, rewrite that code in Rust. What would have happened? People would have abandoned it in droves, and it would have been essentially relegated to a research language, never again suited for prime time.

And -- oh, look what happened to Elm!

Hooking up to and generating calls across filesystem APIs cost multiple orders of magnitude more than calling `ls`. These tooling ideas are interesting, though. Maybe Kenneth_E._Iverson was right all along?

Talking to another senior dev over drinks tonight, we both worried not about our work but about who might come up never having written a single line of code. Never even opened a terminal. Is looking at the code something you learn in semester 5?

I think computer science education is going to stomp onward, poorly. And we will get that generation. And things like "terminal tooling is going out of style" won't even be said any more. Hacker groups will turn from discussions about new ideas to talking about doing leetcode without AI.

Our art died because we used our art to kill it. We are the last human masters.

That's a funny thing to think about.

Greg Egan is far more interesting and spares you that.

Optimizing well-known jumps is useful, as is branch reordering, but the tombstone flag is unnecessary; you can simply write down a list of all targeted / called blocks and perform dead block elimination more generally that way.