From: Larry McVoy <lm@mcvoy.com>
To: Alan Glasser <alanglasser@gmail.com>
Cc: TUHS main list <tuhs@minnie.tuhs.org>
Subject: Re: [TUHS] Book Recommendation [ reallly inscrutable languages ]
Date: Fri, 19 Nov 2021 12:14:47 -0800 [thread overview]
Message-ID: <20211119201447.GF15051@mcvoy.com> (raw)
In-Reply-To: <CALpTLGq6yg398w06J89WgKLec_O7ovet776rPEeb6x_1Yzefbg@mail.gmail.com>
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
next prev parent reply other threads:[~2021-11-19 20:17 UTC|newest]
Thread overview: 38+ 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-17 22:31 ` [COFF] " Adam Thornton
2021-11-17 22:46 ` Bakul Shah
2021-11-18 0:35 ` Larry McVoy
2021-11-19 20:04 ` Alan Glasser
2021-11-19 20:14 ` Larry McVoy [this message]
2021-11-19 21:48 ` Alan Glasser
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=20211119201447.GF15051@mcvoy.com \
--to=lm@mcvoy.com \
--cc=alanglasser@gmail.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.
Code repositories for project(s) associated with this external index
https://git.vuxu.org/mblaze/
https://git.vuxu.org/mirror/zsh/
https://git.vuxu.org/mirror/musl/
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.