* 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; 30+ 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] 30+ messages in thread
* Re: [TUHS] Book Recommendation [ reallly inscrutable languages ] 2021-11-18 18:47 [TUHS] Book Recommendation [ reallly inscrutable languages ] 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; 30+ 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] 30+ 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; 30+ 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] 30+ 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; 30+ 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] 30+ 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; 30+ 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] 30+ messages in thread
* Re: [TUHS] Book Recommendation [ reallly inscrutable languages ] 2021-11-18 18:47 [TUHS] Book Recommendation [ reallly inscrutable languages ] Paul Ruizendaal via TUHS 2021-11-18 19:03 ` arnold @ 2021-11-18 21:42 ` Rich Morin 1 sibling, 0 replies; 30+ 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] 30+ messages in thread
* Re: [TUHS] Book Recommendation [ reallly inscrutable languages ] @ 2021-11-18 22:59 Nelson H. F. Beebe 0 siblings, 0 replies; 30+ 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] 30+ 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; 30+ 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] 30+ 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, 0 replies; 30+ 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] 30+ messages in thread
* Re: [TUHS] Book Recommendation @ 2021-11-16 17:00 Douglas McIlroy 2021-11-16 17:54 ` [TUHS] Book Recommendation [ reallly inscrutable languages ] Jon Steinhart 0 siblings, 1 reply; 30+ 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] 30+ 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) 0 siblings, 4 replies; 30+ 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] 30+ 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; 30+ 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] 30+ 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; 30+ 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] 30+ 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; 30+ 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] 30+ 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; 30+ 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] 30+ 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; 30+ 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] 30+ 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; 30+ 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] 30+ 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; 30+ 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] 30+ 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; 30+ 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] 30+ 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; 30+ 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] 30+ 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; 30+ 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] 30+ 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; 30+ 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] 30+ 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; 30+ 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] 30+ 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; 30+ 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] 30+ 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; 30+ 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] 30+ 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; 30+ 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] 30+ 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; 30+ 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] 30+ 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; 30+ 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] 30+ 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; 30+ 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] 30+ 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; 30+ 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] 30+ 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; 30+ 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] 30+ messages in thread
end of thread, other threads:[~2021-11-19 23:19 UTC | newest] Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-11-18 18:47 [TUHS] Book Recommendation [ reallly inscrutable languages ] 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 -- strict thread matches above, loose matches on Subject: below -- 2021-11-18 22:59 Nelson H. F. Beebe 2021-11-16 19:29 Douglas McIlroy 2021-11-16 19:54 ` Jon Steinhart 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
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).