Plan 9's Acme: The Un-Terminal and Text-Based GUIs
30 points by runxiyu
30 points by runxiyu
Modern GUIs tend to each be created from scratch and are designed to operate hermetically. But treating every application like its own blank slate and creating every user interaction from scratch has the effect, in aggregate, of making modern computers overwhelming to use.
With text as the dominant mode of communication, behavioral patterns have emerged across programs, making the second terminal program easier to learn that the first and scaling from there.
It's true, sad, and absurd. This is exactly what core GUI principles were supposed to solve by comparison to a CLI. And they did, but we've abandoned them. It's a miracle the File menu still comes before Edit, when an app deigns to include them.
I remember when I realised this would happen.
I was at Microsoft TechEd back in 2004-ish, and the speaker was demonstrating Avalon, with XML based UI markup. I asked him, "With the rise of XAML, what will replace the Windows UX Guidelines and ensure standard look and feel across Windows apps?"
His response was "We expect the community will drive those standards", and it was at that point I realised the platform was irrevocably fucked.
There's also the tension of uniformity vs. "branding".
Google's Material Design started out as the great unifier, and both Google and Android third parties were pissed that all apps looked like they're part of Google Workspace Suite. At version 3 they're now aiming for some "branding, but aware of standards and user preferences" panacea.
Branding was much less a concern in early Windows: I suppose companies were happy that they don't have to deal with support requests for "where's the button for X?" because it's all the same, but that only stuck that long…
My hope is that the new iPad notes (with handwriting detection and live interaction) will inspire Apple to throw out a standard for at least cross-app data interfaces on the Apple platform. We can even call it MCP if we've got to ride the AI wave.
There are a few of those in place: AppleScript, services, Mach ports, capability-oriented daemon processes, Automator, and Shortcuts come to mind on macOS; app intents and app extensions on iPhone/iPad.
What the delayed agentic Siri was supposed to use is App Intents. So the tool standard is there but they're not about to open up tool calling before they offer an out of the box agent.
The Russ Cox screencast on Acme that the author linked is definitely worth a watch.
I'm not giving up my syntax highlighting or my VS Code plugins anytime soon. But around the time Russ was explaining how existing text could automatically be made into hyperlinks, and using that to jump back and forth between error messages in the terminal and the guilty lines of code… I was nodding my head and thinking, yeah, I can see why you'd port all that Plan 9 stuff for this.
[…] treating every application like its own blank slate and creating every user interaction from scratch has the effect, in aggregate, of making modern computers overwhelming to use. […] Terminal-based programs don’t suffer from this.
I don't really agree with this evaluation. Yes, the fixed width grids of terminals have a lower fidelity than arbitrary amounts of pixels, but there's still a lot of different options there. Between code page 850, Unicode, emoji or even (*sigh*) "Nerd fonts", there's a lot of graphical tidbits to sprinkle around your textual output. There were early DOS/VT100 screens where you couldn't really depend much on colors or unusual characters. There were later developments like Turbo Vision that almost emulated contemporary pixel-based GUIs. There are VMS or IBM's 3270-based mainframe terminal applications.
And heck, even if we're not going with arbitrary cursor-addressed TUI applications and "just" streamed output, there's a lot of room between ultra-minimalistic early Unix output (where "?" is an error message) and the current Rust/JS meow-tastic rainbow-flavored output you get for even basic build tools.
You really have to narrow it down to have some kind of uniform standard. ISPF, Turbo Vision, sure. But then you're at the same point as a proper pixel-based GUI, with Human Interface Guidelines. Not the current genealogy of web-based and -influenced UIs.
And on a (almost) totally different note, when looking at Acme it's always interesting to compare it to predecessors like Oberon or even Smalltalk. The former looks a lot like Acme, but here the connecting tissue isn't files (or file systems), but functions and modules.
I thought the appeal of TUIs was
TUIs aren’t standardized at all.
https://en.wikipedia.org/wiki/IBM_Common_User_Access started out for TUI, and translated over to GUI quite seamlessly.
The heavy use of iconography makes the uphill climb all that much steeper. Terminal-based programs don’t suffer from this.
I have to disagree with this statement, because TUIs commonly offer even less than icon buttons: they offer no buttons at all, and you have to use almost undiscoverable keyboard shortcuts instead.
https://github.com/sminez/ad fixes some of the problems being mentioned here. No mouse required. TreeSitter integration so syntax coloring is there. LSP integration is there.