Rendered at 18:53:44 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
sroerick 21 hours ago [-]
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.
dharmatech 14 hours ago [-]
This sounds so cool!
Do you have this shared somewhere?
frumiousirc 8 hours ago [-]
> For Markdown to Org translation, Pandoc will be used.
Hmm, pandoc? Surely....
M-x org-import-<TAB>
Damn, why does this family of functions not yet exist?
gritzko 21 hours ago [-]
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.
Great 'scratch my own itch' story and I like the framing of Emacs and Elisp as Malleable Software.
kickingvegas 20 hours ago [-]
OP here. Happy to answer any questions about my post in this thread.
AloysB 18 hours ago [-]
Great article, TIL vtable.
Amazing how much value you got with 400 LoC (even though it's relying on multiple libraries).
kickingvegas 14 hours ago [-]
Seeing how much functionality I could get from just 400 LoC was one of the motivations for writing this post.
tgbugs 4 hours ago [-]
Did you look into the existing org-sync package? I know the use case is slightly different but I think it still works.
kickingvegas 3 hours ago [-]
Wasn't aware of org-sync until now. That said for my use case I still would not use it as I didn't want to setup another GH authentication token for another client. YMMV.
tgbugs 3 hours ago [-]
Definitely understandable, the proliferation of api creds and ways of passing them in is a major pain point.
CharlesW 17 hours ago [-]
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?
kickingvegas 15 hours ago [-]
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.
gnabgib 17 hours ago [-]
If you're into malleable computing you'd never have been a "Mac person"
empthought 16 hours ago [-]
Yeah, NeXTSTEP is notoriously a locked-down, untweakable OS. It's not like anyone was able to use it to program anything of consequence.
DonHopkins 4 hours ago [-]
I had an argument with Steve Jobs about pie menus at the Educom conference in Washington DC, October 26 1988 -- right after he finally shipped NeXTSTEP (people had been teasing it as vaporware with "NeVRSTEP" t-shirts).
I was demonstrating the work I'd done at the UMD Human Computer Interaction Lab on a color Sun 3/60 that Sun lent me to use at their booth, which happened to be right across from the NeXT booth.
Ben Shneiderman dragged Steve Jobs over to the Sun booth, and I gave him a NeWS demo for about half an hour: HyperTIES, UniPress Emacs, pie menus, PostScript windows in arbitrary shapes — the Hubble Space Telescope in orbit, Bill Joy's head popping up when you pointed at it, that kind of thing. Jobs has RELIGION about UI, and he argued wonderfully. He also has volume. On the show floor, in a suit and tie, he was jumping up and down yelling:
"That sucks! That sucks! Wow, that's neat! That sucks!"
Not discouraged, I figured one neat to three sucks was a good score from Steve Jobs. When I explained how flexible NeWS was -- programmable PostScript in the window system, malleable windows, extensible UI, transforming all menus of all apps into pie menus, etc -- he told me:
"I don't need flexibility -- I got my window system right the first time!"
Okay, agree to disagree. Then I gave him a free NeWS "NeRD" button, which he gracefully accepted, then he departed leaving my reality intact and undistorted.
So empthought's joke isn't far from the design philosophy. NeXT was world-class software, but malleability for the user was exactly what Jobs was proud of not offering. That's a big part of why the Emacs / NeWS / PostScript / Smalltalk / Self / Oberon / JavaScript / AJAX branch of computing and the Mac / NeXT / Display PostScript / Objective C / Cocoa branch diverged.
Also, during the conference I was giving essentially the same rolling demos to anyone who walked by, and some scruffy looking dude was hanging out and watched the whole series until it looped back to Emacs, then he finally remarked "I used to use EMACS on ITS." (i.e. the original TECO version)
...I said "Wow, what was your user name? Mine was A2DEH@AI!" and he replied "WNJ".
Only then did I realize I had been giving demos to Bill Joy, the author of VI, of UniPress Emacs for NeWS, and of HyperTIES embedded graphical pop-up links demo with his own inflatable pop-up head. I didn't recognize him because he'd shaved his beard!
How was OSA/AppleScript not an OS-level malleable computing layer?
SoftTalker 16 hours ago [-]
I don't know first hand of anyone who ever used it for anything. Maybe I knew the wrong Mac users (mostly teachers).
DonHopkins 4 hours ago [-]
Re CharlesW: OSA was an OS-level malleable-computing layer, on paper. Apple Events exposed scriptable objects; OSA let multiple scripting dialects share the same runtime. The gap was who actually shipped working product.
Dave Winer's Frontier (UserTalk) is the piece these threads usually skip. Frontier 1.0 shipped in January 1992 -- the same month Apple finally held its one-day scripting developer conference, after years of canceling and restarting AppleScript.
UserTalk wasn't bolted on. It was registered as an OSA dialect: Script Editor, HyperCard, Nisus ("Do Script"), and other OSA hosts could run UserTalk, not only Frontier.
What made it malleable in practice: syntax is an outline (code and data are the same tree); object DB + interpreter + outliner in one app; and one of the most complete Apple Events client/server stacks on the Mac -- I used Frontier and Radio Userland to automate other apps heavily, often before their AppleScript dictionaries caught up.
So yes: OSA/AppleScript was malleable computing at the OS layer if you count UserTalk and HyperCard and scriptable apps, not only Apple's English-like syntax. AppleScript won the namespace; that doesn't mean nobody used the layer. SoftTalker's teachers weren't the crowd wiring Finder, FileMaker, HyperCard, and CGI with UserTalk.
Later the same core powered Manila, Radio Userland, RSS, OPML, XML-RPC. Short timeline:
I've posted about this at length before on HN — ThinkTank, MORE, UserTalk, Apple Events, Radio Userland, the whole outline-as-language lineage. Two long ones:
The thing that's missing from "Google Docs" is a decent collaborative outliner called "Google Trees", that does to "NLS" and "Frontier" what "Google Sheets" did to "VisiCalc" and "Excel".
And I don't mean "Google Wave", I mean a truly collaborative extensible visually programmable spreadsheet-like outliner with expressions, constraints, absolute and relative xpath-like addressing, and scripting like Google Sheets, but with a tree instead of a grid. That eats drinks scripts and shits JSON and XML or any other structured data.
Dave Winer ... originally developed a wonderful outliner on the Mac originally called "ThinkTank" and then "MORE", which later evolved into the "Frontier" programming language, and ultimately the "Radio Free Userland" desktop blogging and RSS syndication tool.
More was great because it had a well designed user interface and feature set with fluid "fahrvergnügen" that made it really easy to use with the keyboard as well as the mouse.
After the success of MORE, he went on to develop a scripting language whose syntax (for both code and data) was an outline. Kind of like Lisp with open/close triangles instead of parens! It had one of the most comprehensive implementation of Apple Events client and server support of any Mac application, and was really useful for automating other Mac apps, earlier and in many ways better than AppleScript.
Then XML came along, and he integrated support for XML into the outliner and programming language, and used Frontier to build "Aretha", "Manila", and "Radio Userland".
He used Frontier to build a fully programmable blogging and podcasting platform, with a dynamic HTTP server, a static HTML generator, structured XML editing, RSS publication and syndication, XML-RPC client and server, OPML import and export, and much more.
Excerpts from the second (26217472):
I was a "random turist" high school kid visiting the AI lab on a pilgrimage. That was when I first met Hugh Daniel: this energetic excited big hairy hippie guy in a Xanadu baseball cap with wings, who I worked with later, hacking NeWS. Hugh and I worked together for two different companies porting NeWS to the Mac.
The fact that Xanadu didn't have a built-in extension language was a disappointment, since extensibility was an essential ingredient to the success of Emacs, HyperCard, Director, and the World Wide Web.
Anyway, my take on all this hyper-crap is that it's useless without a good scripting language. I think that's why Emacs was so successful, why HyperCard was so important, what made NeWS so interesting, why HyperLook was so powerful, why Director has been so successful, how it's possible for you to read this discussion board served by Frontier, and what made the World Wide Web what it is today: they all had extension languages built into them.
If you're into malleable computing and you've never looked at outline-as-language systems (Frontier/UserTalk, MORE, later outliner-programming ideas), you're missing half the Mac story — the half that shipped before AppleScript stabilized.
4 hours ago [-]
WillAdams 7 hours ago [-]
This sort of thing is why the terminal commands pbpaste and pbcopy in NeXTstep/Mac OS X as well as Services are so powerful.
That said, I wonder what the successor to emacs looks like (or what the next generation of it will improve).
__d 21 hours ago [-]
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.
miki123211 12 hours ago [-]
Another approach to this is "build mechanism, not policy" (also of Unix philosophy fame).
Encapsulate the hard parts in libraries, ship the topmost layer as codegen templates that depend on those libraries, and let agents / devs modify that topmost layer to their heart's content. This often beats putting everything in libraries and having to expose customization points everywhere.
This is the approach taken by the Shadcn UI library (which became popular just as agents entered the scene), but it generalizes far beyond UI.
jolmg 4 hours ago [-]
> Another approach to this is "build mechanism, not policy" (also of Unix philosophy fame).
Might be more recognized from the X Window System design principles rather:
> Provide mechanism rather than policy. In particular, place user interface policy in the clients' hands.
It wasn't part of the original Unix philosophy, but I see that went through several revisions.
cfiggers 20 hours ago [-]
AutoHotkey adds a malleable computing layer to Windows.
paulryanrogers 19 hours ago [-]
Meh, it's better than nothing. Though not a great interface or DSL.
cfiggers 18 hours ago [-]
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.
miki123211 12 hours ago [-]
Hammerspoon (Mac) is much better. It's basically Lua, with access to all the MacOS automation APIs.
maleldil 6 hours ago [-]
Hammerspoon is amazing, and LLMs are very good at writing configuration for it. I'm quite happy with my config.
beepbooptheory 19 hours ago [-]
This is nice but not even a mention of the rather robust existing solution here with Magit Forge?
Yet another one rediscovers the way Lisp machines, Smalltalk, Cedar and Oberon were envisioned, and we never really got it in mainstream computing.
Nice article.
kickingvegas 19 hours ago [-]
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.
pjmlp 12 hours ago [-]
In a way this is what Powershell offers in Windows.
On Mac using something like PyObjC, maybe coupled with Xonsh, could do the trick.
bitwize 9 hours ago [-]
This is pretty much what COM is under Windows.
Barrin92 18 hours ago [-]
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
scroot 16 hours ago [-]
> 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)
pjmlp 15 hours ago [-]
Yes, and porting them on top of UNIX wasn't the same thing, while still being commercial.
Even with commercial UNIXes, it was extra on top of standard UNIX developer SKU.
Same with Ada, by the way.
Jtsummers 16 hours ago [-]
> how did we go back to dead text files again?
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.
miki123211 12 hours ago [-]
The Smalltalk approach doesn't really integrate well with anything else.
If you treat data and code the same, it's hard to separate code from data. If you're writing a program for a single machine on which it should be used, that's fine, but if you want to write your code once and run it across many machines, that's a problem.
ERP systems are a bit like this; system owners (businesses) are often able to change any part of the system they want. Predictably, this makes version upgrades an incredible pain and often locks companies into an unsupported proprietary fork of a 20-year-old version of their CRM.
pjmlp 10 hours ago [-]
There are image distribution ways, and already on the 1990's there was image based SCM products.
Most of those ERP systems are a pain, because all those changes where spread across several contractors, each doing their own little silo while keeping everything else running.
SaaS products are basically the Smalltalk approach, and they aren't going away, in fact they are doubling down with iPaaS and AI agentic tooling.
In such business domains, classical backend coding is almost gone, what is left are serverless, microservices, many of which are slowly being exposed as MCP tools.
klibertp 6 hours ago [-]
> The Smalltalk approach doesn't really integrate well with anything else.
That's not true. GToolkit (built on Pharo Smalltalk) integrates tightly with Git for VCS and Rust via FFI for external libraries. It integrates with external Python and JavaScript through IPC. The same IPC mechanism is used to work around the GIL (the same way Python used to do with the multiprocessing library).
Squeak descendants are also not the only Smalltalks available. Smalltalk/X is polyglot, supports Java and C code inline, and has a native AOT compiler (through C). Smalltalk/X and VisualWorks have built-in version control, namespaces, and packages with visibility modifiers.
TL;DR: a live Smalltalk environment doesn't have to be an isolated island. The most popular open-source Smalltalks come from education and hobbyist coding, so they tend to miss a lot of "programming in the large" conveniences, but that's just a historical accident. There's no technical reason why a Smalltalk that's integrated into a wider ecosystem and suited for large teams couldn't exist.
jake_and_fatman 18 hours ago [-]
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.
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.
Hmm, pandoc? Surely....
Damn, why does this family of functions not yet exist?https://github.com/gritzko/beagle
Amazing how much value you got with 400 LoC (even though it's relying on multiple libraries).
I was demonstrating the work I'd done at the UMD Human Computer Interaction Lab on a color Sun 3/60 that Sun lent me to use at their booth, which happened to be right across from the NeXT booth.
Ben Shneiderman dragged Steve Jobs over to the Sun booth, and I gave him a NeWS demo for about half an hour: HyperTIES, UniPress Emacs, pie menus, PostScript windows in arbitrary shapes — the Hubble Space Telescope in orbit, Bill Joy's head popping up when you pointed at it, that kind of thing. Jobs has RELIGION about UI, and he argued wonderfully. He also has volume. On the show floor, in a suit and tie, he was jumping up and down yelling:
"That sucks! That sucks! Wow, that's neat! That sucks!"
Not discouraged, I figured one neat to three sucks was a good score from Steve Jobs. When I explained how flexible NeWS was -- programmable PostScript in the window system, malleable windows, extensible UI, transforming all menus of all apps into pie menus, etc -- he told me:
"I don't need flexibility -- I got my window system right the first time!"
Okay, agree to disagree. Then I gave him a free NeWS "NeRD" button, which he gracefully accepted, then he departed leaving my reality intact and undistorted.
So empthought's joke isn't far from the design philosophy. NeXT was world-class software, but malleability for the user was exactly what Jobs was proud of not offering. That's a big part of why the Emacs / NeWS / PostScript / Smalltalk / Self / Oberon / JavaScript / AJAX branch of computing and the Mac / NeXT / Display PostScript / Objective C / Cocoa branch diverged.
More context from that week:
https://news.ycombinator.com/item?id=17098824
Also, during the conference I was giving essentially the same rolling demos to anyone who walked by, and some scruffy looking dude was hanging out and watched the whole series until it looped back to Emacs, then he finally remarked "I used to use EMACS on ITS." (i.e. the original TECO version)
...I said "Wow, what was your user name? Mine was A2DEH@AI!" and he replied "WNJ".
Only then did I realize I had been giving demos to Bill Joy, the author of VI, of UniPress Emacs for NeWS, and of HyperTIES embedded graphical pop-up links demo with his own inflatable pop-up head. I didn't recognize him because he'd shaved his beard!
HyperTIES founders storyboard: https://donhopkins.com/home/ties/emacs/founders.st0
Bill Joy's Head Target: https://donhopkins.com/home/ties/emacs/obj/founder.curly.tn0
NeWS PostScript pop-up target class: https://donhopkins.com/home/ties/target.ps
At least it wasn't RMS, who would have immediately objected strongly to the "Evil Software Hoarder" version of Emacs I was using.
Here are some examples of not-locked-down NeWS user interfaces:
HCIL Demo - HyperTIES Browsing:
https://www.youtube.com/watch?v=fZi4gUjaGAM
HCIL Demo - HyperTIES Authoring with UniPress Emacs on NeWS:
https://www.youtube.com/watch?v=hhmU2B79EDU
Just the Pie Menus from All the Widgets:
https://www.youtube.com/watch?v=mOLS9I_tdKE
Ben Shneiderman, Don Hopkins, and pie menus in Spring 1989 on a Sun Workstation, running NeWS:
https://www.youtube.com/watch?v=8Fne3j7cWzg
Nelson Spins Pip While Emacs Watches:
https://www.youtube.com/watch?v=aRaD5zH3Qdg
(Oops that was a different Emacs, my cat.)
Dave Winer's Frontier (UserTalk) is the piece these threads usually skip. Frontier 1.0 shipped in January 1992 -- the same month Apple finally held its one-day scripting developer conference, after years of canceling and restarting AppleScript.
Winer's history:
http://scripting.com/dwiner/historyOfFrontier.html
UserTalk wasn't bolted on. It was registered as an OSA dialect: Script Editor, HyperCard, Nisus ("Do Script"), and other OSA hosts could run UserTalk, not only Frontier.
Manual:
http://scripting.com/frontier/manual/chapter01.html
UserTalk as OSA dialect:
https://sbc.apeth.com/frontierDef/ch34.html
What made it malleable in practice: syntax is an outline (code and data are the same tree); object DB + interpreter + outliner in one app; and one of the most complete Apple Events client/server stacks on the Mac -- I used Frontier and Radio Userland to automate other apps heavily, often before their AppleScript dictionaries caught up.
So yes: OSA/AppleScript was malleable computing at the OS layer if you count UserTalk and HyperCard and scriptable apps, not only Apple's English-like syntax. AppleScript won the namespace; that doesn't mean nobody used the layer. SoftTalker's teachers weren't the crowd wiring Finder, FileMaker, HyperCard, and CGI with UserTalk.
Later the same core powered Manila, Radio Userland, RSS, OPML, XML-RPC. Short timeline:
https://eclecticlight.co/2025/02/22/a-brief-history-of-scrip...
I've posted about this at length before on HN — ThinkTank, MORE, UserTalk, Apple Events, Radio Userland, the whole outline-as-language lineage. Two long ones:
https://news.ycombinator.com/item?id=30871497
(on Excel / visual data models — why we still need "Google Trees", and how Frontier got there from MORE)
https://news.ycombinator.com/item?id=26217472
(on Xanadu open source, Hugh Daniel in the winged cap, and why hypertext without a scripting language is hyper-crap)
Index post linking several of these threads:
https://news.ycombinator.com/item?id=21170434
Excerpts from the first (30871497):
The thing that's missing from "Google Docs" is a decent collaborative outliner called "Google Trees", that does to "NLS" and "Frontier" what "Google Sheets" did to "VisiCalc" and "Excel".
And I don't mean "Google Wave", I mean a truly collaborative extensible visually programmable spreadsheet-like outliner with expressions, constraints, absolute and relative xpath-like addressing, and scripting like Google Sheets, but with a tree instead of a grid. That eats drinks scripts and shits JSON and XML or any other structured data.
Dave Winer ... originally developed a wonderful outliner on the Mac originally called "ThinkTank" and then "MORE", which later evolved into the "Frontier" programming language, and ultimately the "Radio Free Userland" desktop blogging and RSS syndication tool.
More was great because it had a well designed user interface and feature set with fluid "fahrvergnügen" that made it really easy to use with the keyboard as well as the mouse.
After the success of MORE, he went on to develop a scripting language whose syntax (for both code and data) was an outline. Kind of like Lisp with open/close triangles instead of parens! It had one of the most comprehensive implementation of Apple Events client and server support of any Mac application, and was really useful for automating other Mac apps, earlier and in many ways better than AppleScript.
Then XML came along, and he integrated support for XML into the outliner and programming language, and used Frontier to build "Aretha", "Manila", and "Radio Userland".
He used Frontier to build a fully programmable blogging and podcasting platform, with a dynamic HTTP server, a static HTML generator, structured XML editing, RSS publication and syndication, XML-RPC client and server, OPML import and export, and much more.
Excerpts from the second (26217472):
I was a "random turist" high school kid visiting the AI lab on a pilgrimage. That was when I first met Hugh Daniel: this energetic excited big hairy hippie guy in a Xanadu baseball cap with wings, who I worked with later, hacking NeWS. Hugh and I worked together for two different companies porting NeWS to the Mac.
The fact that Xanadu didn't have a built-in extension language was a disappointment, since extensibility was an essential ingredient to the success of Emacs, HyperCard, Director, and the World Wide Web.
Anyway, my take on all this hyper-crap is that it's useless without a good scripting language. I think that's why Emacs was so successful, why HyperCard was so important, what made NeWS so interesting, why HyperLook was so powerful, why Director has been so successful, how it's possible for you to read this discussion board served by Frontier, and what made the World Wide Web what it is today: they all had extension languages built into them.
If you're into malleable computing and you've never looked at outline-as-language systems (Frontier/UserTalk, MORE, later outliner-programming ideas), you're missing half the Mac story — the half that shipped before AppleScript stabilized.
That said, I wonder what the successor to emacs looks like (or what the next generation of it will improve).
Pre-existing (or importable) ELisp functions are kinda similar, just a slightly higher level of user skill.
Encapsulate the hard parts in libraries, ship the topmost layer as codegen templates that depend on those libraries, and let agents / devs modify that topmost layer to their heart's content. This often beats putting everything in libraries and having to expose customization points everywhere.
This is the approach taken by the Shadcn UI library (which became popular just as agents entered the scene), but it generalizes far beyond UI.
Might be more recognized from the X Window System design principles rather:
> Provide mechanism rather than policy. In particular, place user interface policy in the clients' hands.
https://en.wikipedia.org/wiki/X_Window_System_protocols_and_...
It wasn't part of the original Unix philosophy, but I see that went through several revisions.
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.
https://github.com/magit/forge
Nice article.
On Mac using something like PyObjC, maybe coupled with Xonsh, could do the trick.
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.
If you treat data and code the same, it's hard to separate code from data. If you're writing a program for a single machine on which it should be used, that's fine, but if you want to write your code once and run it across many machines, that's a problem.
ERP systems are a bit like this; system owners (businesses) are often able to change any part of the system they want. Predictably, this makes version upgrades an incredible pain and often locks companies into an unsupported proprietary fork of a 20-year-old version of their CRM.
Most of those ERP systems are a pain, because all those changes where spread across several contractors, each doing their own little silo while keeping everything else running.
SaaS products are basically the Smalltalk approach, and they aren't going away, in fact they are doubling down with iPaaS and AI agentic tooling.
In such business domains, classical backend coding is almost gone, what is left are serverless, microservices, many of which are slowly being exposed as MCP tools.
That's not true. GToolkit (built on Pharo Smalltalk) integrates tightly with Git for VCS and Rust via FFI for external libraries. It integrates with external Python and JavaScript through IPC. The same IPC mechanism is used to work around the GIL (the same way Python used to do with the multiprocessing library).
Squeak descendants are also not the only Smalltalks available. Smalltalk/X is polyglot, supports Java and C code inline, and has a native AOT compiler (through C). Smalltalk/X and VisualWorks have built-in version control, namespaces, and packages with visibility modifiers.
TL;DR: a live Smalltalk environment doesn't have to be an isolated island. The most popular open-source Smalltalks come from education and hobbyist coding, so they tend to miss a lot of "programming in the large" conveniences, but that's just a historical accident. There's no technical reason why a Smalltalk that's integrated into a wider ecosystem and suited for large teams couldn't exist.