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.
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.
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.
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.
I'm preparing a talk on malleable software for a product management audience, and I've noticed just how hard of a concept it is to grasp outside of engineering.
Us engineers are used to the tools we use being flexible. It's only as we need tooling to be palatable to other audiences they become more constrained. For non technical people, malleable may as well mean complicated.
We're going to see this change, but breaking this concept out of engineering is an uphill battle.
16 comments
[ 2.3 ms ] story [ 27.3 ms ] threadInstead 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.
Pre-existing (or importable) ELisp functions are kinda similar, just a slightly higher level of user skill.
https://github.com/gritzko/beagle
Nice article.
https://github.com/magit/forge
Hmm, pandoc? Surely....
Damn, why does this family of functions not yet exist?That said, I wonder what the successor to emacs looks like (or what the next generation of it will improve).
Us engineers are used to the tools we use being flexible. It's only as we need tooling to be palatable to other audiences they become more constrained. For non technical people, malleable may as well mean complicated.
We're going to see this change, but breaking this concept out of engineering is an uphill battle.