From: clemc@ccc.com (Clem Cole)
Subject: [TUHS] Another "craft" discussion topic - mindless tool proliferation
Date: Wed, 20 Sep 2017 14:15:01 -0400 [thread overview]
Message-ID: <CAC20D2NKC-JdpUkbUqHEJY7d5z1gYi8kwV5axg2h+uD53LE4Qw@mail.gmail.com> (raw)
In-Reply-To: <201709191701.v8JH1vck032168@darkstar.fourwinds.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2874 bytes --]
I fear this thread drifted from Jon's point about improving a tool, instead
of replacing it.
On Tue, Sep 19, 2017 at 1:01 PM, Jon Steinhart <jon at fourwinds.com> wrote:
> OK, here's another one that's good for chest thumping...
>
> I am not a fan of texinfo. It doesn't provide any benefits (to me) over
> man.
>
Amen...
To me this was just rms trying to inflict ITS/emacs on Unix. Lars points
out info is just ITS format, the tool is just emacs commands.
The key was that here was a case where the UNIX solution (man) was
perfectly reasonable, worked very well. But it was not the likely and in
the right flavor of rms.
> This is a systemic problem. I have a section in my book-in-progress where
> I
> talk about being a "good programming citizen". One of the things that I
> say
> is:
>
> Often there is a tool that does most of what you need but is lacking
> some feature or other. Add that feature to the existing tool;
> don't just write a new one. The problem with writing a new one
> is that, as a tool user, you end up having to learn a lot of tools
> that perform essentially the same function. It's a waste of time
> an energy. A good example is the make utility (invented by Stuart
> Feldman at Bell Labs in 1976) that is used to build large software
> packages. As time went on, new features were needed. Some were
> added to make, but many other incompatible utilities were created that
> performed similar functions. Don't create burdens for others.
> Improve existing tools if possible.
Which is exactly your point. I think you are spot on here. Instead of
rms trying to learn to use Unix the way, he inflicted the ITS/emacs way
because he thought it was ``better.'' Which is a tad arrogant.
I have noted that the folks that don't mind and/or like info, are regular
emacs users.
Someone like me, who can use emacs, but does not find it the only thing (I
could switch between RPN - HP style and algebraic - TI calculators too),
just find texinfo to be an annoyance. It's different and one extra place
to look. As Jon said, it does not provide any benefits and in fact is a
detraction because it means the standard Unix tools like apropros does not
index it.
Larry has right idea, with his webroff. Make html when it is appropriate
I also think, man pages are man pages and not user manuals. The Perl
example was classic. We did not learn C from the man page. What we got
in the C man page was how to run it. There was a manual (doc) for the
language. That should have been a manual (in -ms macros) and then run
through Larry's webroff and properly indexed.
Then you get everything.
Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170920/c61c9434/attachment.html>
next prev parent reply other threads:[~2017-09-20 18:15 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-19 17:01 Jon Steinhart
2017-09-19 17:05 ` Steve Nickolas
2017-09-19 20:31 ` Pete Turnbull
2017-09-19 20:37 ` Warner Losh
2017-09-19 23:35 ` Theodore Ts'o
2017-09-20 0:47 ` Lyndon Nerenberg
2017-09-20 1:02 ` Larry McVoy
2017-09-20 1:09 ` Lyndon Nerenberg
2017-09-20 1:13 ` Larry McVoy
2017-09-20 1:22 ` Larry McVoy
2017-09-20 2:01 ` Larry McVoy
2017-09-20 2:34 ` Bakul Shah
2017-09-20 2:47 ` Larry McVoy
2017-09-20 6:18 ` Bakul Shah
2017-09-20 4:35 ` Grant Taylor
2017-09-20 5:54 ` Ian Zimmerman
2017-09-24 23:03 ` Ralph Corderoy
2017-09-24 23:35 ` Bakul Shah
2017-09-20 16:49 ` Steffen Nurpmeso
2017-09-20 4:29 ` Grant Taylor
2017-09-20 6:43 ` Peter Jeremy
2017-09-20 8:25 ` Bakul Shah
2017-09-20 9:12 ` Steve Nickolas
2017-09-20 9:34 ` Bakul Shah
2017-09-20 16:48 ` Steffen Nurpmeso
2017-09-20 2:07 ` Theodore Ts'o
2017-09-24 22:58 ` Ralph Corderoy
2017-09-20 4:26 ` Grant Taylor
2017-09-20 16:45 ` Steffen Nurpmeso
2017-09-21 17:33 ` Tony Finch
2017-09-21 18:39 ` Steffen Nurpmeso
2017-09-22 0:02 ` Greg 'groggy' Lehey
2017-09-22 0:30 ` Lyndon Nerenberg
2017-09-22 0:38 ` Larry McVoy
2017-09-22 0:39 ` Lyndon Nerenberg
2017-09-22 0:50 ` Larry McVoy
2017-09-22 1:01 ` Lyndon Nerenberg
2017-09-22 1:08 ` Larry McVoy
2017-09-22 20:09 ` [TUHS] remaking make (Re: " Bakul Shah
2017-09-22 2:25 ` [TUHS] " Warner Losh
2017-09-22 3:26 ` Greg 'groggy' Lehey
2017-09-22 4:09 ` ron minnich
2017-09-22 2:20 ` Warner Losh
2017-09-22 0:36 ` Larry McVoy
2017-09-22 0:40 ` Lyndon Nerenberg
2017-09-22 1:53 ` Michael Parson
2017-09-22 3:25 ` Grant Taylor
2017-09-20 6:20 ` Lars Brinkhoff
2017-09-20 16:39 ` Steffen Nurpmeso
2017-09-24 22:54 ` Ralph Corderoy
2017-09-25 0:16 ` Steve Johnson
2017-09-25 11:30 ` Ralph Corderoy
2017-09-20 18:15 ` Clem Cole [this message]
2017-09-20 18:35 ` Jon Steinhart
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAC20D2NKC-JdpUkbUqHEJY7d5z1gYi8kwV5axg2h+uD53LE4Qw@mail.gmail.com \
--to=clemc@ccc.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).