The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: jon@fourwinds.com (Jon Steinhart)
Subject: [TUHS] Another "craft" discussion topic - mindless tool proliferation
Date: Tue, 19 Sep 2017 10:01:57 -0700	[thread overview]
Message-ID: <201709191701.v8JH1vck032168@darkstar.fourwinds.com> (raw)

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.

I suppose that it was trailblazing in that it broke manual pages up into
sections that couldn't easily be viewed concurrently long before the www and
web pages that broke things up into multiple pages to make room for more ads.

Any benefits that texinfo might have are completely lost by the introduction
of multiple non-intersecting ways to find documentation.

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.

A funny example of this is when I was consulting for Xilinx in the late 80s
on a project that had to run on both Suns and PCs.  Naturally, I did the
development on a Sun and ported to the PC later.  When it came time to do
the port, a couple of the employees proudly came to me and told me about
this wonderful program that they wrote that was absolutely necessary for
doing the PC build.  I was completely puzzled and told them that I already
had the PC build complete.  They told me that that couldn't be possible
since I didn't use their wonderful utility.  Turns out that their utility
wrote out all of the make dependencies for the PC.  I, of course, wrote a
.c.obj rule which was all that it took.  They were excessively angry at me
for inadvertently making them look like fools that they were.

Another example is a more recent web-based project on which I was advising.
I'm a big fan of jQuery; it gets the job done.  Someone said "Why are you
using that instead of angular?"  I did a bit of research before answering.
Turns out that one of the main reasons given for angular over jQuery was
that "it's fresh".  That was a new one for me.  Still unclear why freshness
is an attribute that would trump stability.

So, I'm sure that many of you have stories about unnecessary tools and
packages that were created by people unable to RTFM.  Would be amused
to hear 'em.

Jon


             reply	other threads:[~2017-09-19 17:01 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-19 17:01 Jon Steinhart [this message]
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
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=201709191701.v8JH1vck032168@darkstar.fourwinds.com \
    --to=jon@fourwinds.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).