TechTakes

This author touches on a point that dovetails with my thinking:

Dijkstra, in “On the foolishness of ‘natural language programming’,” wrote, rather poignantly: “We have to challenge the assumptions that natural languages would simplify work.” And: “The virtue of formal texts is that their manipulation, in order to be legitimate, need to satisfy only a few simple rules; they are, when you come to think of it, an amazingly effective tool for ruling out all sorts of nonsense that, when we use our native tongues, are almost impossible to avoid.”

I think it likely that these tools will not be judged, in the long term, by the ambitions and hopes of the AGI cultists and hype-men, but by comparison to the many other attempts at natural-language programming in English. Smalltalk, Visual Basic, I even want to throw in AppleScript, as simple and threadbare as it was. How are all of these doing now?

AppleScript has been complemented or perhaps superseded by at least two more graphically-oriented attempts at system automation targeted at non-technical users. One could argue that its falloff came from an imperfect marriage with the message-passing/service-oriented architecture based on Objective-C and inherited from NeXT in Mac OS X, a system design which is itself now vestigial. The comparison with LLM coding assistants is imperfect, as they seem to be typically targeted at the more granular level of the class or the method, rather than explicit high-level hooks in an application. A better comparison here would be the last year or so worth of "AI agents," but, uhm, ahh...

Smalltalk seemed to have a pretty big boom in the late 80s/early 90s, but tapered off rapidly after that. I like the more modern implementation of Pharo well enough, but it strives to throw in everything and the kitchen sink, with a downright balk-worthy amount of packages listed when you open up the class browser. On top of that, a few weeks ago I noticed someone in their Discord telling a newbie that current good practice is to file out your code every once in a while and then start over with a fresh image, as various background processes in stock images typically become unstable over time. This is orthogonal to the natural-language-like design, but it is a stumbling block to the sense of "liveness" and interactivity that is similarly a big hook for LLM assistance. Furthermore, as far as I know, they still don't have a stable answer for system-level parallelism in the VM. All I've seen is a rather awkward technique for spinning off tree-shaken child VMs if there's some method you want to run in parallel. You've got to really love Smalltalk to want to work past that shortcoming!

VB.NET I can't really speak to, except that it seems Microsoft now considers it a stable language with little if any new feature development. The original implementation never seemed to have a good rep for maintainability, and the very idea of native Forms seems out of fashion compared to JavaScript web-app frontends. And the land of JavaScript, of course, seems to be the most fertile and uncontested kingdom of LLM coding assistance. I'm genuinely interested to hear more experiences with modern VB, as it strikes me as the last great corporate-sanctioned push for non-technical users to build their own apps, and thus the most worthy comparison.

All this is to say that each of these previous attempts at natural-language programming haven't bit-rotted too hard, implementations are still available and you can probably salvage a legacy project with some effort. But each of them have been sidelined by industry over time. Not necessarily because of Dijkstra's objection to the ambition of approaching natural language, although I don't think we can totally discount that as a factor. But other technical or platform restrictions certainly hamstrung each of them. And LLM tools are still mostly API-based SaaS, which always has the glaring technical vulnerability of the provider running out of money. Yes, people will still pursue local models, but the bubble bursting could do a lot more harm to this approach than proponents anticipate.