19 Nov
2018
19 Nov
'18
9:35 p.m.
On Sun, Nov 18, 2018 at 10:11 PM Jon Steinhart <jon(a)fourwinds.com> wrote:
Sort of like Americans expecting others to speak to
them in English when
they travel instead of understanding that they're in a different
environment and it makes more sense to learn the culture as it's unlikely
that everybody is gonna change just for you.
Amen, brother Jon, can we get another Amen..
This is not a unique problem with man vs info. I see
it in the large
number of different make utilities, package managers, and so on that
really don't provide new functionality but do make it much harder to be a
practitioner since one has a lot more stuff to learn for no real benefit.
Exactly!!
So were it me, I would have looked at the current culture in the UNIX
environment and figured out how it gracefully extend it for new
functionality. To me, that's
a mark of good engineering instead of being a bull in a china shop.
I referred to this previously as the principle of 'least astonishment.'
Again - the argument for doing what he (and his followers did was) 'Gnu is
Not Unix' - but my reply is that they created UNIX when they were done.
They road the research train, then BSD rode the same UNIX train to start
and now ride the UNIX look/work alike, Linux, rides it still. And
because it was incremental on the past, we get more behind it.
A much as I'm live and left live, and to each her/his own -- if GNU had
been a new system, then I might be a lot more willing to accept that the
argument. But what was build was (and is) not. GNU is just the current
and expanded UNIX implementation. And the so its have the man page being
useless and expecting people to use info in just wrong. Even if you are
used it it (ok, so you found English speakers when you travelled).
And Ted is not that I don't use the unix documents (full papers) - hey I
do. That is how I learned to use 'make' when it appeared (or C for that
matter) from documents in /usr/doc. \
What started this whole thread was Doug's comment about how succinct and
to the point man was. If was a fine interface for >>UNIX<<. Man (using
roff) was what people expect. It's not about better or worse -- it worked
and worked well.
As I said, if man had been maintained as the primary >>manual<< style
interface and /usr/doc/<PROG>/foo.ms as the primary scheme (which
>>IS<<
what BSD did), then you don't fail the rule of least astonishment. Then
create a *roff -Tinfo | info_create backend, that produced the info files;
those that want it, get it and love it. Those that >>expect<< man to work
because its UNIX, get what they expect. No one is 'astonished.'
A good example of that in a different field is the way in which FM stereo
was finessed in such a
way as to not break existing mono receivers. Would have been easy to just
toss it
and make everybody buy new gear, but I prefer the more elegant solution.
Yep. Metcalfe's Law -- adding too and improving on the past; makes more
people happy. Yep, it is sometimes 'harder ' for the developer and some
compromises do result. But the result is a bigger pie and happier group
in total. Think of the contemporary system to Linux (including Plan9 for
the matter) -- which were 'better' and which are we still using. Its not
that there are not good ideas.
The 'better than' argument fails when the difference ('betterness')
is
shallow and not something that really is remarkable (I like it and use it
is not good enough). Respecting the past and ensuring the 'old ways' work
is good business. And that is the problem. When you are the creator of
the alternate scheme, its hard to not understand how much better something
is. Being different and better >>sometimes<< can pay off (check out: –Bret
Victor’s: The Future of Programming:
https://www.youtube.com/watch?v=8pTEmbeENF4 –His talk in 2013, but set and
presented it as if he were talking in the 1970s); but if you look each of
these things he is talking about is remarkably different -- man vs. info
(or ed/vi vs teco/emacs for that matter, I'm not sure really are/were).
Clem
ᐧ
ᐧ