Both guests are very well-spoken when explaining why they made various choices about their languages. I appreciate this; it’s not common enough in the ALGOL-ish space. In particular, their comments on the nature of text and textual encodings are deep and well-informed. Set aside a couple hours and give it a listen!
I was a little surprised that Bill carried the (incorrect) meme that obfuscation works in practice. I would expect folks spending lots of time with low-level gadgets to know better, but that’s how memes work.
They spend a bit of time on semantic compression (squeezing concepts into small strings) but not much time on the structure of compressors; they talk about ASTs but not about tree homomorphisms. This might be an instance of a common blind spot for compiler engineers: surely a compiler is just another data-transformation pipeline? But it is more rigid than that, and a homomorphic approach would help them with their handwaving. It’s fascinating to hear three different well-evidenced opinions about what an AST is and whether it’s a useful structure for end users.
We need to stop re-parsing modules. As Bill correctly points out, an AST should be valid on its own by the fact that it was constructible in memory; this suggests that our current workflow is wasteful, requiring us to maintain a separate document on-disk which textually represents the AST in a human-readable fashion and to re-parse that document whenever it is altered. I know that LSP servers are a partial solution to this, and so are structural editors, but I’d like to hear a more hopeful outlook instead of the promise of yet another tree of C++-flavored fancy documents.
Best quote comes from Bill:
Programmers will put up with a lot of crap.
Yes. So will compiler engineers and language designers.
“Works”? It happens, but it doesn’t mean it is good by any stretch. And I am not sure where you got that from the discussion.
…tree homomorphisms
I did extremely briefly without discussing that term, but I also didn’t want to bog down into graph theory when neither the audience nor neither of my guests may not know much of either. No point in alienating either groups (pun intended) just to “sound technical”.
We need to stop re-parsing modules.
The funny thing is, parsing is rarely the bottleneck. The point I was trying to get across is that text has many degenerate states and getting rid of that degeneracy solves a bunch of other problems. And that the compiler has a lot of semantic information that we rarely have access to. LSP kind of do this, but LSPs (as both a concept and their current implementations) have a bunch of other problems which I won’t get into right now.
Ah, sorry, I must have misinterpreted your comments on obfuscation. I apologize for the misunderstanding.
I agree with you that the audience isn’t really open to hearing about homomorphisms. My gripe isn’t really about you, but about compiler engineering on a broader level. For some reason, entire portions of discrete mathematics are considered off-limits, and that includes any recognition that a type of trees might have an associated category of tree homomorphisms. It made the resulting discussion sound somewhat antiquated to me, particularly as folks attempted to explain how visual and textual languages might exchange graphs of code.
Both guests are very well-spoken when explaining why they made various choices about their languages. I appreciate this; it’s not common enough in the ALGOL-ish space. In particular, their comments on the nature of text and textual encodings are deep and well-informed. Set aside a couple hours and give it a listen!
I was a little surprised that Bill carried the (incorrect) meme that obfuscation works in practice. I would expect folks spending lots of time with low-level gadgets to know better, but that’s how memes work.
They spend a bit of time on semantic compression (squeezing concepts into small strings) but not much time on the structure of compressors; they talk about ASTs but not about tree homomorphisms. This might be an instance of a common blind spot for compiler engineers: surely a compiler is just another data-transformation pipeline? But it is more rigid than that, and a homomorphic approach would help them with their handwaving. It’s fascinating to hear three different well-evidenced opinions about what an AST is and whether it’s a useful structure for end users.
We need to stop re-parsing modules. As Bill correctly points out, an AST should be valid on its own by the fact that it was constructible in memory; this suggests that our current workflow is wasteful, requiring us to maintain a separate document on-disk which textually represents the AST in a human-readable fashion and to re-parse that document whenever it is altered. I know that LSP servers are a partial solution to this, and so are structural editors, but I’d like to hear a more hopeful outlook instead of the promise of yet another tree of C++-flavored fancy documents.
Best quote comes from Bill:
Yes. So will compiler engineers and language designers.
“Works”? It happens, but it doesn’t mean it is good by any stretch. And I am not sure where you got that from the discussion.
I did extremely briefly without discussing that term, but I also didn’t want to bog down into graph theory when neither the audience nor neither of my guests may not know much of either. No point in alienating either groups (pun intended) just to “sound technical”.
The funny thing is, parsing is rarely the bottleneck. The point I was trying to get across is that text has many degenerate states and getting rid of that degeneracy solves a bunch of other problems. And that the compiler has a lot of semantic information that we rarely have access to. LSP kind of do this, but LSPs (as both a concept and their current implementations) have a bunch of other problems which I won’t get into right now.
Ah, sorry, I must have misinterpreted your comments on obfuscation. I apologize for the misunderstanding.
I agree with you that the audience isn’t really open to hearing about homomorphisms. My gripe isn’t really about you, but about compiler engineering on a broader level. For some reason, entire portions of discrete mathematics are considered off-limits, and that includes any recognition that a type of trees might have an associated category of tree homomorphisms. It made the resulting discussion sound somewhat antiquated to me, particularly as folks attempted to explain how visual and textual languages might exchange graphs of code.