The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: scj@yaccman.com (Steve Johnson)
Subject: [TUHS] Another "craft" discussion topic - mindless tool proliferation
Date: Sun, 24 Sep 2017 17:16:58 -0700	[thread overview]
Message-ID: <4e62b8b04bb14972d8602909510e20f3bafac7be@webmail.yaccman.com> (raw)
In-Reply-To: <20170924225443.E33121F975@orac.inputplus.co.uk>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4205 bytes --]

One of the best conferences I ever attended was a Usenix conference on
Little Languages, held in Santa Fe, NM.  I had the pleasure of going
out for dinner with a group that included Larry Wall and John
Ousterhout, inventors of Perl and TCL, respectively.  It was a
fascinating discussion.

Larry looked at Perl as if it were a natural language.  Just as
English has borrowed words, phrases and even syntax from other
languages, Larry's view was that if it was useful and the language
didn't already have it, toss it in.  John came from a more
mathematical (and, may I say, Unix) point of view.  Small is
beautiful, etc.  The original motivation for TCL was to allow one
process to dynamically send data to another process and get data back,
so, for example, an application could send editor commands to an
editor that would process them and return the result.  Kind of an RPC
at the process level, and, unlike pipes, the connections were
dynamic.  I'm not sure that ever worked in a useful way. TCL syntax
was quite clean and easy to learn.  But, for a lot of tasks, it
seemed to take a bit more TCL to do that task than Perl did.  On the
other hand, when building substantial applications I personally found
TCL much easier to work with -- the semantic clashes between different
parts of Perl were somewhat disorienting to me.

Ironically, of course, it was the TK graphics package of TCL that had
real legs.  System administrators found Perl  to be a good vehicle
for writing systems administration tools -- kind of like a shell with
useful data structures.  That meant that Perl was alive and well on
almost every Unix-oid system out there.  At the same time, writing
interactive graphics applications in TK was head and shoulders easier
than any other system out there, and it was very portable between
systems, but it was often harder to write the application that the
graphics was the interface for in TCL than in Perl.  And, as I'm sure
Larry would have wanted, the useful TK part migrated slowly but surely
into Perl, and the rest of TCL fell into disuse.

Steve

----- Original Message -----
From: "Ralph Corderoy" <ralph@inputplus.co.uk>
To:"Theodore Ts'o" <tytso at mit.edu>
Cc:<tuhs at minnie.tuhs.org>
Sent:Sun, 24 Sep 2017 23:54:43 +0100
Subject:Re: [TUHS] Another "craft" discussion topic - mindless tool
proliferation

 Hi Ted,

 > If you take a look at how perl handles its man pages, with 188 man
 > pages in section 1:

 Yes, I went there the other day looking for something and was
dismayed.
 The main reason being I learnt Perl thoroughly back when it was
 4.something from its single perl(1) lovingly crafted by Larry Wall. 

 Given Perl is, no was, an amalgam of Unix programming, this was
 perfectly possible to anyone that already new C, sh, sed, awk, grep,
 etc., and the man page ran smoothly, assuming all that background
 knowledge.

 Perl 5 broke this a bit with its addition of classes, and the shift
to
 POD; still overseen by Wall. Since then, with Larry's attention
 elsewhere, it seems they've revelled in TMTOWTDI and the
documentation
 has bloated so it appeared to me, looking for a reference, that there
 several possible man pages where it might be. Looking through those,
a
 lot of content seem duplicated, but slightly different, and I quickly
 gave up.

 > I find that info system, with its hypertext linking, to be far more
 > convenient.

 One nice thing about info(1) in the last few years is they've ditched
 printing to stderr what bit of formatting they're doing, removing the
 need for a `Gg' in `info libc | less' to make it do that work by
seeking
 to the end and then erase the clutter by jumping back to the
beginning.

 > And the question is whether man is a sufficient way to provide
 > documentation.

 As others have pointed out, it wasn't the sole source of
documentation;
 papers for bigger programs used to provide the introduction and
overview
 leaving the man page to mop up as a reference.

 -- 
 Cheers, Ralph.
 https://plus.google.com/+RalphCorderoy


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170924/dc8d7e93/attachment-0001.html>


  reply	other threads:[~2017-09-25  0:16 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 [this message]
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=4e62b8b04bb14972d8602909510e20f3bafac7be@webmail.yaccman.com \
    --to=scj@yaccman.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).