Of course some principles of speech and syntax should stay around (as they probably exist for a good reason), but it is foolhardy to grip tightly onto any language, human or computer, thinking it will always stay the same, when it plainly won't.
Of course some principles of speech and syntax should stay around (as they probably exist for a good reason), but it is foolhardy to grip tightly onto any language, human or computer, thinking it will always stay the same, when it plainly won't.
Partly, but less so.
Human language vocabularies approximate Huffman Coding - the more frequently used words (and phrases) tend to be proportionally shorter. This is a gradual process for spoken languages, and somewhat quantized for written languages.[1] It's possible because with human languages, "close" is "good enough"; one can read english written with ye olde orthography, if with a bit of extra effort.
Less so in the lifespans of particular programming languages. Per Postel's law we tend to be liberal with extending but conservative with breaking backward compatibility. I think the case of command line tool parameters is particularly conservative for various reasons; among them because the 'knowledge' of options is spread among multitude of separate project - many of them obscure and bespoke - and coordination would be nigh impossible.
However there are some signs of similar trends; note how the "function" and "integer" and similar keywords of older languages tend to turn into "fn" and "int" in newer languages.
--
[1] Not sure if there's a comparable process for grammars, but I guess it's a fair bet...?
Pejoration happens too. When is the last time you used a GOTO in code? And yet, 40 years ago, you couldn't write a BASIC program without one. And the revulsion against NULL causing a shift to Maybes and optional types to the point where the concept is reified in many languages now?
All I'm saying is that there are multiple mechanisms that are changing the languages we write code with, and that it is changing far faster than people realize.
So why does `ls` have a recursion flag? Why does `cp` have a recursion flag? Why does `chmod` have a recursion flag? Why does `chown` have a recursion flag? Why isn’t recursion its own command, that takes as argument the command to apply at each level?
Ditto untyped, untagged streams, which mean every tool implements its own custom UI behavior when attached to a terminal, instead of outputting tagged data and letting the consumer run it through system-standard data formatters.
This is not good—or even borderline competent—systems design. This is bullshit. Because the people who slapped it all together are bums, and the people who accepted it didn’t care enough to call them on it.
But noooo, we can’t change anything now; because “backwards compatibility”.
Protip: when you build a system that can’t evolve, that grinds to a halt under its own impossible weight, it’s time to confess “yeah, we totally ballsed that one up” and start over again, lessons learnt. Because maintaining that status quo is a tyranny: dragging everyone else down to the level of its incompetence, and beating them to death with intransigence. No prizes for guessing who that benefits: the bums who built it. And who pays for it: everyone else.
It’s a scam. Perpetrated by and for those who cannot admit they are wrong.
Smash it down. Because whatever comes after it should be so much better, the only question will be “Why the frell did we wait so long?”
--
“Those who make peaceful revolution impossible will make violent revolution inevitable.”—John F Kennedy
Why did ls even need 11 parameters to begin with? Why not exactly 1? Or none? Why did tar need 12? Why did find need 14? The 28 tools in the example (excluding non-existing ones) had an average of ~3 parameters per tool in '79. Should 2017 have brought us 200 extra individual tools to provide the same additional functionality? You want another tool that does recursion for ls to save us from "incompetent bums" and "grinding to a halt"?
Everything around you grew in complexity to adapt to your needs because there's value in consolidation. It's why you are now typing from a device that is orders of magnitude more complex and integrated than the one used to write down the Unix philosophy.
You ask the question "why" but fail to answer the "why not". Why would a tool that still does exactly what it used to do in the past not be able to also do more especially when it's still within its sphere of relevance? And not the "out of principle" answer, not the handwaivy, tin foil hat answer, not the offensive and insulting answer that you provided above (bums? incompetent? bullshit? scam?).
Times change and philosophies adapt to remain relevant. "We must use time as a tool, not as a couch" - JFK.
Yes I absolutely do. Remember UNIX? "Many tools, each small, each doing one thing well". Adding hundreds of flags to older tools does NOT achieve that. Your point here?
> Everything around you grew in complexity to adapt to your needs because there's value in consolidation.
Please don't cross into abstract philosophy. It adds absolutely nothing to a specific technical discussion.
> It's why you are now typing from a device that is orders of magnitude more complex and integrated than the one used to write down the Unix philosophy.
I use my computers as the complex messes and a series of train-wrecks that they are, and now hear me out please, because I literally have no other choice. Be it Win10, Linux, Mac, it's honestly almost irrelevant. One example: to this day nobody can make a reliable system-wide sleep mode that is not messed up by extra hardware (like my external HDDs), on neither of those 3 major OSes. In 2020.
I can't go back to my Apple IIc. I will lose my job if I do.
What's your point here? That such a complexity is inevitable? Is that it? But who argues against that? Of course it's inevitable, we see it in every area of life -- it's one of the aspects of entropy. What's being discussed is: "isn't it time to take a firmer stance and start using newer tools that don't have these problems and protest against the old ones by not using them"?
I personally answered "yes" and I am gradually doing more and more of it -- already replaced grep, ls, find/xargs, about 13 in total IIRC. You know what? My productivity on the terminal skyrocketed. I started ditching languages with too much magic and implied behaviour and too weak/random typing (PHP/JS come to mind) and moved to others which, while not covering everything that I'd like to have (like Elixir), are still letting me sleep that much better knowing that `[] == 0` is actually false and I won't have to curse my way through logs in the next morning.
> You ask the question "why" but fail to answer the "why not".
If you actually frequent HN and aren't just looking for conflict then you'd know that literally every month we have a few rants by people who are now burned out that decry the current state of affairs. But if you really want me to answer then I can likely summarise it to:
"Because our tiny brains don't work well with so much complexity in the long run. We can cope for a few years, some even for 20 and more, but eventually we can't. Because having smaller, more-focused, and more (total count of) tools that each do something really well, has been demonstrated to work better everywhere, not only in IT."
(But I am aware this has been contended endlessly and it devolves into belief and tribalism and science and historical evidence goes out the window in the first three comments tops. Sad. Shouldn't happen to techies. We should be better than that.)
> Why would a tool that still does exactly what it used to do in the past not be able to also do more especially when it's still within its sphere of relevance?
Because it's NOT, and your parent commenter gave you an excellent example which you immediately dismissed and THEN proceeded to ask your question again, pretending he never gave an example. Are you aiming at being disrespectful on purpose? Confusing.
> And not the "out of principle" answer, not the handwaivy, tin foil hat answer
You are aware you are crossing into ad hominem and almost insults, no?
> Times change and philosophies adapt to remain relevant.
Well that's a perfect example how the same sentence is viewed in two completely different ways. This is EXACTLY the problem, dude: philosophies don't adapt at all in our area, most of the time. I knew a sysadmin that adopted those newer CLI tools (most written in Rust but some in Go, like `fzf`) and he is now doing the job of 3 people -- especially after also adopting Nix/NixOS. And I know people that will defend their 5000+ lines of Makefiles with hacks around niche return values of `ls` with their dying breath.
That's exactly the problem. Most people (and philosophies) don't adapt at all. They prefer to fight very hard to mold reality to keep agreeing with their philosophy. I am surprised you are not seeing this because it's literally everywhere -- from your local airport with their laughable security checks to your local cafeteria that likely still uses cash registers that can be hacked with a simple cable and a laptop and running a script and the whole thing will take about 7 seconds before the lady behind the counter even gets back from the toilet.
> "We must use time as a tool, not as a couch" - JFK.
Again, your point?
---
Don't take my comment as an attack. But you very quickly dismissed some pretty good points and proceeded to [attempt to] hijack the discussion to irrelevant -- or too abstract -- examples. Again, I'd change my computer and OS to something more conservative, with one way of doing things and not hanging on to ancient and obviously not-working-that-well-anymore philosophies, tomorrow -- if it existed. But it doesn't.
The fact that now we have no choice doesn't prove your point at all.
Simplicity means different things to different people and at different times. You are both making the same argument for simplicity for the sake of simplicity with no objective measure for it other than a "guideline" philosophy of "does one thing well", and just dismiss the majority who doesn't fit your "burnout as proof" argument.
If you want to wave the philosophy flag you must also acknowledge that either it never applied to pretty much anything as such, or it implies you should adapt your tools to the times, the facts, the challenges.
> Again, your point?
Take full advantage of the times you live in or be left behind, burnt out, reminiscing the glorious past I guess...
Unix provides rather limited primitives for composition, and a lot of things remain unsafe or very difficult to do right in shell. That's why we keep extending tools and doing things (rather redundantly) in a real (if outdated and limited..) programming language.
A lot of that complexity is due to poor design, not due to inherent complexity in the user's needs.
Just yesterday in fact, while implementing a state machine. Except the developers of that particular language explicitly did away with GOTO, so I ended up approximating it with a SWITCH/CASE. At least the language supports fall-through...
Which is to say, people differ in judgements of various features (footguns vs swiss army knifes). Moreover, the judgements seem to oscillate as fashions, in ~10 year long cycles. Please recall how exceptions and templates used to be a hot thing back in the day. Ditto garbage collectors. Presently we're all in love with Rust, and the "JITs considered harmful" paper will drop any day now.
It's interesting to think about how things can be swapped dynamically in this system. Consider the evolution of 'telephone.' In the 1980's, 'phone' referred to a land-line telephone. In the 2000's, it was ambiguous; for young people, it meant 'cell phone' most likely, or we started calling them 'house phones' for land lines. Now 'phone' is mostly used for a 'smart cellular telephone'.
Another interesting example is "Playstation". That always refers to the current generation, and we retroactively apply "PS1."
It will be an interesting period for history in the future to try and decode our present-day meanings since so many words are period specific.
You could probably trace a similar evolution across programming languages, just by systematizing the phrases/words used in each to accomplish the same thing.