alt Hacker NewsThe 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?
Replies
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?
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/