In the Beginning Was the Command Line (1999)

One major advantage of the CLI is that instructions/fixes etc are very concise and can be easily communicated. If someone has a Linux system that needs a known fix, then it's trivial to send someone the commands to copy/paste into a terminal. However, if there's a known fix for a graphical program, then it suddenly becomes much harder to communicate - do you go for a textual instruction (e.g. click on the hamburger menu, then choose "preferences"...), or a series of screenshots along with some text?

I think your trailing question is a hypothetical but to answer:

Screenshots along with text, then use Microsoft Paint to mark up the screen shots. For example, circling the appropriate menu option in a thick red line. Sadly, I do not know how to graphically convey the double-click operation.

Its a time consuming and error prone process, best used if the buggy GUI application is abandonware. Otherwise, the new version will have the same bug or non-intuitive process but the GUI will be unrecognizable. Probably because some manager, somewhere, read too many HN articles and decided a user-facing refactor was the most important thing they could possibly do.

You raise a good point about GUIs changing over time. Obviously, CLIs can change, but that happens less often and is usually in response to a poorly thought out first attempt at providing functionality (or when additional functionality is bolted on).

Agreed. Poor scripting/replay inherently limits the GUI.

That said, the best late 90s expression of the core advantage of the GUI over the TUI/CLI is that it demands less of the user:

"recognize and click" vs

"remember and type"

That seems very fundamental to me.

I have not seen as succinct expression of tradeoffs for V(oice)UI or L(LM)UIs

On windows, steps recorder can be useful. https://support.microsoft.com/en-us/windows/record-steps-to-...

How about the new kid on the block here, the chat interface? Neither "recognize and click" nor "remember and type", esp. if done over voice.

Maybe the chat interface does away with the first half of the GUI/CLI schemes, skipping over learning the affordance part of the interface.

Or even write a script which is just those commands. Meanwhile every step a user as to do is an opportunity to cause a new and different problem.

This seems to deny the possibility of equivalence of any sequence of actions taken in a bounded spaces of entities (named widgets thus type:id) and actions to another 'representation' (e.g. text):

   { select[i]@dropdown:states > click@button:submit }

The fact that we don't have this (yet) does not mean it is not possible. In fact, given that the current darling of tech LLMs can 'compute visually' based on tokens (text) should make it clear that any 'representation' can ultimately be encoded in text.

So a 'record' feature on GUI 'a' can create action encoding that can be emailed to your peer looking at GUI 'b' and 'pasted'.

MacOS kind of had this with AppleScript, including recording. It's a little disappointing that it isn't widespread now but I realize that demand for GUI automation is extremely niche.

Scripts are UI glue in more than one sense.

The usual interpretation is that scripts glue together system commands that don't otherwise incorporate one another. This is tremendously useful and is by itself a huge advantage over GUIs.

But the second sense is that vast libraries of scripts keep developers bound to their previous UI promises. You don't capriciously change command-line options without raising all kinds of ire. I've seen GNU tools (tar comes to mind) in which options have been "deprecated" for decades, yet are still available. I seem to recall a very small number of cases where options had their senses entirely inverted, to much protest, and ultimately abandonment of those tools. In other cases you've got generations of programs which support backwards-compatible options with precursors: exim and postfix with sendmail, ssh with rsh, alpine with pine, off the top of my head. Developer headspace and script compatibility are valuable.

On that note, whilst I find the *BSD's extreme conservatism annoying myself, I can appreciate that it does lead to increased consistency over time as compared with GNU userland.

The correct response to an API change is to re-version the API for the library. E.G.

bsdtar -> libarchive -- Arguments as presently known

bsdtar2 -> libarchive -- Some new overhaul that does things way differently

The 90s UIs all had 'hints' for how to activate UI features using keyboard shortcuts.

Want to know how to copy and paste quickly? It's Right There in the menu you found the action in. Don't know that yet? Alt + E (underlined in Edit) then some other key to jump to the action in the list, or you now see the list, abort the previous command sequence with Esc, and then start memorizing the new shortcut for Ctrl+c + Ctrl+v.

Sure, for APIs or CLI tools.

Doesn't work so well for GUIs, which was sort of the original point.

There's also a lot of text based tools that are designed to be used as part of a script and don't provide much functionality in themselves - the philosophy of do one thing (and do it well). GUIs tend to be designed to provide the entire functionality that's wanted and little thought is given to them being used as part of a toolchain.

I really wish one of the little GUI frameworks would develop this, but alas, the evidence is that "nobody" actually wants this. As evidenced by the things like Applescript that existed, and died.

I feel like it could be done if it was really a goal from day one, and there were things like "record this set of actions as a script" built into the toolkit. Even Applescript was still an afterthought, I think, albeit a very well supported one.

In the meantime, given the comprehensive failure of UI toolkits to support this style, it is completely fair for people to act and speak as if it doesn't exist.

Right. CLIs / TUIs offer composability. GUIs don't.

If someone makes a GUI that does specifically what you want, you're in luck. If not, you're S.O.L.

With CLIs, you can almost always find some way to string things together to get what it is you want.

The hard case is working in domains which aren't inherently textual: graphics, audio, video, etc. Even there, you can often get much more accomplished from the terminal than you'd think, though setting up the process can be challenging at times. Not so useful for one-offs, but invaluable for repetitive processes.

Not only is it good for sharing but for automating functions in script. Imagine managing an IT environment where you have to click around the gui for each and every workstation, versus what these IT professionals actually do which is write a configuration script that does all their setup functions, which they can push to all networked workstations from their office with a single keystroke.

To do that in a gui-centric fashion, the only tools we actually have are textual commands that direct gui action. essentially its a middleman step: if we are already writing our applescript lets say, we might as well just abrogate the actual commands that our applescript is trying to abrogate through the gui system.

Applescript is so clunky and annoying. I have a few applescript launcd functions on my mac for some personal projects, and only because apple forces you to go through stuff like applescript to use stuff like the system notifications. It was a pain as the documentation is just so very poor for applescript, so clearly neglected by anyone at apple even when they built the tool; its not like good documentation only came about in recent years in programming. Then again most of what apple documents is crap. The launchd documentation isn't any better and I get undefined behavior I can't make head or tail of from it (basically functions working fine when ran as a user but failing silently when the same functions are ran through launchd), I'm guessing from some permissions related issue between launchd running as a certain privileged process and maybe the limits of their system integrity protection, I can't be sure because the documentation is so poor. And what is even worse is that there aren't many people using tools like launchd, at least not nearly compared to people who use systemd, so the various stackoverflow or blog posts you could look for reason in these more popular tools are not there for the apple tooling.

Both Applescript and Automater are still around, and still provide recording.

Since CLIs are used in scripts/automation there's much more pressure for them not to change. Essentially, they become an API so breaking changes are a big deal. GUIs, on the other hand, are very difficult to automate so they can't be used in that way even if people wanted.

As an aside, I think a great foundation for a GUI application is a "server" API that the GUI interacts with. You can automate a lot of testing this way and you can give power users the ability to automate workflows. Web apps are already built this way, but if you're making a standalone app you even have the privilege of making a very chatty API, which makes testing even easier.

> As an aside, I think a great foundation for a GUI application is a "server" API that the GUI interacts with. You can automate a lot of testing this way and you can give power users the ability to automate workflows.

An idea already implemented to varying degrees of success in places like BeOS, Haiku (operating system), and to a much lesser extent, AppleScript! You could also throw in the COM interop of Windows and OS/2.