The BSD advocates I knew back in the day suggested that this was my fault for not locating and apprenticing myself to such a master;
the guild mentality was, and in some ways still is, powerful there.
This is a fair point and is actually true of almost any system or, for that matter social setting, if you have a guide it's a lot easier to know what to do or fool people into thinking you do; Liza Doolittle style.
To bang an old drum of mine, while Unix culture pats itself on the back for economizing keystrokes with an ad hoc compression scheme for every
name in sight, it too often overlooks what discarded in pursuit of this form of minimality: clarity, lack of ambiguity, and ease of acquisition by newcomers.
Again fair - which is why I think losing things like the old UNIX (I think bwk originated) 'learn system' from the stock releases is a little sad. I used to tell newcomers - to spend an AM with learn and go through the files/more files/vi scripts and then come back to me, and I'll try to help you.
My line was that UNIX always had a more difficult learning curve than, say GUI based systems (or even some of the old DEC ones likes TOPS or VMS), but once you learned the tools and ideas, it was much simpler to use - made more sense (to me certainly). [Teach someone to fish, vs. give them one idea].
But as you point out, that only works if you have someone(s) to ask.
... when Bell Labs got the Blit, the limitations that motivated the original terseness were not only not discarded, but
retained and doubled down on.
Again a fair observation -- however, making_your_switches_so_verbose_no_one_can_remember_much_less_type_them_gnu style is just as bad.
Developing "good taste" is sometimes difficult. I'll not defend the "Unix room culture" or the later Plan9 folks (many of whom are my friends) - but I also get it. They were making something for themselves.
And here is where it gets tricky -- too many systems are designed to be the solution to too make problems by trying to learn and correct all past sins (Brook's "second-system effect") but fail because no one cares/uses them. The economics of switching are not there.
Frankly, when you build for yourself or, better yet, use what Tektronix called the "next bench" [1] idea, you often can find that happy compromise. Simple enough to learn but not a burden to use.
At least APL chose sigils that were tough to confuse with other things.
True, but you have not lived until someone brings a yellow piece of ASR33 paper into your office, and they are using the APL replacement operations and telling you this is this life's work -- 200 lines of APL - they think there is something wrong with the system. You have to decode the program and tell them they used the wrong operator. ... or better, they actually were right but you can not reproduce the error without their program and datasets.
Best wishes,
Clem
[1] Tektronix's "Next Bench" - was a simple idea. They were an instrumentation company made up of EE primarily. Everyone had work benches, not desks, to work on their projects. The idea was if you saw a colleague the "next bench over" struggling with solving a problem and you could think of a tool or test to help them solve it, chances are pretty good other people were having the same issue. So, if you make it easy to use and become available, you will have a product and it is likely to be popular. The key points: solve a problem, is easy to use, and made available.