On Mon, Jun 12, 2023 at 7:50 PM G. Branden Robinson <
g.branden.robinson@gmail.com> wrote:

> 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.