The divergence between users and programmers became more pronounced over time. When command line interfaces were dominant they naturally made programmers out of users, even if they didn't realize it. CLIs made “using the computer” and “programming the computer” effectively the same activity in a lot of cases. A command someone entered to run a program was itself a program. Entering the previous command again and modifying it, for instance to pipe the output of the first program into another program, was also a program. Once the desired result was achieved, that final command could be saved and used again later. Or shared with someone to be used as-is, or to be tweaked a little bit for their own use case.
Each interaction with a CLI results in a valid program that can be saved, studied, shared, and remixed. That's a powerful model for the same reasons the spreadsheet model is powerful: it's immediate, not modal, and successful interactions can be saved as an artifact and resumed later. Can we do the same things for GUIs? What is the GUI equivalent of pressing the up arrow key in a shell, where I can recall my previous interaction with the system and then modify it? Can I generate artifacts as byproducts from my interactions with a GUI system that I can save for later and share with others?
I've been trying to solve that for a few years now. The closest existing thing I could find in my research was acme from Plan 9, which actually does a pretty good job. The trick it uses is to have you click on a typed command instead of "sending" it, and it stays on your screen after it runs. So you can save several commands in a file, and that's a menu. Or clear the current document and print out several commands from a script, and that's a dynamic menu.
I highly recommend reading the paper[a] and trying it out. It's really interesting, and pretty easy to program.
The main problems with it are that it's too text-centered, and the interaction model is kinda weird for modern standards. I feel these are solvable (Plan B's Omero tried, with partial success), but they are hard to do without integrating the UI and the script into a single process, which feels like cheating. But well. If I ever get around to making a prototype, it will be here on Show HN.
Consider watching the mother of all demos. The GUI paradigm we use today was intended to be for children. The intention was to have much more complex and composable UI for tech workers.
A lot of early users became programmers or sysadmins because they had to. Cliff Stoll was not the only scientist who suddenly found himself in charge of mainframes and learning everything about them. There wasn't a big pool of CS grads to do those things.
The shift to microcomputers enabled mass ownership by driving prices down and dumbing software down enough for everyone to use it. Except for price outliers like Macintosh and usability nightmares like blue screens.
Phones finally got us to today - ubiquitous, easy-to-use computers in everyone's pockets. Most users are clearly not programmers today. Nor do they want to be. Lumping all humans together as "operators" seems like a category error.
This is exactly what I have been thinking lately, starting with looking at Oberon. It seems to me that writing a simple GUI should be the same as writing a simple text-oriented script. GUIs have their own challenges, of course. However, doing the GUI equivalent of print() statements to show calculation output is a think a modern operating system should do, not have a distance between user and the graphic system. At the moment, it's a pretty ideal, but there are cases I wish their was less friction with it.
edit: I never tried, but isn't this where Smalltalk comes in?
The ginormous computer companies don't target programmers, they want ever more users aka consumers. Apple is a good example, their products are increasingly difficult to program yet increasingly polished to appeal to the under-informed buying public.
We only need to look at how BASIC (MS) and HyperCard (Apple) were eliminated in order to remove easily accessible end-user programming. wrt spreadsheets, only a tiny minority of operators use the macro or language binding features.
I shudder at new motor vehicles being ever more software based. On this basis of any recognized bug to lines of code metric, hundreds of faults are lurking therein.
I like this framing! Personally, I'd like to see the Unix shell evolve into a system with a GUI. Where text and graphics are integrated, and the shell isn't "trapped" in the terminal.
There is a historical, path-dependent conflation in this area -- a text-based UI doesn't necessarily imply a terminal-based UI
Excel is pretty good at combining the two paradigms -- it has the textbox where you can type (almost like a URL bar), and it has the GUI part. But for all its power, I don't want to use Excel ... I like spreadsheets, and use LibreCalc a bit, though it's limited.
And I'd like if there were multiple GUI/graphical paradigms combined with text, not just the grid of cells (as useful as it is)
AutoCAD is kind of a classic form of integration of text with GUI via a command window. In general, any GUI I build these days I build to be scriptable, if possible, and I look to translate as much as possible through that scriptable interface.
This has helped immensely with AI assistive (“vibe coding”) tools.
yes!!! this is exactly the direction i want to go with the post on “terminal of the future”—we should reimagine a structured terminal, where the interface isn’t dependent on emulating a VT100.
have you seen https://www.warp.dev/modern-terminal? they’ve made really a lot of progress here, they just locked it all in a platform and then didn’t have the vision to let you metaprogram it.
We're still working (intermittently) on a better shell <-> terminal interface. We actually did the first demo back in 2021, before we became aware of Warp. And here is an update from a month ago, which mentions Warp / IntelliJ / VSCode:
That is, we did some demos with a nushell contributor, to see if there is a protocol that Oils and nushell can agree on. The big constraints seems to be bash and zsh. (I still believe in graceful evolution, not building a "inner platform")
I think these 2025 demos went pretty well, but it's still in the demo/research phase.
This article touches on the revulsion "programmers" have toward Excel.
Deep down it's because many can't imagine writing a program in any way besides rigid, idiomatic OOP
Excel is a pure functional declarative DSL w/ immutability. It has lambdas & you can build applications that are fully data driven, like an ECS
These are already paradigms that the software industry is not open-minded about. And here the mediocre programmer is able to appeal to authority. If "non-technical" users like a bookkeeper can program with Excel, it must be dumber and less elegant than the PHP script I would have written, right?
The best financial modellers are more productive FP devs than many "programmers" deriding Excel, but we've allowed ourselves to think that doesn't "count"
> i would go one step further: the dream of malleable software is to unify users and programmers, such that there are just “operators” of a computer, and “writing a program” doesn’t sound any harder than “writing a resume”
People are on average very stupid, very lazy, don't want to think about anything deeply, and may in fact not only not only not know how to get from origin to destination may on average not even know what their destination ought to be.
Making something more accessible means enabling people who will still be called developers do more whilst knowing less it won't ever make everyone a developer.
A computer operator is someone who maintains the operation of a computer system and schedules programs submitted by users.
It’s mostly a dead profession that has been automated by operating systems.
Honestly neither programmer or user have negative connotations to me. They both imply an active role when interacting with the computer. The term I _really_ hate that’s getting way too commonly thrown around lately is consumer.
The past 30 years have seen a huge explosion in incidental complexity of programming. Programmers are currently very well paid understand and manage this incidental complexity. Unfortunately, because of this high compensation, they are also most responsible for perpetuating incidental complexity (framework churn, GUI design fads, build systems, etc.). Non-programmer professionals are adept at handling essential complexity. LLMs give some hope of closing the gap between "user" and "programmer" by managing the pain of incidental complexity.
Readit News
Each interaction with a CLI results in a valid program that can be saved, studied, shared, and remixed. That's a powerful model for the same reasons the spreadsheet model is powerful: it's immediate, not modal, and successful interactions can be saved as an artifact and resumed later. Can we do the same things for GUIs? What is the GUI equivalent of pressing the up arrow key in a shell, where I can recall my previous interaction with the system and then modify it? Can I generate artifacts as byproducts from my interactions with a GUI system that I can save for later and share with others?
I highly recommend reading the paper[a] and trying it out. It's really interesting, and pretty easy to program.
The main problems with it are that it's too text-centered, and the interaction model is kinda weird for modern standards. I feel these are solvable (Plan B's Omero tried, with partial success), but they are hard to do without integrating the UI and the script into a single process, which feels like cheating. But well. If I ever get around to making a prototype, it will be here on Show HN.
[a]: http://doc.cat-v.org/plan_9/4th_edition/papers/acme/
https://www.youtube.com/watch?v=yJDv-zdhzMY
A lot of early users became programmers or sysadmins because they had to. Cliff Stoll was not the only scientist who suddenly found himself in charge of mainframes and learning everything about them. There wasn't a big pool of CS grads to do those things.
The shift to microcomputers enabled mass ownership by driving prices down and dumbing software down enough for everyone to use it. Except for price outliers like Macintosh and usability nightmares like blue screens.
Phones finally got us to today - ubiquitous, easy-to-use computers in everyone's pockets. Most users are clearly not programmers today. Nor do they want to be. Lumping all humans together as "operators" seems like a category error.
edit: I never tried, but isn't this where Smalltalk comes in?
“Experts and beginners both want to use the same tools. Children want to learn saxophone, not kazoo.” - Rich Hickey
We only need to look at how BASIC (MS) and HyperCard (Apple) were eliminated in order to remove easily accessible end-user programming. wrt spreadsheets, only a tiny minority of operators use the macro or language binding features.
I shudder at new motor vehicles being ever more software based. On this basis of any recognized bug to lines of code metric, hundreds of faults are lurking therein.
There is a historical, path-dependent conflation in this area -- a text-based UI doesn't necessarily imply a terminal-based UI
Some links to work in that direction: https://www.oilshell.org/blog/2023/12/screencasts.html#headl...
Excel is pretty good at combining the two paradigms -- it has the textbox where you can type (almost like a URL bar), and it has the GUI part. But for all its power, I don't want to use Excel ... I like spreadsheets, and use LibreCalc a bit, though it's limited.
And I'd like if there were multiple GUI/graphical paradigms combined with text, not just the grid of cells (as useful as it is)
This has helped immensely with AI assistive (“vibe coding”) tools.
have you seen https://www.warp.dev/modern-terminal? they’ve made really a lot of progress here, they just locked it all in a platform and then didn’t have the vision to let you metaprogram it.
We're still working (intermittently) on a better shell <-> terminal interface. We actually did the first demo back in 2021, before we became aware of Warp. And here is an update from a month ago, which mentions Warp / IntelliJ / VSCode:
https://lobste.rs/s/viwe6p/open_source_can_t_coordinate#c_px...
That is, we did some demos with a nushell contributor, to see if there is a protocol that Oils and nushell can agree on. The big constraints seems to be bash and zsh. (I still believe in graceful evolution, not building a "inner platform")
I think these 2025 demos went pretty well, but it's still in the demo/research phase.
After working in this area for many years, I think the bottleneck is coordination, mentioned here - https://lobste.rs/s/ejcoud/dreaming_smel_shell
i.e. there are many separate projects doing similar things, and most of them get to 80% or so. I like that you mention a lot of prior art!
More links: https://github.com/oils-for-unix/oils/wiki/Headless-Shell-Pr...
Feel free to join any of the Zulip discussions ... there are a bunch of prototypes floating around, but nothing set in stone!
Deep down it's because many can't imagine writing a program in any way besides rigid, idiomatic OOP
Excel is a pure functional declarative DSL w/ immutability. It has lambdas & you can build applications that are fully data driven, like an ECS
These are already paradigms that the software industry is not open-minded about. And here the mediocre programmer is able to appeal to authority. If "non-technical" users like a bookkeeper can program with Excel, it must be dumber and less elegant than the PHP script I would have written, right?
The best financial modellers are more productive FP devs than many "programmers" deriding Excel, but we've allowed ourselves to think that doesn't "count"
People are on average very stupid, very lazy, don't want to think about anything deeply, and may in fact not only not only not know how to get from origin to destination may on average not even know what their destination ought to be.
Making something more accessible means enabling people who will still be called developers do more whilst knowing less it won't ever make everyone a developer.
It’s mostly a dead profession that has been automated by operating systems.
Honestly neither programmer or user have negative connotations to me. They both imply an active role when interacting with the computer. The term I _really_ hate that’s getting way too commonly thrown around lately is consumer.