Hacker News Reader

Comment by Analemma_ | Hacker News Reader

This comment is a good distillation of my frustration with Unix ideologues. Unix and the CLI can never fail, they can only be failed; any possible unhappiness is a "skill issue"; it's your job to memorize a thousand arcane and badly-systematized program names and flags, created in an era of RAM and disk space limitations which have no relevance today, etc. And going "many of the same problems exist in GUIs" is a "no u" tier of response.

View on HN

Unix and the CLI tools represent a huge part of the foundation so much newer software sits on. No one can just change the commands and flags to make them less "arcane" or more "systematized" without breaking millions of lines of scripts and tools and workflows.

Anyone can make their own tools if they have a better idea, and sometimes those take off and get adopted -- look at vim and now Neovim, rg (ripgrep), even Python pushing Perl and bash scripts out of the way. And plenty of people will call those things arcane too.

If you manage servers you know that RAM and disk space and other limitations have lots of relevance today. I'll quote you the next time my boss or customer asks me to explain a huge AWS bill.

If you don't like Unix or CLI tools, or don't want to spend the (admittedly signficant) effort to master them, no one will force you. I think the effort pays off. I have dodged more than one round of layoffs because I can work from the command line and keep legacy scripts and code working.

Dismiss or make fun of us "Unix ideologues" if you want, but I don't worry about losing my job or customers like my friends who have "mastered" VSCode pasting in LLM-generated snippets of React.

Do you expect to go inside a plane and fly it with no training? Or pick up a violin and play a sonata? The terminal have its flaws, but all other interactions models have their own. But when people don't try to learn the basic tenet and just ask why it can't be like $other_system_they've_learned_first, you bet that they're going to point you to the manual.

I expect that pilots are allowed to have opinions about systems in the plane as being user unfriendly, like MCAS of 737 Max fame. I expect violinists to be allowed to complain when their bow is rosined wrong. Sure, we should expect users to at least read parts of the manual, but when billions of dollars have been spent so I can ask the computer to write me an ffmpeg invocation, haven't you got to ask to yourself that there's a chance we're making this unnecessary hard on ourselves for no reason?

> but when billions of dollars have been spent so I can ask the computer to write me an ffmpeg invocation

That was an unnecessary spend then. You should ask yourself why ffmpeg still exists if if it's that hard to use. There's a plethora of simpler tools that exists for simple uses (handbrake, XLD,...). The truth is that if you want versality, there's no better than ffmpeg and it's core usage is relatively simple. It's an input | filter | output pipeline, with various options to fine tune each one. If you don't have the domain knowledge, it will be hard, just like a layman inside a plane cockpit. But if you do, everything makes sense.

Same with a lot of other software. There are bad design out there, but if something persists with no other incentive than its users, you should probably ask why first.

I expect a light switch button on a plane act like any other light switch button everywhere else - switching the light when pressed. The fact that the you can point to the terminal manual that states that you must use --- triple tap for that is irrelevant - that's still very bad design, and you've just dismissed a real issue with an bad analogy.

> why it can't be like

Here is another mistake: in many cases it be.

> I expect a light switch button on a plane act like any other light switch button everywhere else

Me too, which was why I was very surprised when I discovered light switches in the USA worked backwards[0]. :D

(When I initially read your comment I didn't notice the use of "button" by which I guess you're referring to a push-button toggle style switch? But either way I still think light switches are an interesting example of non-obvious things that don't work the same way in all environments. (Even ignoring the "one light controlled by multiple switches" situation.))

----

[0] https://en.wikipedia.org/wiki/Light_switch#Orientation

Yes, I was aware of the toggle switch ambiguity when describing a button... (not a perfect analogy anyway)

Reply on news.ycombinator.com