The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* Re: [TUHS] Book Recommendation
@ 2021-11-16  3:16 Douglas McIlroy
  2021-11-16  4:08 ` G. Branden Robinson
  0 siblings, 1 reply; 62+ messages in thread
From: Douglas McIlroy @ 2021-11-16  3:16 UTC (permalink / raw)
  To: TUHS main list

While waiting to see the full text, I've poked around the index for
subjects of interest. It certainly is copious, and knows about a lot
of things that I don't.

The authors make a reasonable choice in identifying the dawn of
"modern computing" with Eniac and relegating non-electronic machines
to prehistory. Still, I was glad to find the prophetic Konrad Zuse
mentioned, but disappointed not to find the Bell Labs pioneer, George
Stibitz.

Among programming languages, Fortran, which changed the nature of
programming, is merely hinted at (buried in the forgettable Fortran
Monitoring System), while its insignificant offspring PL/I is present.
(Possibly this is an indexing oversight. John Backus, who led the
Fortran project, is mentioned quite early in the book.) Algol, Lisp,
Simula and Smalltalk quite properly make the list, but Basic rates
more coverage than any of them. C, obscurely alphabetized as "C
language", is treated generously, as is Unix in general.

Surprisingly there's almost nothing in the index about security or
privacy. The litany of whiggish chapters about various uses of
computers needs a cautionary complement. "The computer attracts crooks
and spies" would be a stylistically consistent title.

Doug

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

* Re: [TUHS] Book Recommendation
  2021-11-16  3:16 [TUHS] Book Recommendation Douglas McIlroy
@ 2021-11-16  4:08 ` G. Branden Robinson
  2021-11-16 14:56   ` Clem Cole
  0 siblings, 1 reply; 62+ messages in thread
From: G. Branden Robinson @ 2021-11-16  4:08 UTC (permalink / raw)
  To: TUHS main list

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

At 2021-11-15T22:16:41-0500, Douglas McIlroy wrote:
> While waiting to see the full text, I've poked around the index for
> subjects of interest. It certainly is copious, and knows about a lot
> of things that I don't.
> 
> The authors make a reasonable choice in identifying the dawn of
> "modern computing" with Eniac and relegating non-electronic machines
> to prehistory.

Just so long as the antikythera mechanism is in there... ;-)

> Among programming languages, Fortran, which changed the nature of
> programming, is merely hinted at (buried in the forgettable Fortran
> Monitoring System), while its insignificant offspring PL/I is present.

PL/I was important enough to rate presentation in _The Elements of
Programming Style_.  :P  I have gotten the impression that it was a
language that was beloved by no one.

> (Possibly this is an indexing oversight. John Backus, who led the
> Fortran project, is mentioned quite early in the book.) Algol, Lisp,
> Simula and Smalltalk quite properly make the list, but Basic rates
> more coverage than any of them.

It's hard to overstate the impact of BASIC on the first generation of
people who grew up with computers in the home instead of encountering
them only later in a time-sharing environment with professional
operators and administrators.

This is not because BASIC was a high quality language, especially as
stripped down by Microsoft and other implementors.  On 8-bit boxes with
no memory protection and no privilege structure, it taught one a lot
about absolute liberty and the absolute consequences thereof.  We power
cycled machines with a frequency that would have horrified the staff of
any computing center.

Everybody knew there were bigger, better, or faster languages out there,
but they were priced commercially and marketed at professionals.  The
same was usually true of editor/assembler/linker packages.  But BASIC
was packed-in on ROM chips and always available.  And you could always
assemble your own opcodes (or get listings of hex bytes from hobbyist
magazines) and "poke" them into memory--a good way to learn and to
polish that machine reset button to a shine.

At one time, it was considered good sport to ridicule people whose first
programming language was BASIC; after a while I figured out that this
was a form of hazing, similar to the snotty attitudes adopted by a
subset of student employees who got access to group "wheel" on at least
one university-owned machine, lorded it over undergraduates, and who
kept the existence of or access to Volume 2 of the Unix Programmer's
Manual a secret.  ("If you can't learn the system just from the man
pages, you must be pretty dumb.")  Such was my first exposure to BSD and
SunOS partisans.

After a while, I learned they weren't _all_ like that...

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

* Re: [TUHS] Book Recommendation
  2021-11-16  4:08 ` G. Branden Robinson
@ 2021-11-16 14:56   ` Clem Cole
  2021-11-16 15:37     ` Richard Salz
                       ` (3 more replies)
  0 siblings, 4 replies; 62+ messages in thread
From: Clem Cole @ 2021-11-16 14:56 UTC (permalink / raw)
  To: G. Branden Robinson; +Cc: TUHS main list

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

On Mon, Nov 15, 2021 at 11:09 PM G. Branden Robinson <
g.branden.robinson@gmail.com> wrote:

> It's hard to overstate the impact of BASIC on the first generation of
> people who grew up with computers in the home instead of encountering
> them only later in a time-sharing environment with professional
> operators and administrators.
>
FWIW:   A number of us learned BASIC in the late 1960s/early 1970s (*i.e.*
before the microprocessor versions ever appeared as they did not yet
exist).  Gates & Allen used it in HS on a PDP-10 with an ASR-33, and I'm
their same age.   I did the same thing in JHS and HS on a GE-635 [Mark-II
DTSS] and then later HP2000 [Community Computer Services] - 10 cps baby,
upper case only.

What I don't know is if the PDP-8 BASIC came before the PDP-10 version.
 But the point is that most of the mini's (no matter the manufacturer) had
an implementation of BASIC in the late 60s and early 1970s, long before the
micro's came on the scene.  I would later get to know/work with a number of
the people in DEC languages groups and I do know that the syntax and
semantics of the BASIC for RSTS implementation originally was based on the
PDP-10 BASIC (although they did have some differences).

In fact, DEC's RSTS/11 and the HP/2100 running BASIC were the two systems
that ended up being used by a lot of small timesharing shops and eventually
on-site at the high schools that could afford the HW. The reason being that
BASIC became popular on the small system was it required fewer resources
and because it was primarily interpreted matched.  An urban legend is that
when Gates opened in Microsoft in AZ, he bartered time from the local high
school running their RSTS system for them in return for being able to use
it as their development system [I definitely know that he used their
system, I'm just now sure how he renumerated them for the computer time].


> This is not because BASIC was a high quality language, especially as
> stripped down by Microsoft and other implementors.

It made perfect sense when Gates decided to implement it for the Altair.
 And he modeled his version on the DEC syntax and semantics - because that
was what he knew was used to from the PDP-10, and what he and Paul had
learned first.



> Everybody knew there were bigger, better, or faster languages out there,
> but they were priced commercially and marketed at professionals.

And more importantly, *requires many more resources*.
Consider UCSD-Pascal, you needed a disk-based system to run it, be an
LSI-11, Apple-IIe, or CP/M box.  The BASIC's often worked out of ROM.
 Hey, I can think of implementations of other languages such as FORTRAN's,
C, Cobol, PL/M, PL/1, and eventually many Pascals for the different
micro's, but they all took more HW to support the edit/compile/link cycle.

The point is that for a >>hobbyist<<, running BASIC was 'good enough.'  The
only HS in the late 1970s that I knew that could afford a PDP 11/45 and
actually ran UNIX on it, was Lincoln-Sudbury - which is in a high-end
suburban Boston.  They also had a lot of help from parents who per
professionals here in Boston working for places like DEC, DG, Pr1me,
Honeywell, and the like.   At that time, I was long gone, but I now my
father at my own prep school in suburban Philadelphia dreamed of an 11/40
class system to run RSTS, but they could not afford it.  So if they wanted
off a timesharing service like the HP/21000, they bought small
microprocessor (CP/M or Apple-II) gear and ran them as a hobbyist would.




> At one time, it was considered good sport to ridicule people whose first programming
> language was BASIC;

I'm not so much sure it was that their first language was BASIC, as much as
they did not go beyond it.   I will say that once the HW started to be able
to support more complete languages (such as Pascal), there was some of
that.  I used to say the problem was that they probably learned it in HS
and their teachers did know more.

My own father (who taught me BASIC on the GE-635 when I was in JHS), knew
only BASIC and FORTRAN because that was what he had learned working
part-time as a 'computer' at Rocketdyne in the late 1950s/early 1960s.   By
the late 60s, he was the first 'computer teacher' at the prep school when I
went (in Philadelphia, but not that dissimilar to Bill Gates's experiences
in Seattle at a local prep school there).  He taught us what he knew and *what
he had access to*. Eventually, I outpaced him a bit, and I started to learn
a little assembler for the HP because I was curious.  But I came to a point
where I knew way more than he did before I left HS [BTW: Gates and Allen
tell a similar story - of learning PDP-10 assembler at some point --
advancing ahead of their teachers].  The truth is I think my Dad was a bit
ahead of his time, *but he did not know what he did not know *and did know
to try to teach others anything other than BASIC and FORTRAN*.*

FWIW: I went to CMU and had to be re-taught - being introduced to Algol,
real FORTRAN, IBM Assembler, APL (and eventually many of other wonders).
BTW: By the mid/late '70s, I had taught my Dad Pascal so he could use it
with USCD-Pascal with his 'advanced students' now that he had a few
Apple-IIe's that could run it.



> after a while I figured out that this was a form of hazing, similar to
> the snotty attitudes adopted by a
> subset of student employees
>
Point taken... and I there probably was a lot of those, particularly later
once the HW ability and cost available made it possible to have a choice.
But the problem was that most of the young people had come from places
where the educators that taught them BASIC did not know better even if they
had had enough HW to do it.

Unfortunately, because the hobbyist and much of the press for entry-level
of the same, touted BASIC, many did not know better.   The fact is I'm
still now sure the HS and JHS are a lot better than they were.

I'll let Steinhart reply, but he wrote an excellent book recently targeted
to just those same students that what to know more, but frankly their HS
teachers really are not in a position to teach them properly.

Clem
ᐧ

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

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

* Re: [TUHS] Book Recommendation
  2021-11-16 14:56   ` Clem Cole
@ 2021-11-16 15:37     ` Richard Salz
  2021-11-16 15:50       ` Adam Thornton
  2021-11-16 16:02     ` [TUHS] BASIC, RSTS, and UNIX Ron Natalie
                       ` (2 subsequent siblings)
  3 siblings, 1 reply; 62+ messages in thread
From: Richard Salz @ 2021-11-16 15:37 UTC (permalink / raw)
  To: Clem Cole; +Cc: TUHS main list

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

> What I don't know is if the PDP-8 BASIC came before the PDP-10 version.

This was a fun rat-hole.  (My first programming was Edu-24 BASIC on a
pdp-8/e my 7-12 school had.)  It appears that the DEC-10 BASIC is earlier,
at least according to how I intuit the timeline from
https://en.wikipedia.org/wiki/BASIC-8

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

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

* Re: [TUHS] Book Recommendation
  2021-11-16 15:37     ` Richard Salz
@ 2021-11-16 15:50       ` Adam Thornton
  0 siblings, 0 replies; 62+ messages in thread
From: Adam Thornton @ 2021-11-16 15:50 UTC (permalink / raw)
  To: Richard Salz; +Cc: TUHS main list

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

Dijkstra notwithstanding, BASIC has the same strengths and weaknesses as,
later, PHP would for the web, and I think that Javascript might have these
days (and in the scientific programming world, Python).

That is, it's very easy for the novice to get something working that gives
them the results they want.  Maintainability and efficiency are simply not
on their radar for the scope of problem they're trying to solve.  I'm not
even sure how much of this you can lay at the feet of teachers: I would
argue that we see a huge efflorescence of essentially self-taught
programming cobbled together from (in the old days) the system manuals and
programs in magazines, and (these days) Googling that takes you to Stack
Overflow and various tutorials, of wildly varying quality.

Maybe we should take the "personal" in "personal computing" seriously.
That said, now that your personal project is probably exposed to the world
via the Web, maybe that's not a good idea if you have any data behind that
project whose integrity or privacy you care about.

Disclaimer: my formative experiences were MS BASIC on 6502-based micros,
and were fundamentally self-taught.

Adam

On Tue, Nov 16, 2021 at 8:38 AM Richard Salz <rich.salz@gmail.com> wrote:

> > What I don't know is if the PDP-8 BASIC came before the PDP-10 version.
>
> This was a fun rat-hole.  (My first programming was Edu-24 BASIC on a
> pdp-8/e my 7-12 school had.)  It appears that the DEC-10 BASIC is earlier,
> at least according to how I intuit the timeline from
> https://en.wikipedia.org/wiki/BASIC-8
>
>

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

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

* [TUHS] BASIC, RSTS, and UNIX
  2021-11-16 14:56   ` Clem Cole
  2021-11-16 15:37     ` Richard Salz
@ 2021-11-16 16:02     ` Ron Natalie
       [not found]       ` <CAC20D2OT6ZcFOqnNCkqDUfAKy87wYu7mp7xx0ozzAT0eN1wr8g@mail.gmail.com>
  2021-11-16 17:02     ` [TUHS] Book Recommendation Will Senn
  2021-11-16 18:27     ` Jon Steinhart
  3 siblings, 1 reply; 62+ messages in thread
From: Ron Natalie @ 2021-11-16 16:02 UTC (permalink / raw)
  To: TUHS main list

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

My BASIC experience came from the HP/2000 (and the HP/3000) systems the 
Prince George's County (MD) schools had at the time.     When I moved on 
to Johns Hopkins, I was sent a letter in advance of my freshman year 
from professor Bill Huggins who taught one of the freshman EE classes.   
The class was to use Basic  Plus on a PDP-11/45s using the UNIX 
operating system.    Now at this point, I had a friend whose mother 
worked in the local DEC (Lanham, MD) office and would let us raid the 
stock room for things like processor handbooks and the like.    I was 
able to find out about Basic Plus and PDP-11/45 but I was unable to find 
anything about this UNIX thing.

Of course, once I got there I found that the EE computer center was 
largely run by students under the name of the Undergraduate Computer 
Society.   Mike Muuss was in charge and they had made a deal that if 
they could get BasicPlus migrated over from RSTS, they could run UNIX on 
the machine.    It turned out not to be that difficult.   RSTS, like 
most DEC OSes, for some reason used EMT for the system calls (contrary 
to what the processor handbook would recommend).   UNIX used TRAP.   
This means all they had to do is emulate a few RSTS calls.    In 
addition, the only change I believe was to add a system call that 
disabled the UNIX idea of stack management (Basic Plus like many DEC 
programs of the day used a relatively small stack in low memory because 
the actual register saves, etc... were stored elsewhere, it was just 
function call linkage).   The system call was obviously called 
"nostack."

This hadn't been Mike's only foray into Basic.    He had his own IBM 
1130 and had written a Basic interpretter under contract for the 
Baltimore County Public Schools.   I remember sitting in the "KSR room" 
at Hopkins and watching him preparing the invoice for payment.
Please remit $3000, no stamps please.    That last part caused a bit of 
consternation at the school district.

Amusingly, I have my little Raspberry Pi scale model 11/70 front panel 
churning away on my desk.    I can switch it from booting up various 
UNIXes (mostly I run 2.9 BSD hacked to somewhat look like JHU UNIX) and 
RSTS which reinforces why we used to refer to it as the Really Sh-tty 
Timesharing System.


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

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

* [TUHS] Speaking of groups: JHU Ownership
       [not found]       ` <CAC20D2OT6ZcFOqnNCkqDUfAKy87wYu7mp7xx0ozzAT0eN1wr8g@mail.gmail.com>
@ 2021-11-16 16:43         ` Ron Natalie
  0 siblings, 0 replies; 62+ messages in thread
From: Ron Natalie @ 2021-11-16 16:43 UTC (permalink / raw)
  To: TUHS main list

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

A private message with Uh, Clem reminds me of another quaint piece of 
UNIX group history:   JHU Ownership.

The original V6 kernel and file systems used a char for UID and GID.    
This meant that you could only have 255 (plus the root user) distinct 
users on the machine.     The JHU PDP-11/45 was used for the EE classes 
and we had more than that many users.    The kernel was modified to 
check if the GID was 200 or greater.   If it was, that was taken along 
with the UID to be part of the user identity.    We gave all the class 
accounts such GIDs.

Of course, we had to be careful about newgrp and fun and games with 
setuid/setgid (both the system call and the bits on the executables).
I spent a lot of my time looking for exploits there and fixing them once 
I (or someone else) found them.

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

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

* Re: [TUHS] Book Recommendation
  2021-11-16 14:56   ` Clem Cole
  2021-11-16 15:37     ` Richard Salz
  2021-11-16 16:02     ` [TUHS] BASIC, RSTS, and UNIX Ron Natalie
@ 2021-11-16 17:02     ` Will Senn
  2021-11-16 21:38       ` John Cowan
  2021-11-16 18:27     ` Jon Steinhart
  3 siblings, 1 reply; 62+ messages in thread
From: Will Senn @ 2021-11-16 17:02 UTC (permalink / raw)
  To: tuhs

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

I still heart BASIC. I enjoy it's simplicity. I started out on BASIC 
with a Commodore Pet ca. 1978. I still like to fire it up every now and 
then - Chipmunk on my Macbook, BAS/BAS2 on RSTS/11, RSX-11, BBC basic? 
on RISC OS, doesn't matter, they all do a fair job of BASIC. I 
especially like firing up  Berhard's pdp 8 simulator with teletype 
emulation and coding on the teletype - 
https://www.bernhard-baehr.de/pdp8e/pdp8e.html. Unix... well, I've not 
been real successful in getting it to work on v6, other folks maybe, but 
not me. By work, I mean, I type in reasonable BASIC and it runs 
reasonably :). The bas executable work fine, it's the human-computer 
interface that doesn't seem to wanna work, nothing I type in as a 
program more complex than 'hello, world' will run with any reliability.

On another note, I remember the days when people bad mouthed lovers of 
BASIC (in industry) and acted as though they were simpletons, later they 
became haters on VB folks. When I learned C, in my twenties, I felt 
empowered, but at the same time hamstrung, some of the simplest things 
in BASIC became an odyssey in C. Nowadays, I use Python more than 
anything else these (boring data sciency stuff). What I like about 
Python is that it reminds me of BASIC in its simplicity of expression, 
but to be fair, it goes far, far beyond it in power... I just wish it 
were as free form as Ruby in how you say, what you say... any, I digress...

My favorite BASIC book:

My Computer Likes Me*
*when I speak in BASIC

by Bob Albrecht

Written in 1972 (for a teletype interface)

On a less positive note. The professors who originally developed it at 
Dartmouth could never quite see there way clear to open source it. True 
BASIC? pshaw :). There was a time when I would have loved to run BASIC 
on linux, bsd, then Mac and have it be consistent across the platforms, 
other than as a curiosity, that time has gone.

My question for the group is what's BASIC's history in the unices? I 
know it's in v6, cuz I struggled with it there, but I'm curious what the 
backstory is? I have the impression that the marriage of bas and v6 was 
one of convenience, maybe there was a thought to draw in the hobbiest? 
Were Kemeny and Kurtz characters in the same circles as the unix folks?


Later,

Will

On 11/16/21 8:56 AM, Clem Cole wrote:
>
>
> On Mon, Nov 15, 2021 at 11:09 PM G. Branden Robinson 
> <g.branden.robinson@gmail.com> wrote:
>
>     It's hard to overstate the impact of BASIC on the first generation of
>     people who grew up with computers in the home instead of encountering
>     them only later in a time-sharing environment with professional
>     operators and administrators.
>
> FWIW:   A number of us learned BASIC in the late 1960s/early 1970s 
> (/i.e./ before the microprocessor versions ever appeared as they did 
> not yet exist).  Gates & Allen used it in HS on a PDP-10 with an 
> ASR-33, and I'm their same age.   I did the same thing in JHS and HS 
> on a GE-635 [Mark-II DTSS] and then later HP2000 [Community Computer 
> Services] - 10 cps baby, upper case only.
>
> What I don't know is if the PDP-8 BASIC came before the PDP-10 
> version.   But the point is that most of the mini's (nomatter the 
> manufacturer) had an implementation of BASICin the late 60s and early 
> 1970s, long before the micro's came on the scene.  I would later get 
> to know/work with a number of the people in DEC languages groups and I 
> do know that the syntax and semantics of the BASIC for RSTS 
> implementation originally was based on the PDP-10 BASIC (although they 
> did have some differences).
>
> In fact, DEC's RSTS/11 and the HP/2100 running BASIC were the two 
> systems that ended up being used by a lot of small timesharing shops 
> and eventually on-site at the high schools that could afford the HW. 
> The reason being that BASIC became popular on the small system was it 
> required fewer resources and because it was primarily interpreted 
> matched.  An urban legend is that when Gates opened in Microsoft in 
> AZ, he bartered time from the local high school running their RSTS 
> system for them in return for being able to use it as their 
> development system [I definitely know that he used their system, I'm 
> just now sure how he renumerated them for the computer time].
>
>
>     This is not because BASIC was a high quality language, especially as
>     stripped down by Microsoft and other implementors.
>
> It made perfect sense when Gates decided to implement it for the 
> Altair.   And he modeled his version on the DEC syntax and semantics - 
> because that was what he knew was used to from the PDP-10, and what he 
> and Paul had learned first.
>
>     Everybody knew there were bigger, better, or faster languages out
>     there,
>     but they were priced commercially and marketed at professionals.
>
> And more importantly, /requires many more resources/.  
> Consider UCSD-Pascal, you needed a disk-based system to run it, be an 
> LSI-11, Apple-IIe, or CP/M box.  The BASIC's often worked out of ROM. 
>  Hey, I can think of implementations of other languages such as 
> FORTRAN's, C, Cobol, PL/M, PL/1, and eventually many Pascals for the 
> different micro's, but they all took more HW to support the 
> edit/compile/link cycle.
>
> The point is that for a >>hobbyist<<, running BASIC was 'good 
> enough.'  The only HS in the late 1970s that I knew that could afford 
> a PDP 11/45 and actually ran UNIX on it, was Lincoln-Sudbury - which 
> is in a high-end suburban Boston.  They also had a lot of help from 
> parents who per professionals here in Boston working for places like 
> DEC, DG, Pr1me, Honeywell, and the like.   At that time, I was long 
> gone, but I now my father at my own prep school in 
> suburban Philadelphia dreamed of an 11/40 class system to run RSTS, 
> but they could not afford it. So if they wanted off a timesharing 
> service like the HP/21000, they bought small microprocessor (CP/M or 
> Apple-II) gear and ran them as a hobbyist would.
>
>
>     At one time, it was considered good sport to ridicule people whose
>     firstprogramming language was BASIC;
>
> I'm not so much sure it was that their first language was BASIC, as 
> much as they did not go beyond it.   I will say that once the HW 
> started to be able to support more complete languages (such as 
> Pascal), there was some of that.  I used to say the problem was that 
> they probably learned it in HS and their teachers did know more.
>
> My own father (who taught me BASIC on the GE-635 when I was in JHS), 
> knew only BASIC and FORTRAN because that was what he had learned 
> working part-time as a 'computer' at Rocketdyne in the late 
> 1950s/early 1960s.   By the late 60s, he was the first 'computer 
> teacher' at the prep school when I went (in Philadelphia, but not that 
> dissimilar to Bill Gates's experiences in Seattle at a local prep 
> school there). He taught us what he knew and /what he had access to/. 
> Eventually, I outpaced him a bit, and I started to learn a little 
> assembler for the HP because I was curious. But I came to a point 
> where I knew way more than he did before I left HS [BTW: Gates and 
> Allen tell a similar story - of learning PDP-10 assembler at some 
> point -- advancing ahead of their teachers].  The truth is I think my 
> Dad was a bit ahead of his time, /but he did not know what he did not 
> know /and did know to try to teach others anything other than BASIC 
> and FORTRAN/./
>
> FWIW: I went to CMU and had to be re-taught - being introduced to 
> Algol, real FORTRAN, IBM Assembler, APL (and eventually many of other 
> wonders). BTW: By the mid/late '70s, I had taught my Dad Pascal so he 
> could use it with USCD-Pascal with his 'advanced students' now that he 
> had a few Apple-IIe's that could run it.
>
>     after a while I figured out that thiswas a form of hazing, similar
>     to the snotty attitudes adopted by a
>     subset of student employees
>
> Point taken... and I there probably was a lot of those, particularly 
> later once the HW ability and cost available made it possible to have 
> a choice. But the problem was that most of the young people had come 
> from places where the educators that taught them BASIC did not know 
> better even if they had had enough HW to do it.
>
> Unfortunately, because the hobbyist and much of the press for 
> entry-level of the same, touted BASIC, many did not know better.   The 
> fact is I'm still now sure the HS and JHS are a lot better than they were.
>
> I'll let Steinhart reply, but he wrote an excellent book recently 
> targeted to just those same students that what to know more, but 
> frankly their HS teachers really are not in a position to teach them 
> properly.
>
> Clem
> ᐧ

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

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

* Re: [TUHS] Book Recommendation
  2021-11-16 14:56   ` Clem Cole
                       ` (2 preceding siblings ...)
  2021-11-16 17:02     ` [TUHS] Book Recommendation Will Senn
@ 2021-11-16 18:27     ` Jon Steinhart
  2021-11-16 18:44       ` Heinz Lycklama
  3 siblings, 1 reply; 62+ messages in thread
From: Jon Steinhart @ 2021-11-16 18:27 UTC (permalink / raw)
  To: TUHS main list

Clem Cole writes:
> Unfortunately, because the hobbyist and much of the press for entry-level
> of the same, touted BASIC, many did not know better.   The fact is I'm
> still now sure the HS and JHS are a lot better than they were.
>
> I'll let Steinhart reply, but he wrote an excellent book recently targeted
> to just those same students that what to know more, but frankly their HS
> teachers really are not in a position to teach them properly.

Well thanks Clem :-)

I didn't actually hit BASIC until college where freshmen had to learn it
on the PDP-8.  Took me all of about 5 minutes to learn the language and
about a half a day to do the entire semester of coursework.  Got me off
to a good start on annoying my professors.

I think that my first programming language was SNAP running on a PDP8-E in
the (I don't remember the exact name) Princeton computer barn.  Because my
dad worked at IBM I remember going over to his VP's house to learn APL on
his home terminal.  FORTRAN on I think an IBM 1620 was next.  After that
was Heinz's FSNAP on the Honeywell DDP-516 at BTL.  Never thought to
ask before, Heinz - was FSNAP based on SNAP?  Assembler came after that,
followed by C.  I know, what's the difference?  Then Pascal in college
which was dreadful after C.  I asked my professor to give me a few pointers
on how to program with fixed length arrays but he couldn't give me any :-)

It's my opinion that BASIC was a good thing in its day but that that time
has passed.  Part of what made it the goto language was its simplicity;
there wasn't much to learn and there was no complex toolchain so time was
spend on figuring out how to structure a problem so that it could be solved
on a computer.  In my not very humble opinion, this is the fundamental
(or should I say basic) problem with CS education today; the effort is
focused on learning the language and the toolchain, not how to think and
solve problems.  Somehow many of us learned to program in BASIC without a
"Hello World" tutorial.

Another big factor in those days was that the consequences for getting
something wrong were pretty much nonexistent.  What was the worst that
could happen, you'd accidentally output an obscenity?  Give what computers
were used for back then, getting the math wrong was more likely than having
a logic error.  I didn't have to worry about buggy code destroying anything
until a project where I modified FSNAP to control semiconductor test
equipment.

I have tried when mentoring to get people to start with simple
character oriented programs but of course everyone (especially boys)
want to start with a video game.  This immediately means having to deal
with multithreaded code (even if it's somewhat hidden) and complex APIs.
All of this is a distraction from learning how to think and solve problems.
As a result, we're producing a lot of "programmers" who can wrangle this
stuff while having no idea how to solve a problem.  I think that a glance
at stackoverflow backs me up here.  It's extremely frustrating: "I want to
write a video game where I can shoot something."  "Cool.  Let's learn
some physics."  "I don't want to learn physics, I want to shoot something."

As an aside, I saw an article recently where someone was lauding the
github "AI" code writing thing.  The author wrote something like "Wow.
I asked it to replace spaces in a string with underscores and it just
gave me the code."  Arrrrggggghhhh!!!  IMNVHO this person should never be
allowed near a computer.  If you can't do this without help you shouldn't
be programming.

Like usual, I'm rambling, but one more related thing.  I'm mentoring a CS
student who has to do a project this year.  My advice was that I didn't
care what the project actually did, but that it should be based on an
Arduino and written in C and assembler without any of the sketch library
stuff.  The goal being to learn to read a data sheet, program I/O devices,
and handle interrupts.  All on a processor that's not too complicated.

Jon

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

* Re: [TUHS] Book Recommendation
  2021-11-16 18:27     ` Jon Steinhart
@ 2021-11-16 18:44       ` Heinz Lycklama
  0 siblings, 0 replies; 62+ messages in thread
From: Heinz Lycklama @ 2021-11-16 18:44 UTC (permalink / raw)
  To: tuhs

Jon, regarding FSNAP - wrote it from scratch.
Did not know about SNAP at the time.

Heinz

On 11/16/2021 10:27 AM, Jon Steinhart wrote:
> Clem Cole writes:
>> Unfortunately, because the hobbyist and much of the press for entry-level
>> of the same, touted BASIC, many did not know better.   The fact is I'm
>> still now sure the HS and JHS are a lot better than they were.
>>
>> I'll let Steinhart reply, but he wrote an excellent book recently targeted
>> to just those same students that what to know more, but frankly their HS
>> teachers really are not in a position to teach them properly.
> Well thanks Clem :-)
>
> I didn't actually hit BASIC until college where freshmen had to learn it
> on the PDP-8.  Took me all of about 5 minutes to learn the language and
> about a half a day to do the entire semester of coursework.  Got me off
> to a good start on annoying my professors.
>
> I think that my first programming language was SNAP running on a PDP8-E in
> the (I don't remember the exact name) Princeton computer barn.  Because my
> dad worked at IBM I remember going over to his VP's house to learn APL on
> his home terminal.  FORTRAN on I think an IBM 1620 was next.  After that
> was Heinz's FSNAP on the Honeywell DDP-516 at BTL.  Never thought to
> ask before, Heinz - was FSNAP based on SNAP?  Assembler came after that,
> followed by C.  I know, what's the difference?  Then Pascal in college
> which was dreadful after C.  I asked my professor to give me a few pointers
> on how to program with fixed length arrays but he couldn't give me any :-)
>
> It's my opinion that BASIC was a good thing in its day but that that time
> has passed.  Part of what made it the goto language was its simplicity;
> there wasn't much to learn and there was no complex toolchain so time was
> spend on figuring out how to structure a problem so that it could be solved
> on a computer.  In my not very humble opinion, this is the fundamental
> (or should I say basic) problem with CS education today; the effort is
> focused on learning the language and the toolchain, not how to think and
> solve problems.  Somehow many of us learned to program in BASIC without a
> "Hello World" tutorial.
>
> Another big factor in those days was that the consequences for getting
> something wrong were pretty much nonexistent.  What was the worst that
> could happen, you'd accidentally output an obscenity?  Give what computers
> were used for back then, getting the math wrong was more likely than having
> a logic error.  I didn't have to worry about buggy code destroying anything
> until a project where I modified FSNAP to control semiconductor test
> equipment.
>
> I have tried when mentoring to get people to start with simple
> character oriented programs but of course everyone (especially boys)
> want to start with a video game.  This immediately means having to deal
> with multithreaded code (even if it's somewhat hidden) and complex APIs.
> All of this is a distraction from learning how to think and solve problems.
> As a result, we're producing a lot of "programmers" who can wrangle this
> stuff while having no idea how to solve a problem.  I think that a glance
> at stackoverflow backs me up here.  It's extremely frustrating: "I want to
> write a video game where I can shoot something."  "Cool.  Let's learn
> some physics."  "I don't want to learn physics, I want to shoot something."
>
> As an aside, I saw an article recently where someone was lauding the
> github "AI" code writing thing.  The author wrote something like "Wow.
> I asked it to replace spaces in a string with underscores and it just
> gave me the code."  Arrrrggggghhhh!!!  IMNVHO this person should never be
> allowed near a computer.  If you can't do this without help you shouldn't
> be programming.
>
> Like usual, I'm rambling, but one more related thing.  I'm mentoring a CS
> student who has to do a project this year.  My advice was that I didn't
> care what the project actually did, but that it should be based on an
> Arduino and written in C and assembler without any of the sketch library
> stuff.  The goal being to learn to read a data sheet, program I/O devices,
> and handle interrupts.  All on a processor that's not too complicated.
>
> Jon


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

* Re: [TUHS] Book Recommendation
  2021-11-16 17:02     ` [TUHS] Book Recommendation Will Senn
@ 2021-11-16 21:38       ` John Cowan
  2021-11-16 21:46         ` Will Senn
  0 siblings, 1 reply; 62+ messages in thread
From: John Cowan @ 2021-11-16 21:38 UTC (permalink / raw)
  To: Will Senn; +Cc: TUHS main list

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

On Tue, Nov 16, 2021 at 12:06 PM Will Senn <will.senn@gmail.com> wrote:


> On a less positive note. The professors who originally developed it at
> Dartmouth could never quite see there way clear to open source it. True
> BASIC? pshaw :).
>

Yes, well, universities have always been all about the money.

> There was a time when I would have loved to run BASIC on linux, bsd, then
> Mac and have it be consistent across the platforms, other than as a
> curiosity, that time has gone.
>

Not so much.  Bywater Basic (bwbasic), which is a much-extended clone of
GW-Basic, and a clone of Commodore-64 Basic (cbmbasic) are both open
source, TTY-oriented, and portable to most operating systems and Windows.
There are lots of other Basics around: see <
https://en.wikipedia.org/wiki/List_of_BASIC_dialects>.

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

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

* Re: [TUHS] Book Recommendation
  2021-11-16 21:38       ` John Cowan
@ 2021-11-16 21:46         ` Will Senn
  0 siblings, 0 replies; 62+ messages in thread
From: Will Senn @ 2021-11-16 21:46 UTC (permalink / raw)
  To: John Cowan; +Cc: TUHS main list

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

On 11/16/21 3:38 PM, John Cowan wrote:
>
> Not so much.  Bywater Basic (bwbasic), which is a much-extended clone 
> of GW-Basic, and a clone of Commodore-64 Basic (cbmbasic) are both 
> open source, TTY-oriented, and portable to most operating systems and 
> Windows.  There are lots of other Basics around: see 
> <https://en.wikipedia.org/wiki/List_of_BASIC_dialects>.
>
I meant those times were gone for me. BASIC is alive and well and there 
are versions for pretty much any platform now :).

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

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

* Re: [TUHS] Book Recommendation
  2021-12-06  4:42   ` Dan Halbert
@ 2021-12-06  5:18     ` Charles H. Sauer
  0 siblings, 0 replies; 62+ messages in thread
From: Charles H. Sauer @ 2021-12-06  5:18 UTC (permalink / raw)
  To: Dan Halbert; +Cc: tuhs

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



> On Dec 5, 2021, at 10:42 PM, Dan Halbert <halbert@halwitz.org> wrote:
> 
> On 12/5/21 11:25 PM, Adam Thornton wrote:
>> I wonder how many of you don't know about Don Lancaster.
>> 
>> Pioneer in home computing back when that meant something, inventor of a very low cost 1970s video terminal (the TV Typewriter), tremendously skilled hacker, brilliant guy.
>> 
> 
> In 1970, in eighth grade, I learned digital logic from his "RTL Cookbook" and the SWTPC Digital Logic Microlab, from Popular Electronics: https://www.tinaja.com/glib/microlab.pdf, both of which I still have.

In 1972, while i was still ambivalent about my music ambitions, in the second year of my transition to computer ambitions, pondering the combination of those ambitions, I built one of Lancaster’s function generator projects, depicted on the cover at https://worldradiohistory.com/Archive-Radio-Electronics/70s/1972/Radio-Electronics-1972-09.pdf <https://worldradiohistory.com/Archive-Radio-Electronics/70s/1972/Radio-Electronics-1972-09.pdf>. I think i still have  it in the garage, but am not sure if I could still get it to work.

--
voice: +1.512.784.7526       e-mail: sauer@technologists.com <mailto:sauer@technologists.com>           
fax: +1.512.346.5240         web: https://technologists.com/sauer/ <http://technologists.com/sauer/>
Facebook/Google/Skype/Twitter: CharlesHSauer


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

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

* Re: [TUHS] Book Recommendation
  2021-12-06  4:25 ` Adam Thornton
@ 2021-12-06  4:42   ` Dan Halbert
  2021-12-06  5:18     ` Charles H. Sauer
  0 siblings, 1 reply; 62+ messages in thread
From: Dan Halbert @ 2021-12-06  4:42 UTC (permalink / raw)
  To: tuhs

On 12/5/21 11:25 PM, Adam Thornton wrote:
> I wonder how many of you don't know about Don Lancaster.
>
> Pioneer in home computing back when that meant something, inventor of 
> a very low cost 1970s video terminal (the TV Typewriter), tremendously 
> skilled hacker, brilliant guy.
>

In 1970, in eighth grade, I learned digital logic from his "RTL 
Cookbook" and the SWTPC Digital Logic Microlab, from Popular 
Electronics: https://www.tinaja.com/glib/microlab.pdf, both of which I 
still have.

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

* Re: [TUHS] Book Recommendation
  2021-12-03  2:50 Douglas McIlroy
@ 2021-12-06  4:25 ` Adam Thornton
  2021-12-06  4:42   ` Dan Halbert
  0 siblings, 1 reply; 62+ messages in thread
From: Adam Thornton @ 2021-12-06  4:25 UTC (permalink / raw)
  To: Douglas McIlroy, The Eunuchs Hysterical Society,
	Computer Old Farts Followers

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

Probably time to move this to COFF, but

along the line of Fission for Program Comprehension....

I wonder how many of you don't know about Don Lancaster.

Pioneer in home computing back when that meant something, inventor of a
very low cost 1970s video terminal (the TV Typewriter), tremendously
skilled hacker, brilliant guy.

Also still alive, lives a couple hours away from me in Safford, AZ, and has
been doing fantastic research on Native American hanging canals for the
last couple decades.

Anyway: he wrote a magnificent piece on how to understand a (6502) program
from its disassembly, which reminded me of Gibbons's work:
https://www.tinaja.com/ebooks/tearing_rework.pdf

I don't think Don ever had a lot of crossover with the more academic world
of Unix people, but he's one of my heroes and I have learned a hell of a
lot from his works.

Adam

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

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

* Re: [TUHS] Book Recommendation
@ 2021-12-03  2:50 Douglas McIlroy
  2021-12-06  4:25 ` Adam Thornton
  0 siblings, 1 reply; 62+ messages in thread
From: Douglas McIlroy @ 2021-12-03  2:50 UTC (permalink / raw)
  To: TUHS main list, duncanmak

http://www.cs.ox.ac.uk/jeremy.gibbons/publications/fission.pdf

Duncan Mak wrote

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

^ permalink raw reply	[flat|nested] 62+ 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; 62+ 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] 62+ 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; 62+ 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] 62+ messages in thread

* Re: [TUHS] Book Recommendation
  2021-11-16 17:00 Douglas McIlroy
       [not found] ` <CAKH6PiXinxBQGRqoeGMcG9CwTA5BNeU-LY164f-ZLYA4obsyuA@mail.g mail.com>
  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
  2 siblings, 2 replies; 62+ 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] 62+ messages in thread

* Re: [TUHS] Book Recommendation
  2021-11-24 18:40         ` Larry McVoy
  2021-11-24 19:39           ` Clem Cole
@ 2021-11-25 10:26           ` Tom Ivar Helbekkmo via TUHS
  1 sibling, 0 replies; 62+ messages in thread
From: Tom Ivar Helbekkmo via TUHS @ 2021-11-25 10:26 UTC (permalink / raw)
  To: Larry McVoy; +Cc: TUHS main list

Larry McVoy <lm@mcvoy.com> writes:

> SMIT - just say no.

I remember it being useful for one thing: when I was unsure of the
correct way to do some AIX specific operation, I could enter SMIT, get
to where it was ready to do it for me, and it would show me the command
line it was about to run.  Then I could reread the man page for that
command, knowing which options and parameters SMIT would use.  So as a
learning tool it wasn't all bad.

-tih
-- 
Most people who graduate with CS degrees don't understand the significance
of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay

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

* Re: [TUHS] Book Recommendation
  2021-11-24 20:13       ` arnold
  2021-11-24 20:18         ` Will Senn
@ 2021-11-25  7:22         ` arnold
  1 sibling, 0 replies; 62+ messages in thread
From: arnold @ 2021-11-25  7:22 UTC (permalink / raw)
  To: thomas.paulsen, rich.salz, arnold; +Cc: tuhs

What I meant to write here, before my ssh connection dropped, was
that FORTRAN also did not reserve keywords.

Arnold

arnold@skeeve.com wrote:

> Richard Salz <rich.salz@gmail.com> wrote:
>
> > I asked my pal Barry Shein, who many of you know, if he had his PL/1 syntax
> > horror lying around, and he did.  He said: "this was tested on the Iron
> > Spring Software PL/1 compiler running on openSuSe Linux (
> > http://www.iron-spring.com/)"
> >
> > IBM still uses PL/1.  Remember, the main definition of "legacy" is
> > "revenue-producing."
> >
> > TRY:PROC OPTIONS(MAIN);
> >    DCL (IF,THEN,ELSE) FIXED BINARY (31);
> >
> >    IF = 1;
> >    THEN = 2;
> >    ELSE = 3;
> >
> >    IF IF = THEN THEN THEN = IF ; ELSE ELSE = THEN;
> >
> > END TRY;

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

* Re: [TUHS] Book Recommendation
  2021-11-24 15:18     ` Richard Salz
                         ` (3 preceding siblings ...)
  2021-11-24 20:15       ` Rob Pike
@ 2021-11-24 22:19       ` Charles Anthony
  4 siblings, 0 replies; 62+ messages in thread
From: Charles Anthony @ 2021-11-24 22:19 UTC (permalink / raw)
  To: Richard Salz; +Cc: TUHS main list

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

On Wed, Nov 24, 2021 at 7:23 AM Richard Salz <rich.salz@gmail.com> wrote:

> ....
>

          Compiled by: Multics PL/I Compiler, Release 33f, of February 11,
2017
          Compiled at: Installation and location
          Compiled on: 11/24/21  1411.5 pst Wed
              Options: table list

        1 try:proc options(main);
        2    dcl (if,then,else) fixed binary (31);
        3
        4    if = 1;
        5    then = 2;
        6    else = 3;
        7
        8    if if = then then then = if; else else = then;
        9
       10 end try;

-- Charles

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

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

* Re: [TUHS] Book Recommendation
  2021-11-24 20:27         ` Rob Pike
@ 2021-11-24 21:27           ` Richard Salz
  0 siblings, 0 replies; 62+ messages in thread
From: Richard Salz @ 2021-11-24 21:27 UTC (permalink / raw)
  To: Rob Pike; +Cc: TUHS main list

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

Yeah PROCEDURE is the official word, but if you're gonna low DCL heresy,
might as well throw in PROC.

On Wed, Nov 24, 2021 at 3:28 PM Rob Pike <robpike@gmail.com> wrote:

> Also isn't it PROCEDURE? I don't remember PROC.
>
> -rob
>
> On Thu, Nov 25, 2021 at 7:15 AM Rob Pike <robpike@gmail.com> wrote:
> >
> > I thought it was
> >
> > TRY:PROC OPTIONS(MAIN);
> >    DCL (IF,THEN,ELSE) FIXED BINARY (31);
> >
> >    IF = 1;
> >    THEN = 2;
> >    ELSE = 3;
> >
> >    IF IF = THEN THEN THEN = IF ; ELSE ELSE IF = THEN = ELSE;
> >
> > END TRY;
> >
> > But yeah.
> >
> > Best to Barry.
> >
> > -rob
> >
> > On Thu, Nov 25, 2021 at 2:23 AM Richard Salz <rich.salz@gmail.com>
> wrote:
> > >
> > > I asked my pal Barry Shein, who many of you know, if he had his PL/1
> syntax horror lying around, and he did.  He said: "this was tested on the
> Iron Spring Software PL/1 compiler running on openSuSe Linux (
> http://www.iron-spring.com/)"
> > >
> > > IBM still uses PL/1.  Remember, the main definition of "legacy" is
> "revenue-producing."
> > >
> > > TRY:PROC OPTIONS(MAIN);
> > >    DCL (IF,THEN,ELSE) FIXED BINARY (31);
> > >
> > >    IF = 1;
> > >    THEN = 2;
> > >    ELSE = 3;
> > >
> > >    IF IF = THEN THEN THEN = IF ; ELSE ELSE = THEN;
> > >
> > > END TRY;
> > >
>

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

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

* Re: [TUHS] Book Recommendation
  2021-11-24 20:15       ` Rob Pike
  2021-11-24 20:21         ` joe mcguckin
@ 2021-11-24 20:27         ` Rob Pike
  2021-11-24 21:27           ` Richard Salz
  1 sibling, 1 reply; 62+ messages in thread
From: Rob Pike @ 2021-11-24 20:27 UTC (permalink / raw)
  To: Richard Salz; +Cc: TUHS main list

Also isn't it PROCEDURE? I don't remember PROC.

-rob

On Thu, Nov 25, 2021 at 7:15 AM Rob Pike <robpike@gmail.com> wrote:
>
> I thought it was
>
> TRY:PROC OPTIONS(MAIN);
>    DCL (IF,THEN,ELSE) FIXED BINARY (31);
>
>    IF = 1;
>    THEN = 2;
>    ELSE = 3;
>
>    IF IF = THEN THEN THEN = IF ; ELSE ELSE IF = THEN = ELSE;
>
> END TRY;
>
> But yeah.
>
> Best to Barry.
>
> -rob
>
> On Thu, Nov 25, 2021 at 2:23 AM Richard Salz <rich.salz@gmail.com> wrote:
> >
> > I asked my pal Barry Shein, who many of you know, if he had his PL/1 syntax horror lying around, and he did.  He said: "this was tested on the Iron Spring Software PL/1 compiler running on openSuSe Linux (http://www.iron-spring.com/)"
> >
> > IBM still uses PL/1.  Remember, the main definition of "legacy" is "revenue-producing."
> >
> > TRY:PROC OPTIONS(MAIN);
> >    DCL (IF,THEN,ELSE) FIXED BINARY (31);
> >
> >    IF = 1;
> >    THEN = 2;
> >    ELSE = 3;
> >
> >    IF IF = THEN THEN THEN = IF ; ELSE ELSE = THEN;
> >
> > END TRY;
> >

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

* Re: [TUHS] Book Recommendation
  2021-11-24 20:15       ` Rob Pike
@ 2021-11-24 20:21         ` joe mcguckin
  2021-11-24 20:27         ` Rob Pike
  1 sibling, 0 replies; 62+ messages in thread
From: joe mcguckin @ 2021-11-24 20:21 UTC (permalink / raw)
  To: Rob Pike; +Cc: TUHS main list

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

In PL/I, language keywords are not reserved. Makes for interesting work when writing the lex scanner.


Joe McGuckin
ViaNet Communications

joe@via.net
650-207-0372 cell
650-213-1302 office
650-969-2124 fax



> On Nov 24, 2021, at 12:15 PM, Rob Pike <robpike@gmail.com> wrote:
> 
> I thought it was
> 
> TRY:PROC OPTIONS(MAIN);
>   DCL (IF,THEN,ELSE) FIXED BINARY (31);
> 
>   IF = 1;
>   THEN = 2;
>   ELSE = 3;
> 
>   IF IF = THEN THEN THEN = IF ; ELSE ELSE IF = THEN = ELSE;
> 
> END TRY;
> 
> But yeah.
> 
> Best to Barry.
> 
> -rob
> 
> On Thu, Nov 25, 2021 at 2:23 AM Richard Salz <rich.salz@gmail.com> wrote:
>> 
>> I asked my pal Barry Shein, who many of you know, if he had his PL/1 syntax horror lying around, and he did.  He said: "this was tested on the Iron Spring Software PL/1 compiler running on openSuSe Linux (http://www.iron-spring.com/)"
>> 
>> IBM still uses PL/1.  Remember, the main definition of "legacy" is "revenue-producing."
>> 
>> TRY:PROC OPTIONS(MAIN);
>>   DCL (IF,THEN,ELSE) FIXED BINARY (31);
>> 
>>   IF = 1;
>>   THEN = 2;
>>   ELSE = 3;
>> 
>>   IF IF = THEN THEN THEN = IF ; ELSE ELSE = THEN;
>> 
>> END TRY;
>> 


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

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

* Re: [TUHS] Book Recommendation
  2021-11-24 20:13       ` arnold
@ 2021-11-24 20:18         ` Will Senn
  2021-11-25  7:22         ` arnold
  1 sibling, 0 replies; 62+ messages in thread
From: Will Senn @ 2021-11-24 20:18 UTC (permalink / raw)
  To: tuhs

Since we're all recommending books, I'd like to recommend:

Richard Fitzpatrick's translation of J. L. Heiberg's Euclid's Elements 
of Geometry. It's fantastic, and without Euclid, we'd prolly not have 
unix...

Will

On 11/24/21 2:13 PM, arnold@skeeve.com wrote:
> Richard Salz <rich.salz@gmail.com> wrote:
>
>> I asked my pal Barry Shein, who many of you know, if he had his PL/1 syntax
>> horror lying around, and he did.  He said: "this was tested on the Iron
>> Spring Software PL/1 compiler running on openSuSe Linux (
>> http://www.iron-spring.com/)"
>>
>> IBM still uses PL/1.  Remember, the main definition of "legacy" is
>> "revenue-producing."
>>
>> TRY:PROC OPTIONS(MAIN);
>>     DCL (IF,THEN,ELSE) FIXED BINARY (31);
>>
>>     IF = 1;
>>     THEN = 2;
>>     ELSE = 3;
>>
>>     IF IF = THEN THEN THEN = IF ; ELSE ELSE = THEN;
>>
>> END TRY;


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

* Re: [TUHS] Book Recommendation
  2021-11-24 15:18     ` Richard Salz
                         ` (2 preceding siblings ...)
  2021-11-24 20:13       ` arnold
@ 2021-11-24 20:15       ` Rob Pike
  2021-11-24 20:21         ` joe mcguckin
  2021-11-24 20:27         ` Rob Pike
  2021-11-24 22:19       ` Charles Anthony
  4 siblings, 2 replies; 62+ messages in thread
From: Rob Pike @ 2021-11-24 20:15 UTC (permalink / raw)
  To: Richard Salz; +Cc: TUHS main list

I thought it was

TRY:PROC OPTIONS(MAIN);
   DCL (IF,THEN,ELSE) FIXED BINARY (31);

   IF = 1;
   THEN = 2;
   ELSE = 3;

   IF IF = THEN THEN THEN = IF ; ELSE ELSE IF = THEN = ELSE;

END TRY;

But yeah.

Best to Barry.

-rob

On Thu, Nov 25, 2021 at 2:23 AM Richard Salz <rich.salz@gmail.com> wrote:
>
> I asked my pal Barry Shein, who many of you know, if he had his PL/1 syntax horror lying around, and he did.  He said: "this was tested on the Iron Spring Software PL/1 compiler running on openSuSe Linux (http://www.iron-spring.com/)"
>
> IBM still uses PL/1.  Remember, the main definition of "legacy" is "revenue-producing."
>
> TRY:PROC OPTIONS(MAIN);
>    DCL (IF,THEN,ELSE) FIXED BINARY (31);
>
>    IF = 1;
>    THEN = 2;
>    ELSE = 3;
>
>    IF IF = THEN THEN THEN = IF ; ELSE ELSE = THEN;
>
> END TRY;
>

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

* Re: [TUHS] Book Recommendation
  2021-11-24 15:18     ` Richard Salz
  2021-11-24 15:45       ` Larry McVoy
  2021-11-24 18:34       ` Rich Morin
@ 2021-11-24 20:13       ` arnold
  2021-11-24 20:18         ` Will Senn
  2021-11-25  7:22         ` arnold
  2021-11-24 20:15       ` Rob Pike
  2021-11-24 22:19       ` Charles Anthony
  4 siblings, 2 replies; 62+ messages in thread
From: arnold @ 2021-11-24 20:13 UTC (permalink / raw)
  To: thomas.paulsen, rich.salz; +Cc: tuhs

Richard Salz <rich.salz@gmail.com> wrote:

> I asked my pal Barry Shein, who many of you know, if he had his PL/1 syntax
> horror lying around, and he did.  He said: "this was tested on the Iron
> Spring Software PL/1 compiler running on openSuSe Linux (
> http://www.iron-spring.com/)"
>
> IBM still uses PL/1.  Remember, the main definition of "legacy" is
> "revenue-producing."
>
> TRY:PROC OPTIONS(MAIN);
>    DCL (IF,THEN,ELSE) FIXED BINARY (31);
>
>    IF = 1;
>    THEN = 2;
>    ELSE = 3;
>
>    IF IF = THEN THEN THEN = IF ; ELSE ELSE = THEN;
>
> END TRY;


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

* Re: [TUHS] Book Recommendation
  2021-11-24 19:39           ` Clem Cole
@ 2021-11-24 20:02             ` Larry McVoy
  0 siblings, 0 replies; 62+ messages in thread
From: Larry McVoy @ 2021-11-24 20:02 UTC (permalink / raw)
  To: Clem Cole; +Cc: TUHS main list

HP was much better than AIX, you could ignore their admin crud and
just edit the /etc files and stuff worked.  With AIX, I never figured
out how to not use SMIT, it was pretty intertwined with everything.
It was super annoying, I'm not saying it didn't work, it did, but it was
very clunky and you couldn't just go edit /etc/fstab and make stuff work
(well, I couldn't, maybe there is someone who could).  I hated it.

On Wed, Nov 24, 2021 at 02:39:19PM -0500, Clem Cole wrote:
> On Wed, Nov 24, 2021 at 1:43 PM Larry McVoy <lm@mcvoy.com> wrote:
> 
> > SMIT - just say no.
> 
> There were a number of things IBM did well with AIX so I'm not quite so
> glib knocking everything from them.
> 
> But I agree that SMIT was the not so well thought out piece and never fully
> understood why it ended up being such a bad example of systems SW. ... but
>  .... I always suspected that SMIT was an example of what IT managers
> running mainframe thought of UNIX.  The folks at IBM set out (and did) a
> thorough and well thought out requirements study IBM style ... and then ...
> they only talked to Mainframe IT folks, not people that actually had
> experience in running UNIX in a production setting from their (like on a
> BSD or Ultrix based Vax or SunOS - i.e. instead of talking to the folks
> that came to a USENIX LISA, they talked to customers that came to a SHARE
> meeting).  So they solved the wrong set of problems.  SMIT was a force fit
> of UNIX to mainframe shop and never was quite right for either group.  I'm
> not sure the IT folks really liked it much better than the UNIX folks, but
> at least for them it used their terminology and their concepts (*e.g.* DASD
> *vs.* DISK).
> 
> BTW:  HP, I thought had a similar issue and they did not really understand
> the UNIX user.   DEC parts of so got it/parts did not.  Many DECies wanted
> Ultrix == VMS (and really wanted Unix to go away since VMS and RXS were
> really better in their hearts), but at least there were a ton of folks
> inside of DEC doing the Unix work that 'got it.'
> 
> As I have said before, it was always interesting having all of them as
> customers at LCC.  You got to see the good and bad of all the systems
> vendors.

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

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

* Re: [TUHS] Book Recommendation
  2021-11-24 18:40         ` Larry McVoy
@ 2021-11-24 19:39           ` Clem Cole
  2021-11-24 20:02             ` Larry McVoy
  2021-11-25 10:26           ` Tom Ivar Helbekkmo via TUHS
  1 sibling, 1 reply; 62+ messages in thread
From: Clem Cole @ 2021-11-24 19:39 UTC (permalink / raw)
  To: Larry McVoy; +Cc: TUHS main list

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

On Wed, Nov 24, 2021 at 1:43 PM Larry McVoy <lm@mcvoy.com> wrote:

> SMIT - just say no.

There were a number of things IBM did well with AIX so I'm not quite so
glib knocking everything from them.

But I agree that SMIT was the not so well thought out piece and never fully
understood why it ended up being such a bad example of systems SW. ... but
 .... I always suspected that SMIT was an example of what IT managers
running mainframe thought of UNIX.  The folks at IBM set out (and did) a
thorough and well thought out requirements study IBM style ... and then ...
they only talked to Mainframe IT folks, not people that actually had
experience in running UNIX in a production setting from their (like on a
BSD or Ultrix based Vax or SunOS - i.e. instead of talking to the folks
that came to a USENIX LISA, they talked to customers that came to a SHARE
meeting).  So they solved the wrong set of problems.  SMIT was a force fit
of UNIX to mainframe shop and never was quite right for either group.  I'm
not sure the IT folks really liked it much better than the UNIX folks, but
at least for them it used their terminology and their concepts (*e.g.* DASD
*vs.* DISK).

BTW:  HP, I thought had a similar issue and they did not really understand
the UNIX user.   DEC parts of so got it/parts did not.  Many DECies wanted
Ultrix == VMS (and really wanted Unix to go away since VMS and RXS were
really better in their hearts), but at least there were a ton of folks
inside of DEC doing the Unix work that 'got it.'

As I have said before, it was always interesting having all of them as
customers at LCC.  You got to see the good and bad of all the systems
vendors.

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

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

* Re: [TUHS] Book Recommendation
  2021-11-24 18:34       ` Rich Morin
@ 2021-11-24 18:40         ` Larry McVoy
  2021-11-24 19:39           ` Clem Cole
  2021-11-25 10:26           ` Tom Ivar Helbekkmo via TUHS
  0 siblings, 2 replies; 62+ messages in thread
From: Larry McVoy @ 2021-11-24 18:40 UTC (permalink / raw)
  To: Rich Morin; +Cc: TUHS main list

On Wed, Nov 24, 2021 at 10:34:08AM -0800, Rich Morin wrote:
> Speaking of Barry and IBM, I've always loved his snark on AIX:  "It will remind you of Unix."

Barely.  I think after SCO, AIX is the Unix I loved the least.

SMIT - just say no.

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

* Re: [TUHS] Book Recommendation
  2021-11-24 15:18     ` Richard Salz
  2021-11-24 15:45       ` Larry McVoy
@ 2021-11-24 18:34       ` Rich Morin
  2021-11-24 18:40         ` Larry McVoy
  2021-11-24 20:13       ` arnold
                         ` (2 subsequent siblings)
  4 siblings, 1 reply; 62+ messages in thread
From: Rich Morin @ 2021-11-24 18:34 UTC (permalink / raw)
  To: TUHS main list

Speaking of Barry and IBM, I've always loved his snark on AIX:  "It will remind you of Unix."

-r

P.S.  My guess is that this code sets ELSE to 2.  True? 

> On Nov 24, 2021, at 07:18, Richard Salz <rich.salz@gmail.com> wrote:
> 
> I asked my pal Barry Shein, who many of you know, if he had his PL/1 syntax horror lying around, and he did.  He said: "this was tested on the Iron Spring Software PL/1 compiler running on openSuSe Linux (http://www.iron-spring.com/)"
> 
> IBM still uses PL/1.  Remember, the main definition of "legacy" is "revenue-producing."
> 
> TRY:PROC OPTIONS(MAIN);
>    DCL (IF,THEN,ELSE) FIXED BINARY (31);
> 
>    IF = 1;
>    THEN = 2;
>    ELSE = 3;
> 
>    IF IF = THEN THEN THEN = IF ; ELSE ELSE = THEN;
> 
> END TRY;



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

* Re: [TUHS] Book Recommendation
@ 2021-11-24 15:50 Norman Wilson
  0 siblings, 0 replies; 62+ messages in thread
From: Norman Wilson @ 2021-11-24 15:50 UTC (permalink / raw)
  To: tuhs

Larry McVoy:

  Say hi to Barry for me, I knew him back in the UUCP days, he was always
  pleasant.

====

And for me.  Knew him back in my DECUS days.  Also tell him
that since he runs the World, it's all his fault.

Norman Wilson
Toronto ON

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

* Re: [TUHS] Book Recommendation
  2021-11-24 15:18     ` Richard Salz
@ 2021-11-24 15:45       ` Larry McVoy
  2021-11-24 18:34       ` Rich Morin
                         ` (3 subsequent siblings)
  4 siblings, 0 replies; 62+ messages in thread
From: Larry McVoy @ 2021-11-24 15:45 UTC (permalink / raw)
  To: Richard Salz; +Cc: TUHS main list

Say hi to Barry for me, I knew him back in the UUCP days, he was always
pleasant.

That bit of PL/1 is nuts but funny.

On Wed, Nov 24, 2021 at 10:18:56AM -0500, Richard Salz wrote:
> I asked my pal Barry Shein, who many of you know, if he had his PL/1 syntax
> horror lying around, and he did.  He said: "this was tested on the Iron
> Spring Software PL/1 compiler running on openSuSe Linux (
> http://www.iron-spring.com/)"
> 
> IBM still uses PL/1.  Remember, the main definition of "legacy" is
> "revenue-producing."
> 
> TRY:PROC OPTIONS(MAIN);
>    DCL (IF,THEN,ELSE) FIXED BINARY (31);
> 
>    IF = 1;
>    THEN = 2;
>    ELSE = 3;
> 
>    IF IF = THEN THEN THEN = IF ; ELSE ELSE = THEN;
> 
> END TRY;

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

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

* Re: [TUHS] Book Recommendation
  2021-11-23 21:54   ` Thomas Paulsen
@ 2021-11-24 15:18     ` Richard Salz
  2021-11-24 15:45       ` Larry McVoy
                         ` (4 more replies)
  0 siblings, 5 replies; 62+ messages in thread
From: Richard Salz @ 2021-11-24 15:18 UTC (permalink / raw)
  To: Thomas Paulsen; +Cc: TUHS main list

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

I asked my pal Barry Shein, who many of you know, if he had his PL/1 syntax
horror lying around, and he did.  He said: "this was tested on the Iron
Spring Software PL/1 compiler running on openSuSe Linux (
http://www.iron-spring.com/)"

IBM still uses PL/1.  Remember, the main definition of "legacy" is
"revenue-producing."

TRY:PROC OPTIONS(MAIN);
   DCL (IF,THEN,ELSE) FIXED BINARY (31);

   IF = 1;
   THEN = 2;
   ELSE = 3;

   IF IF = THEN THEN THEN = IF ; ELSE ELSE = THEN;

END TRY;

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

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

* Re: [TUHS] Book Recommendation
  2021-11-23  2:28 ` Mary Ann Horton
  2021-11-23  7:57   ` Henry Bent
@ 2021-11-23 21:54   ` Thomas Paulsen
  2021-11-24 15:18     ` Richard Salz
  1 sibling, 1 reply; 62+ messages in thread
From: Thomas Paulsen @ 2021-11-23 21:54 UTC (permalink / raw)
  To: Mary Ann Horton; +Cc: tuhs

Hi,

I remember that PL-1 was regarded in the 70-80ths as a superior programming language, incorporating the best concepts of the languages Mary enumerated. There even was a PL-1 inspired SPL language by siemens for the bs2000 mainframe os including bit fields etc. for system programming like C. Large parts of the start-amadeus ticketing-software were written in SPL. Thus PL-1 and its derivates were very high-ranked in the 70ths and 80ths, regarded as the ultimate ratio of the programming languages by many mainframe experts in those days.
I mean we are now entering the mainframe horizon, totally different to our UNIX and C mini computer, workstation and PC world we all are firm with.

---------------------------------------------------------------------------------------------
PL/I was my favorite mainframe programming language my last two years as

an undergrad. I liked how it incorporated ideas from FORTRAN, ALGOL, and

COBOL. My student job was to enhance a PL/I package for a History professor.


As a grad student in 1976, my first job as a TA was to teach PL/I to 
undergrads. There were a lot of business students in the class. We 
thought PL/I was likely to be the future of business programming, as a 
better alternative to COBOL.

I was turned on to V6 UNIX and C in 1977, and I forgot all about PL/I.

     Mary Ann

On 11/16/2021 6:57 AM, Douglas McIlroy wrote:
> The following remark stirred old memories. Apologies for straying off

> the path of TUHS.
>
>> I have gotten the impression that [PL/I] was a language that was
beloved by no one.
> As I was a designer of PL/I, an implementer of EPL (the preliminary

> PL/I compiler used to build Multics), and author of the first PL/I
> program to appear in the ACM Collected Algorithms, it's a bit hard
to
> admit that PL/I was "insignificant". I'm proud, though, of
having
> conceived the SIGNAL statement, which pioneered exception handling,

> and the USES and SETS attributes, which unfortunately sank into
> oblivion. I also spurred Bud Lawson to invent -> for pointer-chasing.

> The former notation C(B(A)) became A->B->C. This was PL/I's gift
to C.
>
> After the ACM program I never wrote another line of PL/I.
> Gratification finally came forty years on when I met a retired
> programmer who, unaware of my PL/I connection, volunteered that she

> had loved PL/I above all other programming languages.
>
> Doug




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

* Re: [TUHS] Book Recommendation
  2021-11-23 19:04         ` Al Kossow
@ 2021-11-23 19:39           ` Lawrence Stewart
  0 siblings, 0 replies; 62+ messages in thread
From: Lawrence Stewart @ 2021-11-23 19:39 UTC (permalink / raw)
  To: Al Kossow; +Cc: tuhs



> On 2021, Nov 23, at 2:04 PM, Al Kossow <aek@bitsavers.org> wrote:
> 
> On 11/23/21 10:54 AM, Ron Natalie wrote:
> 
>>> I have a vague recollection that PL/X was a PL/I variant used for internal development on VM/CMS.
> 
> PL/S

PL/S also led to PL.8 which was used for the first IBM Risc


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

* Re: [TUHS] Book Recommendation
  2021-11-23 17:26     ` Adam Thornton
  2021-11-23 18:54       ` Ron Natalie
@ 2021-11-23 19:08       ` Ron Natalie
  1 sibling, 0 replies; 62+ messages in thread
From: Ron Natalie @ 2021-11-23 19:08 UTC (permalink / raw)
  To: Adam Thornton; +Cc: TUHS main list

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

Tpl

> On Nov 23, 2021, at 12:31, Adam Thornton <athornton@gmail.com> wrote:
> 
> 
> 
>> On Tue, Nov 23, 2021 at 1:00 AM Henry Bent <henry.r.bent@gmail.com> wrote:
>> What language were the PL/I compilers written in?
>> 
>> Wikipedia claims that IBM is still developing a PL/I compiler, which I suppose I have no reason to disbelieve, but I'm very curious as to who is using it and for what purpose.
>> 
>> 
>> 
>> I have a vague recollection that PL/X was a PL/I variant used for internal development on VM/CMS.  Does that ring any bells for anyone?
>> 
>> Adam

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

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

* Re: [TUHS] Book Recommendation
  2021-11-23 18:54       ` Ron Natalie
@ 2021-11-23 19:04         ` Al Kossow
  2021-11-23 19:39           ` Lawrence Stewart
  0 siblings, 1 reply; 62+ messages in thread
From: Al Kossow @ 2021-11-23 19:04 UTC (permalink / raw)
  To: tuhs

On 11/23/21 10:54 AM, Ron Natalie wrote:

>> I have a vague recollection that PL/X was a PL/I variant used for internal development on VM/CMS.

PL/S

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

* Re: [TUHS] Book Recommendation
  2021-11-23 17:26     ` Adam Thornton
@ 2021-11-23 18:54       ` Ron Natalie
  2021-11-23 19:04         ` Al Kossow
  2021-11-23 19:08       ` Ron Natalie
  1 sibling, 1 reply; 62+ messages in thread
From: Ron Natalie @ 2021-11-23 18:54 UTC (permalink / raw)
  To: Adam Thornton; +Cc: TUHS main list

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



> On Nov 23, 2021, at 12:31, Adam Thornton <athornton@gmail.com> wrote:
> 
> 
> 
>> On Tue, Nov 23, 2021 at 1:00 AM Henry Bent <henry.r.bent@gmail.com> wrote:
>> What language were the PL/I compilers written in?
>> 
>> Wikipedia claims that IBM is still developing a PL/I compiler, which I suppose I have no reason to disbelieve, but I'm very curious as to who is using it and for what purpose.
>> 
>> 
>> 
>> I have a vague recollection that PL/X was a PL/I variant used for internal development on VM/CMS.  Does that ring any bells for anyone?
>> 
>> Adam

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

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

* Re: [TUHS] Book Recommendation
  2021-11-23  7:57   ` Henry Bent
  2021-11-23  8:10     ` arnold
@ 2021-11-23 17:26     ` Adam Thornton
  2021-11-23 18:54       ` Ron Natalie
  2021-11-23 19:08       ` Ron Natalie
  1 sibling, 2 replies; 62+ messages in thread
From: Adam Thornton @ 2021-11-23 17:26 UTC (permalink / raw)
  To: Henry Bent; +Cc: TUHS main list

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

On Tue, Nov 23, 2021 at 1:00 AM Henry Bent <henry.r.bent@gmail.com> wrote:
What language were the PL/I compilers written in?

Wikipedia claims that IBM is still developing a PL/I compiler, which I
suppose I have no reason to disbelieve, but I'm very curious as to who is
using it and for what purpose.



I have a vague recollection that PL/X was a PL/I variant used for internal
development on VM/CMS.  Does that ring any bells for anyone?

Adam

>

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

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

* Re: [TUHS] Book Recommendation
  2021-11-23  8:10     ` arnold
@ 2021-11-23  8:28       ` Henry Bent
  0 siblings, 0 replies; 62+ messages in thread
From: Henry Bent @ 2021-11-23  8:28 UTC (permalink / raw)
  To: Aharon Robbins; +Cc: TUHS main list

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

On Tue, 23 Nov 2021 at 03:10, <arnold@skeeve.com> wrote:

> Henry Bent <henry.r.bent@gmail.com> wrote:
>
> > On Mon, 22 Nov 2021 at 21:31, Mary Ann Horton <mah@mhorton.net> wrote:
> >
> > > PL/I was my favorite mainframe programming language my last two years
> as
> > > an undergrad. I liked how it incorporated ideas from FORTRAN, ALGOL,
> and
> > > COBOL. My student job was to enhance a PL/I package for a History
> > > professor.
> > >
> >
> > What language were the PL/I compilers written in?
> >
> > Wikipedia claims that IBM is still developing a PL/I compiler, which I
> > suppose I have no reason to disbelieve, but I'm very curious as to who is
> > using it and for what purpose.
> >
> > -Henry
>
> PL/1 compiler for Linux: http://www.iron-spring.com/
>
> PL/1 front end for GCC (looks dead): pl1gcc.sourceforge.net


"Expect some more releases soon" and the last release was 0.0.whatever, in
2007.  I think that speaks volumes as to how popular PL/I is today.  That
being said, the Linux compiler does appear to be actively developed, and I
suppose I shouldn't be surprised that the two platforms for active
development are Linux and OS/2 (!).

I have a vague recollection of installing and playing with a PL/I compiler
demo for Ultrix, but I figured that the language was essentially dead at
that point.  I suppose I shouldn't be too surprised that there are still
people using it, as this is the world of "we wrote the specifications in
1975 and there's no reason to update them," but I have a hard time
imagining those companies being truly competitive, and an even harder time
imagining them attracting talent under retirement age.

-Henry

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

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

* Re: [TUHS] Book Recommendation
  2021-11-23  7:57   ` Henry Bent
@ 2021-11-23  8:10     ` arnold
  2021-11-23  8:28       ` Henry Bent
  2021-11-23 17:26     ` Adam Thornton
  1 sibling, 1 reply; 62+ messages in thread
From: arnold @ 2021-11-23  8:10 UTC (permalink / raw)
  To: mah, henry.r.bent; +Cc: tuhs

Henry Bent <henry.r.bent@gmail.com> wrote:

> On Mon, 22 Nov 2021 at 21:31, Mary Ann Horton <mah@mhorton.net> wrote:
>
> > PL/I was my favorite mainframe programming language my last two years as
> > an undergrad. I liked how it incorporated ideas from FORTRAN, ALGOL, and
> > COBOL. My student job was to enhance a PL/I package for a History
> > professor.
> >
>
> What language were the PL/I compilers written in?
>
> Wikipedia claims that IBM is still developing a PL/I compiler, which I
> suppose I have no reason to disbelieve, but I'm very curious as to who is
> using it and for what purpose.
>
> -Henry

PL/1 compiler for Linux: http://www.iron-spring.com/

PL/1 front end for GCC (looks dead): pl1gcc.sourceforge.net

:-)

Arnold

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

* Re: [TUHS] Book Recommendation
  2021-11-23  2:28 ` Mary Ann Horton
@ 2021-11-23  7:57   ` Henry Bent
  2021-11-23  8:10     ` arnold
  2021-11-23 17:26     ` Adam Thornton
  2021-11-23 21:54   ` Thomas Paulsen
  1 sibling, 2 replies; 62+ messages in thread
From: Henry Bent @ 2021-11-23  7:57 UTC (permalink / raw)
  To: Mary Ann Horton; +Cc: TUHS main list

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

On Mon, 22 Nov 2021 at 21:31, Mary Ann Horton <mah@mhorton.net> wrote:

> PL/I was my favorite mainframe programming language my last two years as
> an undergrad. I liked how it incorporated ideas from FORTRAN, ALGOL, and
> COBOL. My student job was to enhance a PL/I package for a History
> professor.
>

What language were the PL/I compilers written in?

Wikipedia claims that IBM is still developing a PL/I compiler, which I
suppose I have no reason to disbelieve, but I'm very curious as to who is
using it and for what purpose.

-Henry

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

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

* Re: [TUHS] Book Recommendation
  2021-11-16 14:57 Douglas McIlroy
  2021-11-16 15:22 ` Richard Salz
  2021-11-16 15:52 ` Ron Natalie
@ 2021-11-23  2:28 ` Mary Ann Horton
  2021-11-23  7:57   ` Henry Bent
  2021-11-23 21:54   ` Thomas Paulsen
  2 siblings, 2 replies; 62+ messages in thread
From: Mary Ann Horton @ 2021-11-23  2:28 UTC (permalink / raw)
  To: tuhs

PL/I was my favorite mainframe programming language my last two years as 
an undergrad. I liked how it incorporated ideas from FORTRAN, ALGOL, and 
COBOL. My student job was to enhance a PL/I package for a History professor.

As a grad student in 1976, my first job as a TA was to teach PL/I to 
undergrads. There were a lot of business students in the class. We 
thought PL/I was likely to be the future of business programming, as a 
better alternative to COBOL.

I was turned on to V6 UNIX and C in 1977, and I forgot all about PL/I.

     Mary Ann

On 11/16/2021 6:57 AM, Douglas McIlroy wrote:
> The following remark stirred old memories. Apologies for straying off
> the path of TUHS.
>
>> I have gotten the impression that [PL/I] was a language that was beloved by no one.
> As I was a designer of PL/I, an implementer of EPL (the preliminary
> PL/I compiler used to build Multics), and author of the first PL/I
> program to appear in the ACM Collected Algorithms, it's a bit hard to
> admit that PL/I was "insignificant". I'm proud, though, of having
> conceived the SIGNAL statement, which pioneered exception handling,
> and the USES and SETS attributes, which unfortunately sank into
> oblivion. I also spurred Bud Lawson to invent -> for pointer-chasing.
> The former notation C(B(A)) became A->B->C. This was PL/I's gift to C.
>
> After the ACM program I never wrote another line of PL/I.
> Gratification finally came forty years on when I met a retired
> programmer who, unaware of my PL/I connection, volunteered that she
> had loved PL/I above all other programming languages.
>
> Doug

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

* Re: [TUHS] Book Recommendation
  2021-11-16 20:02 ` Dan Cross
@ 2021-11-16 23:16   ` Douglas McIlroy
  0 siblings, 0 replies; 62+ messages in thread
From: Douglas McIlroy @ 2021-11-16 23:16 UTC (permalink / raw)
  To: Dan Cross; +Cc: TUHS main list

>> Incidentally, another BEFLIX innovation was the buddy system for
>> dynamic storage allocation.

> I thought that was due to Knuth?

I believe Knuth christened it. Knuth (TAOCP vol 1) attributes it to
Markowitz (1963) and, independently, to Knowlton (1965). So I stand
corrected. However, I know that Knowlton had been using it a long time
before he published.

I should also correct BEFLIX to L6, "[Bell] Labs Low-Level Linked List
Language". Knowlton used L6 in animation work, but I believe not in
the original BEFLIX.

Doug

On Tue, Nov 16, 2021 at 3:03 PM Dan Cross <crossd@gmail.com> wrote:
>
> On Tue, Nov 16, 2021 at 2:51 PM Douglas McIlroy <douglas.mcilroy@dartmouth.edu> wrote:
>>
>> Incidentally, another BEFLIX innovation was the buddy system for
>> dynamic storage allocation.
>
>
> I thought that was due to Knuth?
>
>         - Dan C.
>

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

* Re: [TUHS] Book Recommendation
  2021-11-16 17:00 Douglas McIlroy
       [not found] ` <CAKH6PiXinxBQGRqoeGMcG9CwTA5BNeU-LY164f-ZLYA4obsyuA@mail.g mail.com>
@ 2021-11-16 20:35 ` Bakul Shah
  2021-12-02 21:35 ` Duncan Mak
  2 siblings, 0 replies; 62+ 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] 62+ messages in thread

* Re: [TUHS] Book Recommendation
  2021-11-16 19:49 Douglas McIlroy
@ 2021-11-16 20:02 ` Dan Cross
  2021-11-16 23:16   ` Douglas McIlroy
  0 siblings, 1 reply; 62+ messages in thread
From: Dan Cross @ 2021-11-16 20:02 UTC (permalink / raw)
  To: Douglas McIlroy; +Cc: TUHS main list

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

On Tue, Nov 16, 2021 at 2:51 PM Douglas McIlroy <
douglas.mcilroy@dartmouth.edu> wrote:

> Incidentally, another BEFLIX innovation was the buddy system for
> dynamic storage allocation.
>

I thought that was due to Knuth?

        - Dan C.

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

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

* Re: [TUHS] Book Recommendation
@ 2021-11-16 19:49 Douglas McIlroy
  2021-11-16 20:02 ` Dan Cross
  0 siblings, 1 reply; 62+ messages in thread
From: Douglas McIlroy @ 2021-11-16 19:49 UTC (permalink / raw)
  To: jfoust, TUHS main list

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

It meant exactly what A->B->C means in C. Pixels had properties,
represented in data structures. One valid data type was pointer.

Incidentally, another BEFLIX innovation was the buddy system for
dynamic storage allocation.

Doug

^ permalink raw reply	[flat|nested] 62+ 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; 62+ 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] 62+ messages in thread

* Re: [TUHS] Book Recommendation
@ 2021-11-16 17:00 Douglas McIlroy
       [not found] ` <CAKH6PiXinxBQGRqoeGMcG9CwTA5BNeU-LY164f-ZLYA4obsyuA@mail.g mail.com>
                   ` (2 more replies)
  0 siblings, 3 replies; 62+ 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] 62+ messages in thread

* Re: [TUHS] Book Recommendation
  2021-11-16 14:57 Douglas McIlroy
  2021-11-16 15:22 ` Richard Salz
@ 2021-11-16 15:52 ` Ron Natalie
  2021-11-23  2:28 ` Mary Ann Horton
  2 siblings, 0 replies; 62+ messages in thread
From: Ron Natalie @ 2021-11-16 15:52 UTC (permalink / raw)
  To: Douglas McIlroy, TUHS main list

PL/I was my introduction to structured programming (though it took a 
somewhat loose approach to that).   I always
Over my early years I spent time on a couple of implementations and 
always had been amused by its somewhat COBOLish IO scheme
and spent a little time dabbling in variants such as the IBM PL/S, 
UNIVAC PLUS, and the UofM interpretted PLUM.

Then I got introduced to C and it was all downhill from there :)


------ Original Message ------
From: "Douglas McIlroy" <douglas.mcilroy@dartmouth.edu>
To: "TUHS main list" <tuhs@minnie.tuhs.org>
Sent: 11/16/2021 9:57:55 AM
Subject: Re: [TUHS] Book Recommendation

>The following remark stirred old memories. Apologies for straying off
>the path of TUHS.
>
>>  I have gotten the impression that [PL/I] was a language that was beloved by no one.
>
>As I was a designer of PL/I, an implementer of EPL (the preliminary
>PL/I compiler used to build Multics), and author of the first PL/I
>program to appear in the ACM Collected Algorithms, it's a bit hard to
>admit that PL/I was "insignificant". I'm proud, though, of having
>conceived the SIGNAL statement, which pioneered exception handling,
>and the USES and SETS attributes, which unfortunately sank into
>oblivion. I also spurred Bud Lawson to invent -> for pointer-chasing.
>The former notation C(B(A)) became A->B->C. This was PL/I's gift to C.
>
>After the ACM program I never wrote another line of PL/I.
>Gratification finally came forty years on when I met a retired
>programmer who, unaware of my PL/I connection, volunteered that she
>had loved PL/I above all other programming languages.
>
>Doug


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

* Re: [TUHS] Book Recommendation
  2021-11-16 14:57 Douglas McIlroy
@ 2021-11-16 15:22 ` Richard Salz
  2021-11-16 15:52 ` Ron Natalie
  2021-11-23  2:28 ` Mary Ann Horton
  2 siblings, 0 replies; 62+ messages in thread
From: Richard Salz @ 2021-11-16 15:22 UTC (permalink / raw)
  To: Douglas McIlroy; +Cc: TUHS main list

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

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

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

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

* Re: [TUHS] Book Recommendation
@ 2021-11-16 14:57 Douglas McIlroy
  2021-11-16 15:22 ` Richard Salz
                   ` (2 more replies)
  0 siblings, 3 replies; 62+ messages in thread
From: Douglas McIlroy @ 2021-11-16 14:57 UTC (permalink / raw)
  To: TUHS main list

The following remark stirred old memories. Apologies for straying off
the path of TUHS.

> I have gotten the impression that [PL/I] was a language that was beloved by no one.

As I was a designer of PL/I, an implementer of EPL (the preliminary
PL/I compiler used to build Multics), and author of the first PL/I
program to appear in the ACM Collected Algorithms, it's a bit hard to
admit that PL/I was "insignificant". I'm proud, though, of having
conceived the SIGNAL statement, which pioneered exception handling,
and the USES and SETS attributes, which unfortunately sank into
oblivion. I also spurred Bud Lawson to invent -> for pointer-chasing.
The former notation C(B(A)) became A->B->C. This was PL/I's gift to C.

After the ACM program I never wrote another line of PL/I.
Gratification finally came forty years on when I met a retired
programmer who, unaware of my PL/I connection, volunteered that she
had loved PL/I above all other programming languages.

Doug

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

* Re: [TUHS] Book Recommendation
  2021-11-14 19:27         ` Clem Cole
@ 2021-11-15  9:49           ` Ralph Corderoy
  0 siblings, 0 replies; 62+ messages in thread
From: Ralph Corderoy @ 2021-11-15  9:49 UTC (permalink / raw)
  To: tuhs

Hi Clem,

> > > > > > ISBN 978-0-262-54299-0
> > ...
> > > >     https://amzn.to/3qDVV8G
> > > >     ISBN-13: 978-0262542906
> > > >     ISBN-10: 0262542900
...
> > Three: the ISBN you gave doesn't match Amazon's.  :-)
> > That's how I tried finding it first and why I thought the URL might
> > be useful.
>
> That the us never from the back cover of my copy
>
> Sent from a handheld expect more typos than usual

I error-correct that to ‘That was the US number from...’.  :-)
If so, I think you've either missed a subtlety in the emails,
something's gone wrong in publishing, or you had a pre-print where they
didn't know the final number for the back cover?

Yours: 978-0-262-54299-0  Fails ISBN's check-digit
 Mine: 978-0-262-54290-6  Added dashes to match
 Diff:               ^ ^

Amazon's ‘Look Inside’ shows a paperback ISBN-13 of 9780262542906 which
matches what they put on their web page.  OpenLibrary give the same,
https://openlibrary.org/books/OL32702646M/A_New_History_of_Modern_Computing
as does the Library of Congress catalogue entry.

Anyway, it does look interesting.  I see from the index that they even
mention the Acorn Archimedes, the world's first consumer device with a
RISC chip, the Acorn RISC Machine, AKA the ARM 2.  I learnt ARM
assembler on the A310 model before switching to the R140 which shipped
with RISC iX, Acorn's Unix, and I still get asked to do the odd bit of
swtch() assembler porting on embedded ARM Cortex.

-- 
Cheers, Ralph.

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

* Re: [TUHS] Book Recommendation
  2021-11-14 18:52       ` Ralph Corderoy
@ 2021-11-14 19:27         ` Clem Cole
  2021-11-15  9:49           ` Ralph Corderoy
  0 siblings, 1 reply; 62+ messages in thread
From: Clem Cole @ 2021-11-14 19:27 UTC (permalink / raw)
  To: Ralph Corderoy; +Cc: tuhs

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

That the us never from the back cover of my copy

On Sun, Nov 14, 2021 at 1:52 PM Ralph Corderoy <ralph@inputplus.co.uk>
wrote:

> Hi Clem,
>
> > > > > ISBN 978-0-262-54299-0
> ...
> > >     https://amzn.to/3qDVV8G
> > >     ISBN-13: 978-0262542906
> > >     ISBN-10: 0262542900
> >
> > Sorry- Two typos it is “Modern Computing” in the title of the book and
> > only one r in Paul’s last name.
>
> Three: the ISBN you gave doesn't match Amazon's.  :-)
> That's how I tried finding it first and why I thought the URL might be
> useful.
>
> --
> Cheers, Ralph.
>
-- 
Sent from a handheld expect more typos than usual

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

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

* Re: [TUHS] Book Recommendation
  2021-11-14 18:44     ` Clem Cole
@ 2021-11-14 18:52       ` Ralph Corderoy
  2021-11-14 19:27         ` Clem Cole
  0 siblings, 1 reply; 62+ messages in thread
From: Ralph Corderoy @ 2021-11-14 18:52 UTC (permalink / raw)
  To: tuhs

Hi Clem,

> > > > ISBN 978-0-262-54299-0
...
> >     https://amzn.to/3qDVV8G
> >     ISBN-13: 978-0262542906
> >     ISBN-10: 0262542900
>
> Sorry- Two typos it is “Modern Computing” in the title of the book and
> only one r in Paul’s last name.

Three: the ISBN you gave doesn't match Amazon's.  :-)
That's how I tried finding it first and why I thought the URL might be
useful.

-- 
Cheers, Ralph.

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

* Re: [TUHS] Book Recommendation
  2021-11-14 16:35   ` Ralph Corderoy
  2021-11-14 18:20     ` Larry McVoy
@ 2021-11-14 18:44     ` Clem Cole
  2021-11-14 18:52       ` Ralph Corderoy
  1 sibling, 1 reply; 62+ messages in thread
From: Clem Cole @ 2021-11-14 18:44 UTC (permalink / raw)
  To: Ralph Corderoy; +Cc: tuhs

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

Sorry- Two typos it is “Modern Computing” in the title of the book and only
one r in Paul’s last name.

As I understand it, the Book should be available now.  A friend of mine
says he had downloaded the Kindle version already and as the lead HW
designer of the 360/50 his comment to me today was reading just the the
table of contents is already bringing back “some wonderful memories.”

On Sun, Nov 14, 2021 at 11:45 AM Ralph Corderoy <ralph@inputplus.co.uk>
wrote:

> Hi De,
>
> > > I wanted to pass on a recommendation of a new book from MIT Press
> > > called: “A New History of Computing” by Thomas Haigh and Paul
> > > Cerruzzi, ISBN 978-0-262-54299-0
> >
> > Any info on when it will be released?  seem to know about it yet.
>
> amazon.com, he say 2021-09-14.
>
>     https://amzn.to/3qDVV8G
>     ISBN-13: 978-0262542906
>     ISBN-10: 0262542900
>
> --
> Cheers, Ralph.
>
-- 
Sent from a handheld expect more typos than usual

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

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

* Re: [TUHS] Book Recommendation
  2021-11-14 16:35   ` Ralph Corderoy
@ 2021-11-14 18:20     ` Larry McVoy
  2021-11-14 18:44     ` Clem Cole
  1 sibling, 0 replies; 62+ messages in thread
From: Larry McVoy @ 2021-11-14 18:20 UTC (permalink / raw)
  To: Ralph Corderoy; +Cc: tuhs

On Sun, Nov 14, 2021 at 04:35:38PM +0000, Ralph Corderoy wrote:
> Hi De,
> 
> > > I wanted to pass on a recommendation of a new book from MIT Press
> > > called: ???A New History of Computing??? by Thomas Haigh and Paul
> > > Cerruzzi, ISBN 978-0-262-54299-0
> >
> > Any info on when it will be released?  seem to know about it yet.
> 
> amazon.com, he say 2021-09-14.
> 
>     https://amzn.to/3qDVV8G
>     ISBN-13: 978-0262542906
>     ISBN-10: 0262542900

Thanks for the link, ordered.  The reviews make it sound good but Clem's
advice was enough.

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

* Re: [TUHS] Book Recommendation
  2021-11-14 14:55 ` Dennis Boone
@ 2021-11-14 16:35   ` Ralph Corderoy
  2021-11-14 18:20     ` Larry McVoy
  2021-11-14 18:44     ` Clem Cole
  0 siblings, 2 replies; 62+ messages in thread
From: Ralph Corderoy @ 2021-11-14 16:35 UTC (permalink / raw)
  To: tuhs

Hi De,

> > I wanted to pass on a recommendation of a new book from MIT Press
> > called: “A New History of Computing” by Thomas Haigh and Paul
> > Cerruzzi, ISBN 978-0-262-54299-0
>
> Any info on when it will be released?  seem to know about it yet.

amazon.com, he say 2021-09-14.

    https://amzn.to/3qDVV8G
    ISBN-13: 978-0262542906
    ISBN-10: 0262542900

-- 
Cheers, Ralph.

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

* Re: [TUHS] Book Recommendation
  2021-11-14 14:37 Clem Cole
@ 2021-11-14 14:55 ` Dennis Boone
  2021-11-14 16:35   ` Ralph Corderoy
  0 siblings, 1 reply; 62+ messages in thread
From: Dennis Boone @ 2021-11-14 14:55 UTC (permalink / raw)
  To: TUHS main list

 > I wanted to pass on a recommendation of a new book from MIT Press
 > called: “A New History of Computing” by Thomas Haigh and Paul Cerruzzi,
 > ISBN 978-0-262-54299-0

Any info on when it will be released?  Even the MIT Press site doesn't
seem to know about it yet.

De

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

* [TUHS] Book Recommendation
@ 2021-11-14 14:37 Clem Cole
  2021-11-14 14:55 ` Dennis Boone
  0 siblings, 1 reply; 62+ messages in thread
From: Clem Cole @ 2021-11-14 14:37 UTC (permalink / raw)
  To: TUHS main list

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

I wanted to pass on a recommendation of a new book from MIT Press called:
“A New History of Computing” by Thomas Haigh and Paul Cerruzzi, ISBN
978-0-262-54299-0

Full disclosure, I reviewed a bit of it for them and have been eagerly
awaiting final publication.

I do expect a lot of the readers of this mailing list will enjoy it.  They
did a super job researching it and it’s very complete and of course,
interesting.  FWIW: the work of a number people that are part of this list
is nice chronicled.

Clem
-- 
Sent from a handheld expect more typos than usual

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

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

end of thread, other threads:[~2021-12-06  5:20 UTC | newest]

Thread overview: 62+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-11-16  3:16 [TUHS] Book Recommendation Douglas McIlroy
2021-11-16  4:08 ` G. Branden Robinson
2021-11-16 14:56   ` Clem Cole
2021-11-16 15:37     ` Richard Salz
2021-11-16 15:50       ` Adam Thornton
2021-11-16 16:02     ` [TUHS] BASIC, RSTS, and UNIX Ron Natalie
     [not found]       ` <CAC20D2OT6ZcFOqnNCkqDUfAKy87wYu7mp7xx0ozzAT0eN1wr8g@mail.gmail.com>
2021-11-16 16:43         ` [TUHS] Speaking of groups: JHU Ownership Ron Natalie
2021-11-16 17:02     ` [TUHS] Book Recommendation Will Senn
2021-11-16 21:38       ` John Cowan
2021-11-16 21:46         ` Will Senn
2021-11-16 18:27     ` Jon Steinhart
2021-11-16 18:44       ` Heinz Lycklama
  -- strict thread matches above, loose matches on Subject: below --
2021-12-03  2:50 Douglas McIlroy
2021-12-06  4:25 ` Adam Thornton
2021-12-06  4:42   ` Dan Halbert
2021-12-06  5:18     ` Charles H. Sauer
2021-11-24 15:50 Norman Wilson
2021-11-16 19:49 Douglas McIlroy
2021-11-16 20:02 ` Dan Cross
2021-11-16 23:16   ` Douglas McIlroy
2021-11-16 17:00 Douglas McIlroy
     [not found] ` <CAKH6PiXinxBQGRqoeGMcG9CwTA5BNeU-LY164f-ZLYA4obsyuA@mail.g mail.com>
2021-11-16 18:47   ` 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 14:57 Douglas McIlroy
2021-11-16 15:22 ` Richard Salz
2021-11-16 15:52 ` Ron Natalie
2021-11-23  2:28 ` Mary Ann Horton
2021-11-23  7:57   ` Henry Bent
2021-11-23  8:10     ` arnold
2021-11-23  8:28       ` Henry Bent
2021-11-23 17:26     ` Adam Thornton
2021-11-23 18:54       ` Ron Natalie
2021-11-23 19:04         ` Al Kossow
2021-11-23 19:39           ` Lawrence Stewart
2021-11-23 19:08       ` Ron Natalie
2021-11-23 21:54   ` Thomas Paulsen
2021-11-24 15:18     ` Richard Salz
2021-11-24 15:45       ` Larry McVoy
2021-11-24 18:34       ` Rich Morin
2021-11-24 18:40         ` Larry McVoy
2021-11-24 19:39           ` Clem Cole
2021-11-24 20:02             ` Larry McVoy
2021-11-25 10:26           ` Tom Ivar Helbekkmo via TUHS
2021-11-24 20:13       ` arnold
2021-11-24 20:18         ` Will Senn
2021-11-25  7:22         ` arnold
2021-11-24 20:15       ` Rob Pike
2021-11-24 20:21         ` joe mcguckin
2021-11-24 20:27         ` Rob Pike
2021-11-24 21:27           ` Richard Salz
2021-11-24 22:19       ` Charles Anthony
2021-11-14 14:37 Clem Cole
2021-11-14 14:55 ` Dennis Boone
2021-11-14 16:35   ` Ralph Corderoy
2021-11-14 18:20     ` Larry McVoy
2021-11-14 18:44     ` Clem Cole
2021-11-14 18:52       ` Ralph Corderoy
2021-11-14 19:27         ` Clem Cole
2021-11-15  9:49           ` Ralph Corderoy

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