Post #1407440

@shriramk @jschuster @lindsey @krismicinski@types.pl @jfdm @csgordon @jeremysiek why is it a foolish position, though? (Serious question: I'm not trying to be either obtuse or confrontational). Most people don't look at the object code in an executable binary, and even most programmers have no working knowledge of an assembly language or machine's instruction set at this point. This is something I was just thinking about while walking over to the corner store. Consider my ham radio example: I consider that a pretty impressive accomplishment, despite all the deficiencies I mentioned earlier. And while I don't think it's possible right now, it is _conceivable_ that at some point in the future, I may be able pop up one of these things and say, "rewrite the Linux kernel in Rust" and it would make a passable go at doing so. But then it struck me, what would be the point? If the premise is that the machine is going to be able to write better code than I can, perhaps not now, but at some point in the future, then what does it matter what notation it uses to do so? The value-adds of Rust, the borrow checker and so on, are there to help human programmers. But if the machine gets good enough to work around our inability to reason about thorny concurrency issues, memory, and type safety, UB, etc, in C, and it does a better job than me _anyway_, then there's no reason to convert it to a language that's optimized for humans. Maybe that's just a big matrix of numbers; meaningful to it, but not to most of the rest of us, just as object code is not meaningful to most of us. Surely the best course of action is to settle on something that's optimized _for the LLM_. Almost all extant programming languages seem to be optimized for the _programmer_ (not you, APL). Perhaps this is similar to what you were referring to when you mentioned the source and intermediate languages?