16 Nov
2021
16 Nov
'21
11 p.m.
> The former notation C(B(A)) became A->B->C.
This was PL/I's gift to C.
You seem to have a gift for notation. That's
rare. Curious what you think of APL?
I take credit as a go-between, not as an inventor. Ken Knowlton
introduced the notation ABC in BEFLIX, a pixel-based animation
language. Ken didn't need an operator because identifiers were single
letters. I showed Ken's scheme to Bud Lawson, the originator of PL/I's
pointer facility. Bud liked it and came up with the vivid -> notation
to accommodate longer identifiers.
If I had a real gift of notation I would have come up with the pipe
symbol. In my original notation ls|wc was written ls>wc>. Ken Thompson
invented | a couple of months later. That was so influential that
recently, in a paper that had nothing to do with Unix, I saw |
referred to as the "pipe character"!
APL is a fascinating invention, but can be so compact as to be
inscrutable. (I confess not to have practiced APL enough to become
fluent.) In the same vein, Haskell's powerful higher-level functions
make middling fragments of code very clear, but can compress large
code to opacity. Jeremy Gibbons, a high priest of functional
programming, even wrote a paper about deconstructing such wonders for
improved readability.
Human impatience balks at tarrying over a saying that puts so much in
a small space. Yet it helps once you learn it. Try reading transcripts
of medieval Arabic algebra carried out in words rather than symbols.
Iverson's hardware descriptions in APL are another case where
symbology pays off.
Doug
16 Nov
16 Nov
11:54 p.m.
New subject: Book Recommendation [ reallly inscrutable languages ]
Douglas McIlroy writes:
APL is a fascinating invention, but can be so compact
as to be
inscrutable. (I confess not to have practiced APL enough to become
fluent.) In the same vein, Haskell's powerful higher-level functions
make middling fragments of code very clear, but can compress large
code to opacity. Jeremy Gibbons, a high priest of functional
programming, even wrote a paper about deconstructing such wonders for
improved readability.
Wasn't Perl created to fill this void?
11:57 p.m.
New subject: Book Recommendation [ reallly inscrutable languages ]
Awk bailing out near line 1.
------ Original Message ------
From: "Jon Steinhart" <jon(a)fourwinds.com>
To: "TUHS main list" <tuhs(a)minnie.tuhs.org>
Sent: 11/16/2021 12:54:16 PM
Subject: Re: [TUHS] Book Recommendation [ reallly inscrutable languages
]
Douglas McIlroy writes:
APL is a fascinating invention, but can be so
compact as to be
inscrutable. (I confess not to have practiced APL enough to become
fluent.) In the same vein, Haskell's powerful higher-level functions
make middling fragments of code very clear, but can compress large
code to opacity. Jeremy Gibbons, a high priest of functional
programming, even wrote a paper about deconstructing such wonders for
improved readability.
Wasn't Perl created to fill this void? 
17 Nov
17 Nov
midnight
New subject: Book Recommendation [ reallly inscrutable languages ]
On Tue, Nov 16, 2021 at 12:57 PM Jon Steinhart <jon(a)fourwinds.com> wrote:
Douglas McIlroy writes:
I thought Perl was a reaction to exceeding awk's tolerance for abuse?
- Dan C.
APL is a fascinating invention, but can be so
compact as to be
inscrutable. (I confess not to have practiced APL enough to become
fluent.) In the same vein, Haskell's powerful higher-level functions
make middling fragments of code very clear, but can compress large
code to opacity. Jeremy Gibbons, a high priest of functional
programming, even wrote a paper about deconstructing such wonders for
improved readability.
Wasn't Perl created to fill this void?
12:04 a.m.
New subject: Book Recommendation [ reallly inscrutable languages ]
On Tue, Nov 16, 2021 at 09:54:16AM -0800, Jon Steinhart wrote:
Douglas McIlroy writes:
My belief is that perl was written to replace a lot of Unix pipelines,
which are awesome when you discover them but less awesome as they become
complex (error handling in a pipeline is pretty tricky if you actually
want to handle stuff nicely).
I was a huge fan of Perl 4, still am, wrote a source management system
in it while at Sun. It wanted you to be pretty disciplined in how you
wrote it or it becomes write only, but if you are, it was really pleasant.
--
---
Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
APL is a fascinating invention, but can be so
compact as to be
inscrutable. (I confess not to have practiced APL enough to become
fluent.) In the same vein, Haskell's powerful higher-level functions
make middling fragments of code very clear, but can compress large
code to opacity. Jeremy Gibbons, a high priest of functional
programming, even wrote a paper about deconstructing such wonders for
improved readability.
Wasn't Perl created to fill this void? 
2:05 a.m.
New subject: Book Recommendation [ reallly inscrutable languages ]
On Tue, Nov 16, 2021 at 12:55 PM Richard Salz <rich.salz(a)gmail.com> wrote:
My belief is that perl was written to replace a lot of Unix pipelines,
This is true. I heard it from Larry himself :)
It's certainly what his posts from the time said: Perl was written to cope
with the hodge-podge
of awk / sed / etc scripts that grew in complexity, but not quite having
the power to solve
the problems past a certain point in complexity in an understandable,
digestible way. Perl
was designed to provide an 'all of the above' language that gave a better
framework to
the pipelining and data processing and transformation than shell + sed +
awk could with
its disparate utilities.
One can debate the extent to which these goals were fulfilled, of course,
but that's
what Larry was saying on USENET in the late 80s.
Warner
18 Nov
18 Nov
1:12 a.m.
New subject: Book Recommendation [ reallly inscrutable languages ]
Wasn't Perl created to fill this void?
Void? I thought Perl was created to fill a much-needed gap.
Norman Wilson
Toronto ON
Not an awk maintainer
2:46 a.m.
New subject: Book Recommendation [ reallly inscrutable languages ]
On Wed, Nov 17, 2021 at 11:35 AM Norman Wilson <norman(a)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.
2:52 a.m.
New subject: Book Recommendation [ reallly inscrutable languages ]
On Wed, Nov 17, 2021, 1:48 PM Dan Stromberg <drsalists(a)gmail.com> wrote:
On Wed, Nov 17, 2021 at 11:35 AM Norman Wilson <norman(a)oclsc.org> wrote:
It's what paved the way for python to fill that gap...
Warner
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.
3:17 a.m.
New subject: Book Recommendation [ reallly inscrutable languages ]
On Wed, Nov 17, 2021 at 3:54 PM Warner Losh <imp(a)bsdimp.com> wrote:
On Wed, Nov 17, 2021, 1:48 PM Dan Stromberg
<drsalists(a)gmail.com> wrote:
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.
On Wed, Nov 17, 2021 at 11:35 AM Norman Wilson
<norman(a)oclsc.org> wrote:
It's what paved the way for python to fill that gap...
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.
4:21 a.m.
New subject: Book Recommendation [ reallly inscrutable languages ]
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(a)gmail.com> wrote:
On Wed, Nov 17, 2021 at 3:54 PM Warner Losh
<imp(a)bsdimp.com> wrote:
On Wed, Nov 17, 2021, 1:48 PM Dan Stromberg
<drsalists(a)gmail.com> wrote:
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.
On Wed, Nov 17, 2021 at 11:35 AM Norman Wilson
<norman(a)oclsc.org> wrote:
It's what paved the way for python to fill that gap...
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.
6:35 a.m.
New subject: Book Recommendation [ reallly inscrutable languages ]
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(a)gmail.com> wrote:
> On Wed, Nov 17, 2021 at 3:54 PM Warner Losh <imp(a)bsdimp.com> wrote:
>
>> On Wed, Nov 17, 2021, 1:48 PM Dan Stromberg <drsalists(a)gmail.com> wrote:
>>
>>> On Wed, Nov 17, 2021 at 11:35 AM Norman Wilson <norman(a)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
20 Nov
20 Nov
2:04 a.m.
New subject: Book Recommendation [ reallly inscrutable languages ]
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(a)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(a)gmail.com> wrote:
> On Wed, Nov 17, 2021 at 3:54 PM Warner Losh <imp(a)bsdimp.com> wrote:
>
>> On Wed, Nov 17, 2021, 1:48 PM Dan Stromberg <drsalists(a)gmail.com>
wrote:
>>
>>> On Wed, Nov 17, 2021 at 11:35 AM Norman Wilson <norman(a)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
2:14 a.m.
New subject: Book Recommendation [ reallly inscrutable languages ]
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(a)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(a)gmail.com> wrote:
> >
> > > On Wed, Nov 17, 2021 at 3:54 PM Warner Losh <imp(a)bsdimp.com> wrote:
> > >
> > >> On Wed, Nov 17, 2021, 1:48 PM Dan Stromberg
<drsalists(a)gmail.com>
> wrote:
> > >>
> > >>> On Wed, Nov 17, 2021 at 11:35 AM Norman Wilson
<norman(a)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
3:48 a.m.
New subject: Book Recommendation [ reallly inscrutable languages ]
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(a)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:
> 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
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(a)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(a)gmail.com> wrote:
> >
> > > On Wed, Nov 17, 2021 at 3:54 PM Warner Losh <imp(a)bsdimp.com>
wrote:
>
>> On Wed, Nov 17, 2021, 1:48 PM Dan Stromberg <drsalists(a)gmail.com>
wrote:
> >>
> >>> On Wed, Nov 17, 2021 at 11:35 AM Norman Wilson <norman(a)oclsc.org
> > >>> 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
4:28 a.m.
New subject: Book Recommendation [ reallly inscrutable languages ]
Hi Alan (and others, should this move to COFF?)
I'm happy to hear that some folks appreciated
what I called "INEX" (for
include/exclude); one of my contributions to SCCS.
You just got yourself a big fan, anyone who had the insight to add includes
and excludes to SCCS is a smart cookie, thank you for those, BitKeeper makes
heavy use of them.
I've had to argue against RCS and, of course,
deal with CVS, much to my
chagrin.
You and me both.
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)?
That sounds like BitKeeper's ChangeSet file. BitKeeper's model is
repository based, a repository is a collection of SCCS files that are
all managed as a unit. It doesn't work this way but you could think
of the original content of the ChangeSet file as
src/foo.c 1.1
man/foo.1 1.1
It is <pathname> <revision>
The ChangeSet file is itself versioned so lets say you added a file,
then version 1.2 of the ChangeSet file is
src/foo.c 1.1
man/foo.1 1.1
examples/foo.eg 1.1
Because pathnames can change (BitKeeper has pathnames versioned just like
the content is version) we had to come up with a non-changing name for
pathnames (think inode # but it has to be globally unique). Ditto for
revisions, they get changed all the time because of merges.
BitKeeper's internal names look like (you can skip this for now):
Inode:
lm(a)lm.bitmover.com|man/WhatIs|19980710174007|58324|a9558aeac091a142
or
user(a)host.domain|relative/path|date|chksum|64 bits of /dev/random
Revision:
lm(a)work.bitmover.com|man/WhatIs|20000205064107|58704
or
same as the inode but skip the 64 bits.
Getting back to useful stuff, you can clone a repository to any commit,
all that does is check out that version of the ChangeSet file and strips
off deltas until the tip matches the revision from that version of the
ChangeSet file.
BitKeeper was the first fully distributed SCM system, Git, Hg, et al,
are all inspired by BitKeeper (and would have done well to copy it more
closely, Git in particular is just awful). BitKeeper owes a tremendous
nod to SCCS, SCCS taught me the value of that file format.
--lm
5:17 a.m.
New subject: Book Recommendation [ reallly inscrutable languages ]
My 2 cents on Perl.
Having come up on Ken's original shell, the Mashey shell, the Bourne shell
and the Korn shell (and now bash), and a happy awk (and nawk) programmer, I
mostly avoided perl. But since many others didn't, I've found myself
needing to read perl code, which as Larry stated "It wanted you to be
pretty disciplined in how you wrote it or it becomes write only, but if you
are, it was really pleasant." Unfortunately, most open source that I
looked at felt to me like write only. Also, as Dave stated "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." Not good for a peruser of perl code (me). And what's with the
"special" or "magic" variables? Shades of IBM/OS; not at all
Unix-like.
From 1996 until 2013 (when I retired) I was lucky
enough to have a Perl
aficionado on my team and he spared me much grief.
Alan
On Wed, Nov 17, 2021 at 7:39 PM Larry McVoy <lm(a)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(a)gmail.com> wrote:
> On Wed, Nov 17, 2021 at 3:54 PM Warner Losh <imp(a)bsdimp.com> wrote:
>
>> On Wed, Nov 17, 2021, 1:48 PM Dan Stromberg <drsalists(a)gmail.com>
wrote:
>>
>>> On Wed, Nov 17, 2021 at 11:35 AM Norman Wilson <norman(a)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
19 Nov
19 Nov
3:03 a.m.
New subject: Book Recommendation [ reallly inscrutable languages ]
Interesting use of the past tense. I like to think this remains in the past
tense but I keep walking into sysadmin tasks where its (regrettably ?)
present.
G
On Thu, 18 Nov 2021, 8:24 am Rob Pike, <robpike(a)gmail.com> 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(a)gmail.com> wrote:
> On Wed, Nov 17, 2021 at 3:54 PM Warner Losh <imp(a)bsdimp.com> wrote:
>
>> On Wed, Nov 17, 2021, 1:48 PM Dan Stromberg <drsalists(a)gmail.com> wrote:
>>
>>> On Wed, Nov 17, 2021 at 11:35 AM Norman Wilson <norman(a)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.
>
>
3:39 a.m.
New subject: Book Recommendation [ reallly inscrutable languages ]
In my limited orbit, Ruby eventually displaced Perl for that, but as
to the default today, I don't know.
-rob
On Fri, Nov 19, 2021 at 8:06 AM George Michaelson <ggm(a)algebras.org> wrote:
Interesting use of the past tense. I like to think this remains in the past tense but I
keep walking into sysadmin tasks where its (regrettably ?) present.
G
On Thu, 18 Nov 2021, 8:24 am Rob Pike, <robpike(a)gmail.com> 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(a)gmail.com> wrote:
>>
>> On Wed, Nov 17, 2021 at 3:54 PM Warner Losh <imp(a)bsdimp.com> wrote:
>>>
>>> On Wed, Nov 17, 2021, 1:48 PM Dan Stromberg <drsalists(a)gmail.com>
wrote:
>>>>
>>>> On Wed, Nov 17, 2021 at 11:35 AM Norman Wilson <norman(a)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.
>>
18 Nov
18 Nov
4:36 a.m.
New subject: Book Recommendation [ reallly inscrutable languages ]
On Nov 17, 2021, at 11:12 AM, Norman Wilson <norman(a)oclsc.org> wrote:
Wasn't Perl created to fill this void?
Void? I thought Perl was created to fill a much-needed gap.
and tcl, rc etc.
I just want better builtin support for shell pipelines as
they are essentially (flat) list processors! As an example
consider something like the following:
find . -name '*.[hc]' -type f | \
xargs grep -l '\<foo\>' /dev/null | \
xargs grep -l '\<bar\>' /dev/null | \
xargs some-command
Just to run some-command on all *.[hc] files with words
foo & bar. And this will fall apart if there are spaces
or : in filenames. Basically most scripts are about
enumerating, filtering, converting and processing. If
files, especially text files, are so central to unix,
a shell should know about them and provide common
operations on them. One can even think of shell variables
as files (sort of like the env device in plan9). If you
want to name some sub-computation instead of processing it
all in one pipeline, it should be trivial but it isn't;
you have to find uniq names for these temp files and remember
to delete them when done. I want lexically scoped variables
(aka files) that disappear once you exist the scope!
The difficulty is in coming up with an intuitive, regular
& a relatively concise syntax. Even so it would likely be
unpopular since people seem to prefer for-loops!
6:56 a.m.
New subject: Book Recommendation [ reallly inscrutable languages ]
On Wed, Nov 17, 2021 at 2:40 PM Bakul Shah <bakul(a)iitbombay.org> wrote:
I just want better builtin support for shell pipelines
as
they are essentially (flat) list processors! As an example
consider something like the following:
find . -name '*.[hc]' -type f | \
xargs grep -l '\<foo\>' /dev/null | \
xargs grep -l '\<bar\>' /dev/null | \
xargs some-command
The GNU tools let you (for EG) :
find . -type f -print0 | xargs -0 egrep --null -il mypy | xargs -0 egrep
--null -il pylint > /tmp/mypy-and-pylint-hits
17 Nov
17 Nov
2:35 a.m.
New subject: Book Recommendation
On Nov 16, 2021, at 9:04 AM, Douglas McIlroy <douglas.mcilroy(a)dartmouth.edu> wrote:
APL is a fascinating invention, but can be so compact as to be
inscrutable. (I confess not to have practiced APL enough to become
fluent.) In the same vein, Haskell's powerful higher-level functions
make middling fragments of code very clear, but can compress large
code to opacity.
I enjoyed using APL in late ‘70s. And now I use and like k, another array
language. I am not fond of code golfing (fewest keystrokes win!) in these
languages but some problems are certainly easier to solve in them. It’s
like a workshop with a well thought out set of power tools. Similarly, a
lot of practice is necessary to use them effectively. When I get tired of
using grep, send, xargs in a shell pipeline I have wanted to write a shell
with similarly powerful builtin features….
3 Dec
3 Dec
3:35 a.m.
New subject: Book Recommendation
On Tue, Nov 16, 2021 at 12:04 PM Douglas McIlroy <
douglas.mcilroy(a)dartmouth.edu> wrote:
APL is a fascinating invention, but can be so compact as to be
inscrutable. (I confess not to have practiced APL enough to become
fluent.) In the same vein, Haskell's powerful higher-level functions
make middling fragments of code very clear, but can compress large
code to opacity. Jeremy Gibbons, a high priest of functional
programming, even wrote a paper about deconstructing such wonders for
improved readability.
I went looking for this paper by Jeremy Gibbons here:
https://dblp.org/pid/53/1090.html but didn't find anything resembling it.
What's the name of the paper?
--
Duncan.
4:32 a.m.
New subject: Book Recommendation
On Dec 2, 2021, at 1:35 PM, Duncan Mak
<duncanmak(a)gmail.com> wrote:
On Tue, Nov 16, 2021 at 12:04 PM Douglas McIlroy <douglas.mcilroy(a)dartmouth.edu>
wrote:
APL is a fascinating invention, but can be so compact as to be
inscrutable. (I confess not to have practiced APL enough to become
fluent.) In the same vein, Haskell's powerful higher-level functions
make middling fragments of code very clear, but can compress large
code to opacity. Jeremy Gibbons, a high priest of functional
programming, even wrote a paper about deconstructing such wonders for
improved readability.
I went looking for this paper by Jeremy Gibbons here: https://dblp.org/pid/53/1090.html
but didn't find anything resembling it.
What's the name of the paper?
The following paper seems APLicable here. Jeremy Gibbons also
gave a delightful talk on this.
https://www.47deg.com/media/2017/11/07/jeremy-gibbons-lambda-world-2017/
"APLicative Programming with Naperian Functors"
https://www.cs.ox.ac.uk/people/jeremy.gibbons/publications/aplicative.pdf
We show here that such a custom language design is
unnecessary: the requisite compatibility checks can
already be captured in modern expressive type systems, as
found for example in Haskell; moreover, generative
type-driven program- ming can exploit that static type
information constructively to automat- ically induce the
appropriate liftings. We show also that the structure of
multi-dimensional data is inherently a matter of Naperian
applicative functors -- lax monoidal functors, with
strength, commutative up to isomorphism under
composition -- that also support traversal.
4:34 a.m.
New subject: Book Recommendation
https://www.youtube.com/watch?v=ek1yjc9sSag
On Fri, Dec 3, 2021 at 8:39 AM Duncan Mak <duncanmak(a)gmail.com> wrote:
On Tue, Nov 16, 2021 at 12:04 PM Douglas McIlroy <douglas.mcilroy(a)dartmouth.edu>
wrote:
APL is a fascinating invention, but can be so compact as to be
inscrutable. (I confess not to have practiced APL enough to become
fluent.) In the same vein, Haskell's powerful higher-level functions
make middling fragments of code very clear, but can compress large
code to opacity. Jeremy Gibbons, a high priest of functional
programming, even wrote a paper about deconstructing such wonders for
improved readability.
I went looking for this paper by Jeremy Gibbons here: https://dblp.org/pid/53/1090.html
but didn't find anything resembling it.
What's the name of the paper?
--
Duncan.
1115
days inactive
1131
days old
25 comments
14 participants
participants (14)
-
Alan Glasser -
Bakul Shah -
Dan Cross -
Dan Stromberg -
Douglas McIlroy -
Duncan Mak -
George Michaelson -
Jon Steinhart -
Larry McVoy -
Norman Wilson -
Richard Salz -
Rob Pike -
Ron Natalie -
Warner Losh