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.
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?
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.
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’ve been working on my own to build in this same direction, and recently started writing about what I’ve built so far (HN link below). If you agreed with this article, give it a read.
I would add that the artificial divide is purposefully made worse in corporate environments. IT and Data & Analytics departments put curbs on user programmable anything typically in the name of expense. However, I would argue that these controls exist only to prop up the department’s managers and hand them an outsized role at the senior management table. It’s not just engineering snobbery that creates this divide, it’s a purposeful exertion of control for the sake of control.
This has come up a lot at work for me the last few years.
I've ended up (unintentionally, but satellite control systems is a small world) working on systems both using the same framework (a COTS satellite C&C system) though with differing attitudes on how it should be used. The framework has a lot of issues, among them the creators don't understand that if adding two 64-bit values gets you a 32-bit value it's probably not working correctly (it has its own bespoke scripting system).
However, one of the things I think they got right, at least in principle if not in the precise mechanism, is that the end users can develop their own automation scripts, displays for telemetry and other data, etc. very easily. What's been interesting is the perspective the two projects take on this.
In one, the operators are given a write-protected baseline. This means they cannot mess with the known working (or working but with known issues) versions willy-nilly. However, the operators make modifications to scripts as, for instance, it turns out the documentation on a satellite's command language is wrong (happens more than you'd expect for 9- to 10-figure systems). They make their own modified versions of the displays. They attach to the automation hooks so that when some telemetry values pop up, specific scripts are triggered, and so on. They're programming even if they don't recognize it as such, and actively engaged with improving their system.
In the other, the operators are actively discouraged from this. They are encouraged to provide feedback, but not to make their own scripts, to attach to automation hooks, or to make their own displays (as new displays or their improved, for their mission needs, version of the display).
It's been interesting because while the former had some issues, like the operators making scripts that failed because the scripting language has subtle errors that people on my side (more actively involved in maintaining the systems) understood and they didn't, it worked pretty well. They'd send us how they want things to look and flow with working scripts and custom displays not just descriptions. It wasn't speedy or always the most congenial, but it was collaborative. In the current one, though, it's more like there's a lack of trust in the operators. An assumption that they will fuck things up and a fear of how to restore the system to a known good state overriding a desire
There are true idiots out there and malicious people, you have to take some precautions. But it's been interesting to me to see two organizations dealing with the same kinds of critical systems (screwing up a billion dollar satellite is a big deal) taking almost diametrically opposed positions on operator customization and modifications to their systems. I like the more open one better, add in some reasonable constraints (they have sims to test against, use version control and peer reviews and engineering reviews) due to the criticality of the systems in question, but let them make the modifications. A perfect system can't be engineered without input from users, and users making modifications to suit their needs shortens the loop instead of taking weeks, months, or years.
this is SO COOL thank you for sharing!!! i love that you mention this is collaborative, i really think people can do so much if they just have a little guidance on how to get started.
the lack of trust is so real—this is one of the reasons i focused so heavily on autosave and rollback in the post, because it gives people the freedom to experiment without being afraid of breaking things.
Malleable software is hard not just for technology reasons; probably the most difficult part of designing software is thinking through and cleanly handling the implications of every decision. It's easy to imagine that one could 'just make it work like this instead of that' without understanding the implications of the change or the reasons why the system is like that in the first place. Making software has never been easier than it is today, but it's still hard because designing coherent systems that work correctly in all scenarios of usage is hard.
Yes, configurability is good and scripting is a great way to safely add functionality to a system but there will always be a distinction between people who use software and just want it to work perhaps with minor tweaking, and those who build systems. It makes no more sense to throw everyone in the same bucket than saying that being able to change the oil in a car makes everyone a mechnical engineer.
Also:
> Many, many technologists have taken one look at an existing workflow of spreadsheets, reacted with performative disgust, and proposed the trifecta of microservices, Kubernetes and something called a "service mesh".
Yes, over-engineering is a thing, but piles of interlinked spreadsheets are usually thrown out precisely because the people who created them didn't have the skills necessary to build a system, and these ad-hoc systems eventually outgrow their usefulness and become unwieldy horror shows. Maybe Beryl in accounts knows the eighteen cells across three files that need to be updated when the interest rate changes, but if she leaves then we're all screwed.
two thoughts:
1) did you read the linked post on malleable software (https://nothingisnttrivial.com/vines.html)? it has a very good distinction between “functional risk” (is the business logic right) and “technical risk” (was the logic implemented correctly), and says—correctly IMO—that the more control we give to end users, the lower the functional risk is.
2) sometimes it’s ok for software not to scale (https://gwern.net/doc/technology/2004-03-30-shirky-situateds...). sometimes people are solving a problem just for themselves, not for a business. i want it to be possible to build situated software in an afternoon without spending a month studying how terminals and stacks and data structures work.
> 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.
Amazing that there's no mention of AI in this post. People have been trying and failing to blur this line since the beginning of computing, and the only real success story has been excel. And it's because rigid computing systems have to draw a line somewhere between user and developer, and if that line is in the wrong place, people will either get hampered or lost. And the correct threshold is different for every user and use-case
AI is going to finally be the realization of this dream. I don't think it could have happened any other way
And the main reason excel works is because it's very tangible. Referencing by cell address is obvious in ways declaring variables isn't. And the formula style is similar to the f(x) we learned in high school. And they are domain primitives instead of weird things like main() or sys.exit().
But most people don't like to program. They want to use their computer to do a task. And maybe they think of a novel way to do the task, but it's not a daily or even monthly occurrence. And even then they lack the training to fully specify their ideas (it's tedious for a reason). And from what I've seen, almost no one wants to spend the day trying to get it out a probability machine.
You're spot-on that excel managed to break through because it's one of the few kinds of rigidness that was both legible and familiar enough to the average person. But very little else is, because the average person doesn't think in precision.
> they lack the training to fully specify their ideas (it's tedious for a reason)
> almost no one wants to spend the day trying to get it out a probability machine
These are opposing statements. What AI does best is taking fuzziness or under-specification and making sense out of it. For the first time in history, computers don't need precise instruction to be useful.
> For the first time in history, computers don't need precise instruction to be useful.
They still do. What we've done mostly is extracting common meaning out of textual languages so that we can map out a prompt to an interpretation. But the issue is that a single sentence can have many and some are plainly wrong. The training data is also not so clean.
The computer is still using precise instructions. Now we only have a mapping program that's using probability and weights to match natural languages to those instructions with no limit on the gap between what it chooses and what was needed (aka error).
The standard way was to have the idea going through multiple people (or persona), each refining it until it's precise enough to be done by a computer. Yes, the final result, the program, is restrictive. But like checklist, the dependability matters more than creative flexibility. Especially in cases like "Transfer N dollars from account X to account Y". You don't want LLMs to decide it's fine for N to be negative or for N to be greater than the balance of account X.
Excel isn't the only one; Hypercard, Filemaker Plus, askSam, Emacs, the Unix shell, SAS, R, SQL, Microsoft Access, Visual BASIC, HTML, PHP, ... and maybe even APL, RPG-II, PowerBuilder, and COBOL.
AI papers over underlying problems, it’s a very strong force to reinforce the status quo. i don’t have strong feelings about AI, but i feel like “the AI generates a terminal command line for you” is just not going to work, it only deepens the division between users who have to blindly trust it isn’t hallucinating and programmers who can check it’s correct. (and most people won’t think to use it in this way anyway because they’ve never heard of a terminal before.)
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.
[a]: http://doc.cat-v.org/plan_9/4th_edition/papers/acme/
Probably worth mentioning that an earlier version of this is in Wirth's Oberon system, which inspired acme.
acme looks extremely cool, thank you for sharing!
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?
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.
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.
“If a system is to serve the creative spirit, it must be entirely comprehensible to a single individual. Human potential manifests in individuals.” https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk....
“Experts and beginners both want to use the same tools. Children want to learn saxophone, not kazoo.” - Rich Hickey
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
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)
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.
I'll keep an eye out for the blog post!
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!
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’ve been working on my own to build in this same direction, and recently started writing about what I’ve built so far (HN link below). If you agreed with this article, give it a read.
https://news.ycombinator.com/item?id=44449848
(thanks poster for help discovering this article)
I would add that the artificial divide is purposefully made worse in corporate environments. IT and Data & Analytics departments put curbs on user programmable anything typically in the name of expense. However, I would argue that these controls exist only to prop up the department’s managers and hand them an outsized role at the senior management table. It’s not just engineering snobbery that creates this divide, it’s a purposeful exertion of control for the sake of control.
This has come up a lot at work for me the last few years.
I've ended up (unintentionally, but satellite control systems is a small world) working on systems both using the same framework (a COTS satellite C&C system) though with differing attitudes on how it should be used. The framework has a lot of issues, among them the creators don't understand that if adding two 64-bit values gets you a 32-bit value it's probably not working correctly (it has its own bespoke scripting system).
However, one of the things I think they got right, at least in principle if not in the precise mechanism, is that the end users can develop their own automation scripts, displays for telemetry and other data, etc. very easily. What's been interesting is the perspective the two projects take on this.
In one, the operators are given a write-protected baseline. This means they cannot mess with the known working (or working but with known issues) versions willy-nilly. However, the operators make modifications to scripts as, for instance, it turns out the documentation on a satellite's command language is wrong (happens more than you'd expect for 9- to 10-figure systems). They make their own modified versions of the displays. They attach to the automation hooks so that when some telemetry values pop up, specific scripts are triggered, and so on. They're programming even if they don't recognize it as such, and actively engaged with improving their system.
In the other, the operators are actively discouraged from this. They are encouraged to provide feedback, but not to make their own scripts, to attach to automation hooks, or to make their own displays (as new displays or their improved, for their mission needs, version of the display).
It's been interesting because while the former had some issues, like the operators making scripts that failed because the scripting language has subtle errors that people on my side (more actively involved in maintaining the systems) understood and they didn't, it worked pretty well. They'd send us how they want things to look and flow with working scripts and custom displays not just descriptions. It wasn't speedy or always the most congenial, but it was collaborative. In the current one, though, it's more like there's a lack of trust in the operators. An assumption that they will fuck things up and a fear of how to restore the system to a known good state overriding a desire
There are true idiots out there and malicious people, you have to take some precautions. But it's been interesting to me to see two organizations dealing with the same kinds of critical systems (screwing up a billion dollar satellite is a big deal) taking almost diametrically opposed positions on operator customization and modifications to their systems. I like the more open one better, add in some reasonable constraints (they have sims to test against, use version control and peer reviews and engineering reviews) due to the criticality of the systems in question, but let them make the modifications. A perfect system can't be engineered without input from users, and users making modifications to suit their needs shortens the loop instead of taking weeks, months, or years.
The foregoing brings to mind an article I read a long time ago about JPL using Lisp and "patching" some probe when it was a very long way away.
That'd be this one: https://flownet.com/gat/jpl-lisp.html
Or possibly this one: https://corecursive.com/lisp-in-space-with-ron-garret/
I think he's written about it in a few other places, too, but I'm not sure where.
this is SO COOL thank you for sharing!!! i love that you mention this is collaborative, i really think people can do so much if they just have a little guidance on how to get started.
the lack of trust is so real—this is one of the reasons i focused so heavily on autosave and rollback in the post, because it gives people the freedom to experiment without being afraid of breaking things.
I love this so much, and eager to see what comes next in the "multi-part series".
This approach is rare, but when it works, it works really well.
I built this for myself. I call in imtropy and it is awesome.
Getting it prod ready for others takes too much time and money I don't have.
please post demo vid.
Malleable software is hard not just for technology reasons; probably the most difficult part of designing software is thinking through and cleanly handling the implications of every decision. It's easy to imagine that one could 'just make it work like this instead of that' without understanding the implications of the change or the reasons why the system is like that in the first place. Making software has never been easier than it is today, but it's still hard because designing coherent systems that work correctly in all scenarios of usage is hard.
Yes, configurability is good and scripting is a great way to safely add functionality to a system but there will always be a distinction between people who use software and just want it to work perhaps with minor tweaking, and those who build systems. It makes no more sense to throw everyone in the same bucket than saying that being able to change the oil in a car makes everyone a mechnical engineer.
Also:
> Many, many technologists have taken one look at an existing workflow of spreadsheets, reacted with performative disgust, and proposed the trifecta of microservices, Kubernetes and something called a "service mesh".
Yes, over-engineering is a thing, but piles of interlinked spreadsheets are usually thrown out precisely because the people who created them didn't have the skills necessary to build a system, and these ad-hoc systems eventually outgrow their usefulness and become unwieldy horror shows. Maybe Beryl in accounts knows the eighteen cells across three files that need to be updated when the interest rate changes, but if she leaves then we're all screwed.
unwieldy yes but a working prototype of what the organization actually needs.
two thoughts: 1) did you read the linked post on malleable software (https://nothingisnttrivial.com/vines.html)? it has a very good distinction between “functional risk” (is the business logic right) and “technical risk” (was the logic implemented correctly), and says—correctly IMO—that the more control we give to end users, the lower the functional risk is.
2) sometimes it’s ok for software not to scale (https://gwern.net/doc/technology/2004-03-30-shirky-situateds...). sometimes people are solving a problem just for themselves, not for a business. i want it to be possible to build situated software in an afternoon without spending a month studying how terminals and stacks and data structures work.
There are cases when the entire point of automation is to remove the flexible but unreliable and sometimes untrustworthy human component.
> 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.
They would also once in a while fix a script. I started out as an operator. You also forgot load mag tapes :)
Also pulling output off of the line printer, separating it at the banner pages, and slotting it into cubbyholes for people to pick up.
And feeding stacks of punched cards into the card reader.
Does this count as self-promotion?!
No, I'm not related to the Mr Hollerith who invented the punched card.
Amazing that there's no mention of AI in this post. People have been trying and failing to blur this line since the beginning of computing, and the only real success story has been excel. And it's because rigid computing systems have to draw a line somewhere between user and developer, and if that line is in the wrong place, people will either get hampered or lost. And the correct threshold is different for every user and use-case
AI is going to finally be the realization of this dream. I don't think it could have happened any other way
And the main reason excel works is because it's very tangible. Referencing by cell address is obvious in ways declaring variables isn't. And the formula style is similar to the f(x) we learned in high school. And they are domain primitives instead of weird things like main() or sys.exit().
But most people don't like to program. They want to use their computer to do a task. And maybe they think of a novel way to do the task, but it's not a daily or even monthly occurrence. And even then they lack the training to fully specify their ideas (it's tedious for a reason). And from what I've seen, almost no one wants to spend the day trying to get it out a probability machine.
You're spot-on that excel managed to break through because it's one of the few kinds of rigidness that was both legible and familiar enough to the average person. But very little else is, because the average person doesn't think in precision.
> they lack the training to fully specify their ideas (it's tedious for a reason)
> almost no one wants to spend the day trying to get it out a probability machine
These are opposing statements. What AI does best is taking fuzziness or under-specification and making sense out of it. For the first time in history, computers don't need precise instruction to be useful.
> For the first time in history, computers don't need precise instruction to be useful.
They still do. What we've done mostly is extracting common meaning out of textual languages so that we can map out a prompt to an interpretation. But the issue is that a single sentence can have many and some are plainly wrong. The training data is also not so clean.
The computer is still using precise instructions. Now we only have a mapping program that's using probability and weights to match natural languages to those instructions with no limit on the gap between what it chooses and what was needed (aka error).
The standard way was to have the idea going through multiple people (or persona), each refining it until it's precise enough to be done by a computer. Yes, the final result, the program, is restrictive. But like checklist, the dependability matters more than creative flexibility. Especially in cases like "Transfer N dollars from account X to account Y". You don't want LLMs to decide it's fine for N to be negative or for N to be greater than the balance of account X.
Excel is so usable because that rigidity eliminates an entire class of bugs
No race conditions, no side effects, no confusing state to debug
Functional languages like Nix is also extremely inflexible by design but there we recognize it as a "smart" feature, not a "dumb" limitation
Excel isn't the only one; Hypercard, Filemaker Plus, askSam, Emacs, the Unix shell, SAS, R, SQL, Microsoft Access, Visual BASIC, HTML, PHP, ... and maybe even APL, RPG-II, PowerBuilder, and COBOL.
It's hard to tell what will happen with AI.
AI papers over underlying problems, it’s a very strong force to reinforce the status quo. i don’t have strong feelings about AI, but i feel like “the AI generates a terminal command line for you” is just not going to work, it only deepens the division between users who have to blindly trust it isn’t hallucinating and programmers who can check it’s correct. (and most people won’t think to use it in this way anyway because they’ve never heard of a terminal before.)