secondary impact is structured editing, and maybe it's helping code reading by human brains.
secondary impact is structured editing, and maybe it's helping code reading by human brains.
But does it actually have that impact? Being able to represent language constructs within the language doesn’t seem to have much to do with the textual syntax that humans use to input those constructs. Or perhaps you meant it in the sense that when introducing new constructs for humans to use (and not just generating code programmatically), it’s easier to make their syntax “blend in” with existing syntax if there isn’t much of the latter.
> and maybe it's helping code reading by human brains.
Empirically, I’m not convinced that it’s the case.
IME, at least a weak of full-time dedication is needed, with a suitable editor and config, to start grasping this.
there's a large threshold on the way just to configure emacs and structured editing of lisp, in a powerful environment like slime. and only then comes the language itself.
nowadays it could be less, though, with tutorial videos and LLMs to set it up.
Everyone should be using an IR like C# source generators. It's a lot faster to process, more stable and more intuitive because it maps closer to the language semantics instead of surface level syntax. And then you don't need a simple syntax at all.
anything that transforms the source code in a lossy way is an obstacle to that.