Comment by jdp | Hacker News Reader

Comment by jdp | Hacker News Reader

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!

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.

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 never worked with Smalltalk either but I think you are right. The conversation here reminds me of the the Unix-Haters Handbook = )

Reply on news.ycombinator.com