The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Alan Glasser <alanglasser@gmail.com>
To: Larry McVoy <lm@mcvoy.com>
Cc: TUHS main list <tuhs@minnie.tuhs.org>
Subject: Re: [TUHS] Book Recommendation [ reallly inscrutable languages ]
Date: Fri, 19 Nov 2021 16:48:40 -0500	[thread overview]
Message-ID: <CALpTLGpsWL_YD2sJZRXcyRSmhdg6X+SG0cafN29T8Xv7BeAHNw@mail.gmail.com> (raw)
In-Reply-To: <20211119201447.GF15051@mcvoy.com>

[-- Attachment #1: Type: text/plain, Size: 5290 bytes --]

Larry,

I have been out of working (retired from AT&T Labs Research in 2013), let
alone working on SCCS and related tools for quite a while.
I'm happy to hear that some folks appreciated what I called "INEX" (for
include/exclude); one of my contributions to SCCS.
I've had to argue against RCS and, of course, deal with CVS, much to my
chagrin.
Are you familiar with the concept of SCCS ID lists (slists), which act as a
table of contents of a "unit" (usually a library or load module)?
Not much released (from the Labs) documentation on slists; one paper was
way back in COMSAC 80 by three former co-workers: Gene Cristofor, Tim Wendt
and Bud Wonsiewicz.

Alan

P.S. Sounds like I should learn more about BitKeeper.


On Fri, Nov 19, 2021 at 3:14 PM Larry McVoy <lm@mcvoy.com> wrote:

> All the time.  A merge in BitKeeper (which is SCCS based, I rewrote SCCS
> from scratch and evolved it quite a bit) is just a
>
> get -e -ir1,r2,r3,r4
>
> where the include list is all the revs on the branch being merged.
>
> That's the beauty of SCCS that seems to be lost to the rest of the
> world:  if someone added N bytes on the branch, the merge passes that
> to the trunk by *reference*, every other SCM that is in current use
> copies the branch data to the trunk.
>
> Suppose Rob had done a bunch of important work on the branch, you had
> done some work on the trunk, and for whatever reason, I merged Rob's
> work.  Let's say everything automerged.  In SCCS or BitKeeper, the only
> new data in the file is a merge node that says "Include all of Rob's
> work".  In all other systems in use today, there would be a merge node
> with another copy of Rob's work with me as the author because I did
> the merge.  Blech.
>
> Strangely enough, ClearCase has a weave format like SCCS and they could
> have done merges by reference and they choose to copy it.  I dunno who
> the idiot was that made that decision.
>
> On Fri, Nov 19, 2021 at 03:04:37PM -0500, Alan Glasser wrote:
> > Larry,
> >
> > Did you ever try the -i or -x options on get(1) to include or exclude
> > deltas?
> >
> > Alan
> >
> >
> > On Wed, Nov 17, 2021 at 7:39 PM Larry McVoy <lm@mcvoy.com> wrote:
> >
> > > I'll defend perl, at least perl4, vigorously.  I wrote a lot of code in
> > > it on 20mhz SPARCs.  Yeah, like any kitchen sink language you have to
> > > develop a style, but it is possible.  All of Solaris 2.0 development
> > > happened under a source management system I wrote, NSElite, that was
> > > almost 100% perl4.  There was one C program, that Marc might like,
> > > that took 2 SCCS files that had the initial part of the graph in
> > > common but the recent nodes were different in each file, and zippered
> > > them together into a new SCCS file that had the newer nodes on a
> > > branch.  It was F.A.S.T compared to the edit/delta cycles you'd
> > > do if you did it by hand.
> > >
> > > My perl4 was maintainable, I fixed bugs in it quickly.
> > >
> > > When it happened, perl4 was a God send, as much as I love awk, perl
> > > was far more useful for stuff that awk just didn't want to handle.
> > >
> > > On Thu, Nov 18, 2021 at 09:21:49AM +1100, Rob Pike wrote:
> > > > Perl certainly had its detractors, but for a few years there it was
> the
> > > > lingua franca of system administration.
> > > >
> > > > -rob
> > > >
> > > >
> > > > On Thu, Nov 18, 2021 at 8:21 AM Dan Cross <crossd@gmail.com> wrote:
> > > >
> > > > > On Wed, Nov 17, 2021 at 3:54 PM Warner Losh <imp@bsdimp.com>
> wrote:
> > > > >
> > > > >> On Wed, Nov 17, 2021, 1:48 PM Dan Stromberg <drsalists@gmail.com>
> > > wrote:
> > > > >>
> > > > >>> On Wed, Nov 17, 2021 at 11:35 AM Norman Wilson <norman@oclsc.org
> >
> > > wrote:
> > > > >>>
> > > > >>>> Wasn't Perl created to fill this void?
> > > > >>>>
> > > > >>>> Void? I thought Perl was created to fill a much-needed gap.
> > > > >>>>
> > > > >>> There was and is a need for something to sit between Shell and C.
> > > But
> > > > >>> it needn't be filled by Perl.
> > > > >>>
> > > > >>> The chief problem with Perl, as I see it, is it's like 10
> languages
> > > > >>> smashed together.  To write it, you only need to know one of the
> > > 10.  But
> > > > >>> to read it, you never know what subset you're going to see until
> > > you're
> > > > >>> deep in the code.
> > > > >>>
> > > > >>> Perl is the victim of an experiment in exuberant, Opensource
> design,
> > > > >>> where the bar to adding a new feature was troublingly low.
> > > > >>>
> > > > >>> It was undeniably influential.
> > > > >>>
> > > > >>
> > > > >> It's what paved the way for python to fill that gap...
> > > > >>
> > > > >
> > > > > I feel that Perl, and to a lesser extent Tcl, opened the floodgates
> > > for a
> > > > > number of relatively lightweight "scripting" languages that sat
> > > between C
> > > > > and the shell in terms of their functionality and expressive power.
> > > From
> > > > > that group, the one I liked best was Ruby, but it got hijacked by
> > > Rails and
> > > > > Python swooped in and stole its thunder.
> > > > >
> > > > >         - Dan C.
> > > > >
> > > > >
> > >
> > > --
> > > ---
> > > Larry McVoy                  lm at mcvoy.com
> > > http://www.mcvoy.com/lm
> > >
>
> --
> ---
> Larry McVoy                  lm at mcvoy.com
> http://www.mcvoy.com/lm
>

[-- Attachment #2: Type: text/html, Size: 7675 bytes --]

  reply	other threads:[~2021-11-19 21:51 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-16 17:00 [TUHS] Book Recommendation Douglas McIlroy
2021-11-16 17:54 ` [TUHS] Book Recommendation [ reallly inscrutable languages ] Jon Steinhart
2021-11-16 17:57   ` Ron Natalie
2021-11-16 18:00   ` Dan Cross
2021-11-16 18:04   ` Larry McVoy
2021-11-16 19:53     ` Richard Salz
2021-11-16 20:05       ` Warner Losh
2021-11-17 19:12   ` Norman Wilson
2021-11-17 20:46     ` Dan Stromberg
2021-11-17 20:52       ` Warner Losh
2021-11-17 21:17         ` Dan Cross
2021-11-17 22:21           ` Rob Pike
2021-11-18  0:35             ` Larry McVoy
2021-11-19 20:04               ` Alan Glasser
2021-11-19 20:14                 ` Larry McVoy
2021-11-19 21:48                   ` Alan Glasser [this message]
2021-11-19 22:28                     ` Larry McVoy
2021-11-19 23:17               ` Alan Glasser
2021-11-18 21:03             ` George Michaelson
2021-11-18 21:39               ` Rob Pike
2021-11-17 22:36     ` Bakul Shah
2021-11-18  0:56       ` Dan Stromberg
     [not found] ` <CAKH6PiXinxBQGRqoeGMcG9CwTA5BNeU-LY164f-ZLYA4obsyuA@mail.g mail.com>
2021-11-16 18:47   ` [TUHS] Book Recommendation John Foust via TUHS
2021-11-16 20:35 ` Bakul Shah
2021-12-02 21:35 ` Duncan Mak
2021-12-02 22:32   ` Bakul Shah
2021-12-02 22:34   ` Rob Pike
2021-11-16 19:29 [TUHS] Book Recommendation [ reallly inscrutable languages ] Douglas McIlroy
2021-11-16 19:54 ` Jon Steinhart
2021-11-18 18:47 Paul Ruizendaal via TUHS
2021-11-18 19:03 ` arnold
2021-11-18 19:16   ` Chet Ramey
2021-11-18 19:20     ` arnold
2021-11-18 21:03   ` John Cowan
2021-11-18 21:42 ` Rich Morin
2021-11-18 22:59 Nelson H. F. Beebe

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=CALpTLGpsWL_YD2sJZRXcyRSmhdg6X+SG0cafN29T8Xv7BeAHNw@mail.gmail.com \
    --to=alanglasser@gmail.com \
    --cc=lm@mcvoy.com \
    --cc=tuhs@minnie.tuhs.org \
    /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).