>I saw the majority of his complaints as basically "it's too hard/unfamiliar", a sentiment which I don't really agree with as I've noticed the steepness of lear

>I saw the majority of his complaints as basically "it's too hard/unfamiliar", a sentiment which I don't really agree with as I've noticed the steepness of learning curve of various software tends to be correlated with how powerful it is - those who give up early might not see that Many powerful systems are unfamiliar and difficult to use— but a system that is unfamiliar and difficult to use is by no means necessarily powerful. At any rate, the issue isn't that Unix is difficult to use, because it isn't. What's difficult is using it well. What's difficult is learning all the idiosyncrasies, all the details you have to get right to write good software in the Unix ecosystem. What's difficult is learning when and why rm * does not do what you expect, recognizing the flaw in code like mv "$PROJECT_ROOT"/* . that can nuke your entire machine because the default semantics of the Unix shell are... well, questionable. The thing is, using Unix well isn't difficult because the individual things you have to learn are difficult; the problems with the above commands are very simple and easy to address. Using Unix well is difficult because these problems arise goddamn everywhere. >Inconsistent command names shouldn't be a difficulty - shell commands are like any other language, whose vocabulary is quickly learned with repeated use. >I'd consider it generous to see a mention of shell redirection in cat's manual, since that's done before it ever gets executed; in general, interactions between commands can't be exhaustively documented because they are numerous, and Unix assumes you can put two and two together. Excuses. Inconsistent anything is a difficulty. The user of a system should not have to compensate in any capacity for the failure on the part of the system's designers to ensure consistency— of names of all things. That interactions between parts of the same system are so complex that it would be an act of generosity to document them is not the mark of a powerful system; it is the mark of a poorly designed one. And that's the thing: Unix is poorly designed. Maybe it was revolutionary nearly a half-century ago, but if someone unveiled an operating system, today, built on passing around and interpreting ASCII-encoded strings, with the occasional undecorated integer thrown in for kicks, they'd be laughed out of the room. >Thanks to this "lowest-common-denominator" type of interface design, ease-of-use seems to have massively replaced learning, dissuading and distancing users from having control of their machines at a time when such control is becoming increasingly important. This is happening, to a degree. However, there is a very important distinction to be made between the sort of "ease of use" that comes from reducing a system to a minimal high-level mode of interaction, and the sort of "ease of use" that comes from fixing the mistakes of previous iterations of the interaction model. Replacing the process of learning the aforementioned inconsistencies, pitfalls, and general frustrating complexities of Unix and its descendants with a system of equal or greater power that is genuinely easier to use is not a bad thing. It's just really, really freaking difficult. Or at least, no one seems to have done it yet.