This is a good discussion of these principles. Largely inspired by Emacs, I built an interpreted lisp which runs in a web server and stores the AST Postgres. It gives me this kind of malleable computing and a Lispy feel with very little overhead.
Instead of calling an API, agents can just use functions in a REPL. They can also write new views and improve the program if they run into an issue. Honestly, pretty amazing stuff.
Being able to design a program specifically for the workflow I want is pretty neat. There's some vibeslop jank, but Emacs is a little bit jank too.
JavaScript did this for the Web back in the day. I work on a malleable git-compatible SCM right now. First I put all the performance-critical parts into a native lib, then happily built my own git(hub) in JavaScript. Tastes differ, someone else may build it completely differently. I believe this is the right architecture for the LLM age.
2.0 fixes a ton of stuff over 1.0, but yeah you're not wrong.
Between custom keybinds, hot strings, and pop-up menus I have literally hundreds of tiny AHK scripts running 24/7. I'm pretty sure there's stuff I've literally forgotten is an AHK vs an actual part of Windows. It's all just ingrained in my muscle memory at this point.
Out of curiosity, are you now or have you ever been a "Mac person"? I'm curious if you've ever gone down the rabbit hole on Apple's history of technologies for what I think you'd call "malleable computing" at the OS level, like Open Scripting Architecture/AppleScript and now App Intents?
Short answer, yes I am a Mac guy. AFAIK, both AppleScript and Shortcuts/Intents are mechanisms Apple has provided to support orchestration between apps. I do not consider them “malleable computing” mechanisms as they do not allow for adapting and reshaping the apps themselves. That said, AppleScript and Shortcuts are only as useful as the support given to them by 3rd party apps, which IMHO has always been mid.
There’s an interesting middle ground: not fully malleable software, where the end user has full customisation ability but requires full programming skill, but eg the Unix tool model where prebuilt utilities can be composed with a simple syntax.
Pre-existing (or importable) ELisp functions are kinda similar, just a slightly higher level of user skill.
Useless without local/remote sync. Also kind of obvious is the preferability of composeable UNIX programs over heavily locked down monoliths, hardly calling for a Fred Brooks style exegesis.
NGL, whenever I work with Cocoa APIs, I wistfully think of another timeline where we get a system-level SmallTalk style REPL and ecosystem accessing all of it.
I genuinely do wonder why that has been the trajectory. When you look at the almost futuristic vision of interacting with living, programmable software objects and environments that evolve over time and you get a glimpse of it in Emacs, Pharo or Oberon (worth mentioning Free Oberon, fun to play around with https://free.oberon.org/en/ think it was on the frontpage recently), how did we go back to dead text files again?
I always have to think the "the world if" meme when I think about what would have happened if the whole Engelbart, Licklider, Alan Kay school of thought had won out
> I genuinely do wonder why that has been the trajectory.
The simple answer here is still likely the best one: Smalltalk and Lisp Machine systems were expensive and proprietary right at the same time that Unix and C became free (and therefore ran everywhere)
We never went away from it. It's how a significant amount of computer use has always been. Smalltalk, Oberon, Lisp Machines (mentioned by sibling), they were always minority systems.
There was a brief time when maybe home computers could have leaned this way, but that lasted until VisiCalc. What sold computers was software that turned them from clay to be molded by the user into a defined tool. People prefer appliances (or were convinced to prefer appliances), and appliances make more money for businesses than distributing programs as a Smalltalk package would have.
Instead of calling an API, agents can just use functions in a REPL. They can also write new views and improve the program if they run into an issue. Honestly, pretty amazing stuff.
Being able to design a program specifically for the workflow I want is pretty neat. There's some vibeslop jank, but Emacs is a little bit jank too.
https://github.com/gritzko/beagle
Between custom keybinds, hot strings, and pop-up menus I have literally hundreds of tiny AHK scripts running 24/7. I'm pretty sure there's stuff I've literally forgotten is an AHK vs an actual part of Windows. It's all just ingrained in my muscle memory at this point.
Amazing how much value you got with 400 LoC (even though it's relying on multiple libraries).
Pre-existing (or importable) ELisp functions are kinda similar, just a slightly higher level of user skill.
https://github.com/magit/forge
Nice article.
I always have to think the "the world if" meme when I think about what would have happened if the whole Engelbart, Licklider, Alan Kay school of thought had won out
The simple answer here is still likely the best one: Smalltalk and Lisp Machine systems were expensive and proprietary right at the same time that Unix and C became free (and therefore ran everywhere)
Even with commercial UNIXes, it was extra on top of standard UNIX developer SKU.
Same with Ada, by the way.
We never went away from it. It's how a significant amount of computer use has always been. Smalltalk, Oberon, Lisp Machines (mentioned by sibling), they were always minority systems.
There was a brief time when maybe home computers could have leaned this way, but that lasted until VisiCalc. What sold computers was software that turned them from clay to be molded by the user into a defined tool. People prefer appliances (or were convinced to prefer appliances), and appliances make more money for businesses than distributing programs as a Smalltalk package would have.