The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* Re: [TUHS] Book Recommendation
@ 2021-11-16 17:00 Douglas McIlroy
  2021-11-16 17:54 ` [TUHS] Book Recommendation [ reallly inscrutable languages ] Jon Steinhart
                   ` (3 more replies)
  0 siblings, 4 replies; 36+ messages in thread
From: Douglas McIlroy @ 2021-11-16 17:00 UTC (permalink / raw)
  To: TUHS main list

>> 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

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [TUHS] Book Recommendation [ reallly inscrutable languages ]
  2021-11-16 17:00 [TUHS] Book Recommendation Douglas McIlroy
@ 2021-11-16 17:54 ` Jon Steinhart
  2021-11-16 17:57   ` Ron Natalie
                     ` (3 more replies)
       [not found] ` <CAKH6PiXinxBQGRqoeGMcG9CwTA5BNeU-LY164f-ZLYA4obsyuA@mail.g mail.com>
                   ` (2 subsequent siblings)
  3 siblings, 4 replies; 36+ messages in thread
From: Jon Steinhart @ 2021-11-16 17:54 UTC (permalink / raw)
  To: TUHS main list

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?

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [TUHS] Book Recommendation [ reallly inscrutable languages ]
  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
                     ` (2 subsequent siblings)
  3 siblings, 0 replies; 36+ messages in thread
From: Ron Natalie @ 2021-11-16 17:57 UTC (permalink / raw)
  To: Jon Steinhart, TUHS main list

Awk bailing out near line 1.


------ Original Message ------
From: "Jon Steinhart" <jon@fourwinds.com>
To: "TUHS main list" <tuhs@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?


^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [TUHS] Book Recommendation [ reallly inscrutable languages ]
  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-17 19:12   ` Norman Wilson
  3 siblings, 0 replies; 36+ messages in thread
From: Dan Cross @ 2021-11-16 18:00 UTC (permalink / raw)
  To: Jon Steinhart; +Cc: TUHS main list

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

On Tue, Nov 16, 2021 at 12:57 PM Jon Steinhart <jon@fourwinds.com> wrote:

> 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?
>

I thought Perl was a reaction to exceeding awk's tolerance for abuse?

        - Dan C.

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

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [TUHS] Book Recommendation [ reallly inscrutable languages ]
  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-17 19:12   ` Norman Wilson
  3 siblings, 1 reply; 36+ messages in thread
From: Larry McVoy @ 2021-11-16 18:04 UTC (permalink / raw)
  To: Jon Steinhart; +Cc: TUHS main list

On Tue, Nov 16, 2021 at 09:54:16AM -0800, Jon Steinhart wrote:
> 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?

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 

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [TUHS] Book Recommendation
       [not found] ` <CAKH6PiXinxBQGRqoeGMcG9CwTA5BNeU-LY164f-ZLYA4obsyuA@mail.g mail.com>
@ 2021-11-16 18:47   ` John Foust via TUHS
  0 siblings, 0 replies; 36+ messages in thread
From: John Foust via TUHS @ 2021-11-16 18:47 UTC (permalink / raw)
  To: tuhs

At 11:00 AM 11/16/2021, Douglas McIlroy wrote:
>>> 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. 

In BEFLIX, 'ABC' meant what, exactly?  Offsets from pixel locations?

- John


^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [TUHS] Book Recommendation [ reallly inscrutable languages ]
  2021-11-16 18:04   ` Larry McVoy
@ 2021-11-16 19:53     ` Richard Salz
  2021-11-16 20:05       ` Warner Losh
  0 siblings, 1 reply; 36+ messages in thread
From: Richard Salz @ 2021-11-16 19:53 UTC (permalink / raw)
  To: Larry McVoy; +Cc: TUHS main list

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

> My belief is that perl was written to replace a lot of Unix pipelines,
>

This is true.  I heard it from Larry himself :)

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

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [TUHS] Book Recommendation [ reallly inscrutable languages ]
  2021-11-16 19:53     ` Richard Salz
@ 2021-11-16 20:05       ` Warner Losh
  0 siblings, 0 replies; 36+ messages in thread
From: Warner Losh @ 2021-11-16 20:05 UTC (permalink / raw)
  To: Richard Salz; +Cc: TUHS main list

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

On Tue, Nov 16, 2021 at 12:55 PM Richard Salz <rich.salz@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

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

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [TUHS] Book Recommendation
  2021-11-16 17:00 [TUHS] Book Recommendation Douglas McIlroy
  2021-11-16 17:54 ` [TUHS] Book Recommendation [ reallly inscrutable languages ] Jon Steinhart
       [not found] ` <CAKH6PiXinxBQGRqoeGMcG9CwTA5BNeU-LY164f-ZLYA4obsyuA@mail.g mail.com>
@ 2021-11-16 20:35 ` Bakul Shah
  2021-12-02 21:35 ` Duncan Mak
  3 siblings, 0 replies; 36+ messages in thread
From: Bakul Shah @ 2021-11-16 20:35 UTC (permalink / raw)
  To: TUHS main list

On Nov 16, 2021, at 9:04 AM, Douglas McIlroy <douglas.mcilroy@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….

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [TUHS] Book Recommendation [ reallly inscrutable languages ]
  2021-11-16 17:54 ` [TUHS] Book Recommendation [ reallly inscrutable languages ] Jon Steinhart
                     ` (2 preceding siblings ...)
  2021-11-16 18:04   ` Larry McVoy
@ 2021-11-17 19:12   ` Norman Wilson
  2021-11-17 20:46     ` Dan Stromberg
  2021-11-17 22:36     ` Bakul Shah
  3 siblings, 2 replies; 36+ messages in thread
From: Norman Wilson @ 2021-11-17 19:12 UTC (permalink / raw)
  To: tuhs

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

  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

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

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [TUHS] Book Recommendation [ reallly inscrutable languages ]
  2021-11-17 19:12   ` Norman Wilson
@ 2021-11-17 20:46     ` Dan Stromberg
  2021-11-17 20:52       ` Warner Losh
  2021-11-17 22:36     ` Bakul Shah
  1 sibling, 1 reply; 36+ messages in thread
From: Dan Stromberg @ 2021-11-17 20:46 UTC (permalink / raw)
  To: Norman Wilson; +Cc: TUHS main list

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

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.

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

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [TUHS] Book Recommendation [ reallly inscrutable languages ]
  2021-11-17 20:46     ` Dan Stromberg
@ 2021-11-17 20:52       ` Warner Losh
  2021-11-17 21:17         ` Dan Cross
  0 siblings, 1 reply; 36+ messages in thread
From: Warner Losh @ 2021-11-17 20:52 UTC (permalink / raw)
  To: Dan Stromberg; +Cc: TUHS main list

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

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...

Warner

>

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

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [TUHS] Book Recommendation [ reallly inscrutable languages ]
  2021-11-17 20:52       ` Warner Losh
@ 2021-11-17 21:17         ` Dan Cross
  2021-11-17 22:21           ` Rob Pike
  0 siblings, 1 reply; 36+ messages in thread
From: Dan Cross @ 2021-11-17 21:17 UTC (permalink / raw)
  To: Warner Losh; +Cc: TUHS main list

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

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.

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

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [TUHS] Book Recommendation [ reallly inscrutable languages ]
  2021-11-17 21:17         ` Dan Cross
@ 2021-11-17 22:21           ` Rob Pike
  2021-11-18  0:35             ` Larry McVoy
  2021-11-18 21:03             ` George Michaelson
  0 siblings, 2 replies; 36+ messages in thread
From: Rob Pike @ 2021-11-17 22:21 UTC (permalink / raw)
  To: Dan Cross; +Cc: TUHS main list

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

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.
>
>

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

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [TUHS] Book Recommendation [ reallly inscrutable languages ]
  2021-11-17 19:12   ` Norman Wilson
  2021-11-17 20:46     ` Dan Stromberg
@ 2021-11-17 22:36     ` Bakul Shah
  2021-11-18  0:56       ` Dan Stromberg
  1 sibling, 1 reply; 36+ messages in thread
From: Bakul Shah @ 2021-11-17 22:36 UTC (permalink / raw)
  To: TUHS main list

On Nov 17, 2021, at 11:12 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.

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!


^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [TUHS] Book Recommendation [ reallly inscrutable languages ]
  2021-11-17 22:21           ` Rob Pike
@ 2021-11-18  0:35             ` Larry McVoy
  2021-11-19 20:04               ` Alan Glasser
  2021-11-19 23:17               ` Alan Glasser
  2021-11-18 21:03             ` George Michaelson
  1 sibling, 2 replies; 36+ messages in thread
From: Larry McVoy @ 2021-11-18  0:35 UTC (permalink / raw)
  To: Rob Pike; +Cc: TUHS main list

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 

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [TUHS] Book Recommendation [ reallly inscrutable languages ]
  2021-11-17 22:36     ` Bakul Shah
@ 2021-11-18  0:56       ` Dan Stromberg
  0 siblings, 0 replies; 36+ messages in thread
From: Dan Stromberg @ 2021-11-18  0:56 UTC (permalink / raw)
  To: Bakul Shah; +Cc: TUHS main list

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

On Wed, Nov 17, 2021 at 2:40 PM Bakul Shah <bakul@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

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

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [TUHS] Book Recommendation [ reallly inscrutable languages ]
  2021-11-17 22:21           ` Rob Pike
  2021-11-18  0:35             ` Larry McVoy
@ 2021-11-18 21:03             ` George Michaelson
  2021-11-18 21:39               ` Rob Pike
  1 sibling, 1 reply; 36+ messages in thread
From: George Michaelson @ 2021-11-18 21:03 UTC (permalink / raw)
  To: TUHS main list

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

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@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@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.
>>
>>

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

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [TUHS] Book Recommendation [ reallly inscrutable languages ]
  2021-11-18 21:03             ` George Michaelson
@ 2021-11-18 21:39               ` Rob Pike
  0 siblings, 0 replies; 36+ messages in thread
From: Rob Pike @ 2021-11-18 21:39 UTC (permalink / raw)
  To: George Michaelson; +Cc: TUHS main list

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@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@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@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.
>>>

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [TUHS] Book Recommendation [ reallly inscrutable languages ]
  2021-11-18  0:35             ` Larry McVoy
@ 2021-11-19 20:04               ` Alan Glasser
  2021-11-19 20:14                 ` Larry McVoy
  2021-11-19 23:17               ` Alan Glasser
  1 sibling, 1 reply; 36+ messages in thread
From: Alan Glasser @ 2021-11-19 20:04 UTC (permalink / raw)
  To: Larry McVoy; +Cc: TUHS main list

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

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
>

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

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [TUHS] Book Recommendation [ reallly inscrutable languages ]
  2021-11-19 20:04               ` Alan Glasser
@ 2021-11-19 20:14                 ` Larry McVoy
  2021-11-19 21:48                   ` Alan Glasser
  0 siblings, 1 reply; 36+ messages in thread
From: Larry McVoy @ 2021-11-19 20:14 UTC (permalink / raw)
  To: Alan Glasser; +Cc: TUHS main list

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 

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [TUHS] Book Recommendation [ reallly inscrutable languages ]
  2021-11-19 20:14                 ` Larry McVoy
@ 2021-11-19 21:48                   ` Alan Glasser
  2021-11-19 22:28                     ` Larry McVoy
  0 siblings, 1 reply; 36+ messages in thread
From: Alan Glasser @ 2021-11-19 21:48 UTC (permalink / raw)
  To: Larry McVoy; +Cc: TUHS main list

[-- 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 --]

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [TUHS] Book Recommendation [ reallly inscrutable languages ]
  2021-11-19 21:48                   ` Alan Glasser
@ 2021-11-19 22:28                     ` Larry McVoy
  0 siblings, 0 replies; 36+ messages in thread
From: Larry McVoy @ 2021-11-19 22:28 UTC (permalink / raw)
  To: Alan Glasser; +Cc: TUHS main list

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@lm.bitmover.com|man/WhatIs|19980710174007|58324|a9558aeac091a142

or

user@host.domain|relative/path|date|chksum|64 bits of /dev/random

Revision:

lm@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

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [TUHS] Book Recommendation [ reallly inscrutable languages ]
  2021-11-18  0:35             ` Larry McVoy
  2021-11-19 20:04               ` Alan Glasser
@ 2021-11-19 23:17               ` Alan Glasser
  1 sibling, 0 replies; 36+ messages in thread
From: Alan Glasser @ 2021-11-19 23:17 UTC (permalink / raw)
  To: Larry McVoy; +Cc: TUHS main list

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

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@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
>

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

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [TUHS] Book Recommendation
  2021-11-16 17:00 [TUHS] Book Recommendation Douglas McIlroy
                   ` (2 preceding siblings ...)
  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
  3 siblings, 2 replies; 36+ messages in thread
From: Duncan Mak @ 2021-12-02 21:35 UTC (permalink / raw)
  To: Douglas McIlroy; +Cc: TUHS main list

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

On Tue, Nov 16, 2021 at 12:04 PM Douglas McIlroy <
douglas.mcilroy@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.

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

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [TUHS] Book Recommendation
  2021-12-02 21:35 ` Duncan Mak
@ 2021-12-02 22:32   ` Bakul Shah
  2021-12-02 22:34   ` Rob Pike
  1 sibling, 0 replies; 36+ messages in thread
From: Bakul Shah @ 2021-12-02 22:32 UTC (permalink / raw)
  To: Duncan Mak; +Cc: TUHS main list



> On Dec 2, 2021, at 1:35 PM, Duncan Mak <duncanmak@gmail.com> wrote:
> 
> On Tue, Nov 16, 2021 at 12:04 PM Douglas McIlroy <douglas.mcilroy@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.




^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [TUHS] Book Recommendation
  2021-12-02 21:35 ` Duncan Mak
  2021-12-02 22:32   ` Bakul Shah
@ 2021-12-02 22:34   ` Rob Pike
  1 sibling, 0 replies; 36+ messages in thread
From: Rob Pike @ 2021-12-02 22:34 UTC (permalink / raw)
  To: Duncan Mak; +Cc: TUHS main list, Douglas McIlroy

https://www.youtube.com/watch?v=ek1yjc9sSag

On Fri, Dec 3, 2021 at 8:39 AM Duncan Mak <duncanmak@gmail.com> wrote:
>
> On Tue, Nov 16, 2021 at 12:04 PM Douglas McIlroy <douglas.mcilroy@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.

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [TUHS] Book Recommendation [ reallly inscrutable languages ]
@ 2021-11-18 22:59 Nelson H. F. Beebe
  0 siblings, 0 replies; 36+ messages in thread
From: Nelson H. F. Beebe @ 2021-11-18 22:59 UTC (permalink / raw)
  To: tuhs

The discussions under this subject line have somewhat strayed from
Unix heritage issues, but because several people have contributed
views of assorted programming languages that mostly grew up on
Unix-family systems, I decided to add this memory.

Several years ago, I attended a talk by Dan McCracken (1930--2011),
noted book author in computer areas, and VP and later President of the
ACM (1978--1980).  His talk was about programming languages, and was
done in a question/answer format, with Dan offering both parts.

He began:

   Q: In 10 years, which of the following programming languages will
      still be in use:  Basic, Cobol, Fortran, PL/I, ....

   A: First of all, Basic is not a programming language.  Then ...

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe@math.utah.edu  -
- 155 S 1400 E RM 233                       beebe@acm.org  beebe@computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [TUHS] Book Recommendation [ reallly inscrutable languages ]
  2021-11-18 18:47 Paul Ruizendaal via TUHS
  2021-11-18 19:03 ` arnold
@ 2021-11-18 21:42 ` Rich Morin
  1 sibling, 0 replies; 36+ messages in thread
From: Rich Morin @ 2021-11-18 21:42 UTC (permalink / raw)
  To: TUHS main list

Not that anyone asked, but...

My introduction to Perl was motivated by a performance issue.  I had been using a set of sh/awk/... scripts to generate the source files (troff and file trees) for my Prime Time Freeware book/CD-ROM collections.  One of the cooler aspects of this approach was that I could use sh as a macro processor, substituting assorted values into the awk (etc) code.

However, running the scripts was taking about three hours (!), so I tended to start them up just before going to bed.  This worked, for some value of "work", but it was kind of a nuisance...

So, upon the recommendation of Erik Fair, I transliterated my scripts into Perl.  The similarity of Perl syntax to my previous combination of languages was so strong that the effort was almost mindless.  And, even though I made no attempt to use any Perlish features, the new scripts ran about five (!) times faster.  My assumption is that this was mostly due to getting rid of the process startup times.

My move to Ruby was motivated by the Perl 6 clusterfudge.  After watching Perl 5 sit at a siding for a few years, with no relief in sight, I took another friend's advice and tried out Ruby.  Aside from a few odd differences, it was quite familiar and a very easy transition.  However, the syntax seemed much "cleaner" than Perl's (Matz has very good taste, IMHO).  So, it's still my choice for small, single-threaded scripts.

That said, if I want to write larger and/or concurrent apps, I turn to Elixir.  It gives me Ruby-like syntax (with nifty extensions such as pipes), strong support for concurrency and distribution, macros, etc.

-r


^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [TUHS] Book Recommendation [ reallly inscrutable languages ]
  2021-11-18 19:03 ` arnold
  2021-11-18 19:16   ` Chet Ramey
@ 2021-11-18 21:03   ` John Cowan
  1 sibling, 0 replies; 36+ messages in thread
From: John Cowan @ 2021-11-18 21:03 UTC (permalink / raw)
  To: Aharon Robbins; +Cc: TUHS main list, pnr

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

On Thu, Nov 18, 2021 at 2:06 PM <arnold@skeeve.com> wrote:


> > The shell, awk, sed, etc. had arrived at more or less fully formed
> > versions by 1980. Perl (and TCL) did not appear until the very end of
> > the 1980’s. What filled the gap in that decade, if anything?
>
> Nothing. It was the need for filling the gap that engendered Perl.
>

ISTR that lwall said his specific problem with using awk was its inability
to read from files other than those mentioned on the command line (and them
only sequentially).  Old awk did not have getline.  There were probably
other itches he wanted to scratch, but that one was a deal-breaker (or
-maker).

Remember that Perl 1 through Perl 3 were around durinig the 80s; Perl 4
> sort of settled in for a longer time.
>

Perl 2 was the faster (though still very slow) regex engine; Perl 3 was
binary I/O; Perl 4 was the Camel Book, which is why the version number
stayed at 4.xxx until something in the Camel Book broke.

"New" awk didn't get out of the labs until 1987/1988, and that was only
> via SVR3.2 and/or the AT&T Toolchest; it wasn't open source, nor
> did it provide access to many of the needed system calls in the way
> that Perl did.
>

The project I worked on in 1999-2005 was about half Perl and half
shell+sed+awk+etc....  I was able to do that because I had worked on an
earlier project that was by fiat all Perl 4.  I don't use Perl any more,
but I still use the shell toolkit constantly.

I have a back burner project to allow convenient manual data file
transformation.  It grew out of my dissatisfaction with using the m,n!
command in various editors: you can undo, but it's slow, and you have no
access to the full undo tree except in vim.  My proposed 'mung' command
doesn't actually edit at the micro level, but it lets you use | to create a
new state of the tree, and each state is stored in a file (disk is cheap).
The tree is persistent.  When you have the file the way you want it, you
write it out and, if you want, generate a shell script that replicates what
you just did so it's repeatable.

I'll probably implement it in Python.  The commands and other external
information are at <
https://github.com/johnwcowan/exx/blob/master/mung/mung.txt>.

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

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [TUHS] Book Recommendation [ reallly inscrutable languages ]
  2021-11-18 19:16   ` Chet Ramey
@ 2021-11-18 19:20     ` arnold
  0 siblings, 0 replies; 36+ messages in thread
From: arnold @ 2021-11-18 19:20 UTC (permalink / raw)
  To: tuhs, pnr, chet.ramey, arnold

Chet Ramey <chet.ramey@case.edu> wrote:

> On 11/18/21 2:03 PM, arnold@skeeve.com wrote:
>
> > Also remember that there were plenty of people who were happy working
> > with the shell and the Unix toolkit as-is.
>
> I would argue that this functionality gap is what inspired David Korn to
> put as much into ksh as he did. The first `public' version of ksh was
> released in 1983.

This is a good point. Those of us with access to ksh made use of
its features when scripting. (Speaking for myself.)

Arnold

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [TUHS] Book Recommendation [ reallly inscrutable languages ]
  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
  1 sibling, 1 reply; 36+ messages in thread
From: Chet Ramey @ 2021-11-18 19:16 UTC (permalink / raw)
  To: arnold, tuhs, pnr

On 11/18/21 2:03 PM, arnold@skeeve.com wrote:

> Also remember that there were plenty of people who were happy working
> with the shell and the Unix toolkit as-is.

I would argue that this functionality gap is what inspired David Korn to
put as much into ksh as he did. The first `public' version of ksh was
released in 1983.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [TUHS] Book Recommendation [ reallly inscrutable languages ]
  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 21:03   ` John Cowan
  2021-11-18 21:42 ` Rich Morin
  1 sibling, 2 replies; 36+ messages in thread
From: arnold @ 2021-11-18 19:03 UTC (permalink / raw)
  To: tuhs, pnr

Paul Ruizendaal via TUHS <tuhs@minnie.tuhs.org> wrote:

> Here’s another angle on Perl, perhaps more on topic for TUHS. Let’s
> accept for a minute that Perl filled the void between C and shell scripts,
> and that there was a latent need for a scripting language like this
> on Unix.
> 
> The shell, awk, sed, etc. had arrived at more or less fully formed
> versions by 1980. Perl (and TCL) did not appear until the very end of
> the 1980’s. What filled the gap in that decade, if anything?

Nothing. It was the need for filling the gap that engendered Perl.
Remember that Perl 1 through Perl 3 were around durinig the 80s; Perl 4
sort of settled in for a longer time.

"New" awk didn't get out of the labs until 1987/1988, and that was only
via SVR3.2 and/or the AT&T Toolchest; it wasn't open source, nor
did it provide access to many of the needed system calls in the way
that Perl did.

Also remember that there were plenty of people who were happy working
with the shell and the Unix toolkit as-is.

Arnold

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [TUHS] Book Recommendation [ reallly inscrutable languages ]
@ 2021-11-18 18:47 Paul Ruizendaal via TUHS
  2021-11-18 19:03 ` arnold
  2021-11-18 21:42 ` Rich Morin
  0 siblings, 2 replies; 36+ messages in thread
From: Paul Ruizendaal via TUHS @ 2021-11-18 18:47 UTC (permalink / raw)
  To: TUHS main list


Here’s another angle on Perl, perhaps more on topic for TUHS. Let’s accept for a minute that Perl filled the void between C and shell scripts, and that there was a latent need for a scripting language like this on Unix.

The shell, awk, sed, etc. had arrived at more or less fully formed versions by 1980. Perl (and TCL) did not appear until the very end of the 1980’s. What filled the gap in that decade, if anything?

Ancient Unix has ‘bs’ https://en.wikipedia.org/wiki/Bs_(programming_language) but this seems to have had very little use.

Paul


^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [TUHS] Book Recommendation [ reallly inscrutable languages ]
  2021-11-16 19:29 [TUHS] Book Recommendation [ reallly inscrutable languages ] Douglas McIlroy
@ 2021-11-16 19:54 ` Jon Steinhart
  0 siblings, 0 replies; 36+ messages in thread
From: Jon Steinhart @ 2021-11-16 19:54 UTC (permalink / raw)
  To: TUHS main list

Douglas McIlroy writes:
> > My belief is that perl was written to replace a lot of Unix pipelines,
>
> I understand Perl's motive to have been a lot like PL/I's: subsume
> several popular styles of programming in one language. PL/I's ensemble
> wasn't always harmonious. Perl's was cacophony.

Perl was nice in its early years as it was much more capable than awk.
I understood its original intent to be a better glue language.  While
I find the syntax to be ugly, that's not where I hit a Wall.  To me,
the thing that makes Perl a bad language is the magic side effects left
in things like _0 from many operations.  This is stuff that one is not
likely to remember unless it's used every day.  I think that it's why
so many consider Perl to be write-only; too many magic implicit things
instead of being explicit.  I understand that compactness was a big
deal 40 years ago but no longer.

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [TUHS] Book Recommendation [ reallly inscrutable languages ]
@ 2021-11-16 19:29 Douglas McIlroy
  2021-11-16 19:54 ` Jon Steinhart
  0 siblings, 1 reply; 36+ messages in thread
From: Douglas McIlroy @ 2021-11-16 19:29 UTC (permalink / raw)
  To: TUHS main list

> My belief is that perl was written to replace a lot of Unix pipelines,

I understand Perl's motive to have been a lot like PL/I's: subsume
several popular styles of programming in one language. PL/I's ensemble
wasn't always harmonious. Perl's was cacophony.

Doug

^ permalink raw reply	[flat|nested] 36+ messages in thread

end of thread, other threads:[~2021-12-02 22:35 UTC | newest]

Thread overview: 36+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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

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).