←back to thread

In the Beginning Was the Command Line (1999)

(web.stanford.edu)
412 points conanxin | 8 comments | 27 Jul 24 06:25 UTC | HN request time: 0.41s | source | bottom
Show context
ndsipa_pomu ◴[27 Jul 24 12:50 UTC] No.41086243[source]▶
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?
replies(6): >>41086944 #>>41088283 #>>41088290 #>>41088405 #>>41089211 #>>41095482 #
anthomtb ◴[27 Jul 24 14:47 UTC] No.41086944[source]▶
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.

replies(1): >>41087495 #
1. ndsipa_pomu ◴[27 Jul 24 16:17 UTC] No.41087495[source]▶
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).
replies(2): >>41089899 #>>41102998 #
2. dredmorbius ◴[27 Jul 24 22:50 UTC] No.41089899[source]▶
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.

replies(2): >>41091579 #>>41092052 #
3. mjevans ◴[28 Jul 24 06:29 UTC] No.41091579[source]▶
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

replies(1): >>41091974 #
4. dredmorbius ◴[28 Jul 24 08:32 UTC] No.41091974{3}[source]▶
Sure, for APIs or CLI tools.

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

5. ndsipa_pomu ◴[28 Jul 24 08:57 UTC] No.41092052[source]▶
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.
replies(1): >>41092914 #
6. dredmorbius ◴[28 Jul 24 13:11 UTC] No.41092914{3}[source]▶
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.

7. consteval ◴[29 Jul 24 19:26 UTC] No.41102998[source]▶
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.

replies(1): >>41124175 #
8. IIsi50MHz ◴[31 Jul 24 22:27 UTC] No.41124175[source]▶
> 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.