Earlier quoted context omitted.
Fish is similar in this way, if you're not on Windows and thus don't have access to PowerShell.
PowerShell is available for Linux. There's also Elvish, Nushell, and a few other attempts in a similar vein.
A Requiem for a Dying Operating System (1994)
131–140 of 286 posts
Re: A Requiem for a Dying Operating System (1994)
#132Earlier quoted context omitted.
man -k "key words of the thing i'm searching for" ^^ also works fine ..
Finding man, cold from a prompt, is hard. If you type help, even today, you might get the shell one which doesn't take you there. Ditto info.
(base) user@myMachine ~ % help
zsh: command not found: helpRe: A Requiem for a Dying Operating System (1994)
#133Earlier quoted context omitted.
The issue with git is that no matter how well documented, the user interface is horribly designed. For starters, how many different things does "git checkout" do, and how many of them actually reflect an intuitive meaning of "checking out" ?
The one thing that all the negative commentary fails to acknowledge is that even in the face of this somewhat overstated inconsistency across all these command line tools and applications, is that for the knowledgeable and motivated, it is quite simple to wrap the more complex invocations in simplified scripts or, at the other extreme, a completely functional native GUI. They also fail to acknowledge that contemporar…
My brain is really quite small compared to all the knowledge about computers that is out there. And my willpower too is very limited. So I would rather learn things I'd rather like to know, and be motivated to do things I'd rather get done instead of spending those precious resources of mine (and time! I will die in less than 25,000 days, that's a pretty small amount of time, you know) on something of dubious value.
Re: A Requiem for a Dying Operating System (1994)
#134> One can only conclude that the makers of Unix held, and still hold, the ordinary computer user in total contempt, and this viewpoint seems to me to be mirrored in the attitudes of the people who are inflicting this awful system on the rest of us. Does Unix's enormously steep learning curve have any function other than to deter the faint-hearted, those who may want to use computers without necessarily dedicating the…
Re: A Requiem for a Dying Operating System (1994)
#135Earlier quoted context omitted.
Powershell pretty much has universal tab-complete. Typing a command, '-', and repeatedly hitting tab will cycle through all available arguments for that command, and arguments will be quite consistent between commands. But you can also tab complete variable names and the commands themselves. Discovering the cmdlets is not as trivial as it could be, because they are named verb-first instead of noun first. Get- is not…
> Discovering the cmdlets is not as trivial as it could be, because they are named verb-first instead of noun first Irrelevant. Use Get-Command *network #network anywhere in noun gcm *-network* #network as first word in noun PowerShell has it all, its just that people don't bother to learn it.
Re: A Requiem for a Dying Operating System (1994)
#136Earlier quoted context omitted.
Powershell pretty much has universal tab-complete. Typing a command, '-', and repeatedly hitting tab will cycle through all available arguments for that command, and arguments will be quite consistent between commands. But you can also tab complete variable names and the commands themselves. Discovering the cmdlets is not as trivial as it could be, because they are named verb-first instead of noun first. Get- is not…
> Discovering the cmdlets is not as trivial as it could be, because they are named verb-first instead of noun first Irrelevant. Use Get-Command *network #network anywhere in noun gcm *-network* #network as first word in noun PowerShell has it all, its just that people don't bother to learn it.
Re: A Requiem for a Dying Operating System (1994)
#137Our bodies are the same way.
Re: A Requiem for a Dying Operating System (1994)
#138Tell that to linux nerds who encourage people on forums to install arch from scratch if they want to learn about how computers work.
Re: A Requiem for a Dying Operating System (1994)
#139Re: A Requiem for a Dying Operating System (1994)
#140> Unix and C however form a powerful deterrent to the average astronomer to write her or his own code (and the average astronomer's C is much, much worse than his Fortran used to be). The powers-that-be in the software world of course have always felt that "ordinary" users (astronomers in this case) should be using software and not writing it. The cynic might feel that since those same powers nearly all make their living by writing software, and get even more pay when they manage other programmers, then they have a vested interest in bringing about a state of affairs where the rest of us are reduced to mere supplicants, dependent on them for all our software needs. It is clear that Unix does not pose an insuperable barrier --- the ever-expanding armies of hackers out there are evidence enough that the barrier can be scaled given enough time and enthusiasm for the task. But hacking is not astronomy, and hackers are not astronomers, and it is astronomy and astronomers I worry about. We shouldn't have to scale the Unix barrier, and it is all the sadder because, since the advent of a VMS-based Starlink, ordinary astronomers have had something denied to most other scientists in this country --- readily accessible, reliable, user-friendly computing power that can be easily harnessed to a particular astronomical requirement.
I've spent the past hour or so figuring out what I think about this. It's easy to dismiss this piece of rhetoric as flawed reasoning or as irrelevant today. For example, I'm not sure if Unix was ever to blame for the self-serving user-developer dichotomy discussed in that quote above. After all, the Unix philosophy is all about small tools tied together with scripting, not the mega-packages mentioned in the article. And was there really not a good Fortran option for Unix in 1994? Or was Starlink (or its Unix-based successor) just too cheap to buy whatever good Unix Fortran implementation might have existed back then?
But the software development priesthood is still a problem; I'd say it's worse today. It's what worries me the most about the future of computing for the next generation, including my nieces and nephew. Will they be able to help shape the software that runs so much of their lives if they can't land a job at a handful of tech behemoths? Much of that software is even built on a foundation of Unix and more generally open source, but the power of that foundation isn't available to the end-users.
However, the free software movement's answers to these problems are hampered by their own elitism, which is in fact largely a continuation of the Unix elitism this article bemoans. It's true that we have much better languages than C, there are usable GUI desktop environments for free Unixes, and there are even whole open-source integrated development environments that one can run on a free Unix. But at some point one still comes in contact with the same arcane, haphazardly designed command-line environment that this article and the UNIX-HATERS Handbook rightly ridicule.
So if we actually want a system that's both free and open from top to bottom, and actually approachable to most people, then maybe we need to finally let go of Unix, or treat it as only an expedient substrate as Apple and Google do. Or as another writer put it, we need to free our technical aesthetic from the 1970s [1].
[1]: https://prog21.dadgum.com/74.html
Disclosure: I happen to currently work for Microsoft, on the Windows accessibility team. But these opinions are entirely my own, written on my own initiative. And yes, the fact that I benefit somewhat from the user-developer dichotomy enforced by the likes of my employer makes me feel uncomfortable. But I'm not sure quitting would actually help anything.