3 ms·

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

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.

mjevans 2y ago
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
- dredmorbius 2y ago
  Sure, for APIs or CLI tools. Doesn't work so well for GUIs, which was sort of the original point.
ndsipa_pomu 2y ago
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.
- dredmorbius 2y ago
  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.

mjevans 2y ago

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

dredmorbius 2y ago
Sure, for APIs or CLI tools. Doesn't work so well for GUIs, which was sort of the original point.

ndsipa_pomu 2y ago

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.

dredmorbius 2y ago
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.