The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* Re: [TUHS] ratfor vibe
@ 2022-02-01 18:19 Noel Chiappa
  2022-02-01 18:47 ` Clem Cole
  2022-02-01 21:50 ` Win Treese
  0 siblings, 2 replies; 28+ messages in thread
From: Noel Chiappa @ 2022-02-01 18:19 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: Clem Cole

    > So by the late 70s/early 80s, [except for MIT where LISP/Scheme reigned]

Not quite. The picture is complicated, because outside the EECS department,
they all did their own thing - e.g. in the mid-70's I took a programming
intro couse in the Civil Engineering department which used Fortran. But in
EECS, in the mid-70's, their intro programming course used assembler
(PDP-11), Algol, and LISP - very roughly, a third of the time in each. Later
on, I think it used CLU (hey, that was MIT-grown :-). I think Scheme was used
later. In both of these cases, I have no idea if it was _only_ CLU/Scheme, or
if they did part of it in other languages.

	Noel

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

* Re: [TUHS] ratfor vibe
  2022-02-01 18:19 [TUHS] ratfor vibe Noel Chiappa
@ 2022-02-01 18:47 ` Clem Cole
  2022-02-01 19:10   ` Dan Cross
                     ` (2 more replies)
  2022-02-01 21:50 ` Win Treese
  1 sibling, 3 replies; 28+ messages in thread
From: Clem Cole @ 2022-02-01 18:47 UTC (permalink / raw)
  To: Noel Chiappa; +Cc: tuhs

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

On Tue, Feb 1, 2022 at 1:19 PM Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote:

>     > From: Clem Cole
>
>     > So by the late 70s/early 80s, [except for MIT where LISP/Scheme
> reigned]
>
> Not quite. The picture is complicated, because outside the EECS department,
> they all did their own thing -
>
Interesting .. I trust you, but I had thought ( famously) you folks had
required a LISP and/or Scheme in the required "intro to computers" course
using the Gerald  Sussman and Hal Abelson "Structure of Computer Programs"
[Scheme IIRC] until it was finally replaced a few years ago with a
Python based one [I thought it was tjt that told me that, but I could
easily have been misled/misunderstood].

FWIW:  Through the 60s, the early and into the later 70s, CMU used to call
its 15-104 "Intro to Computer Programming" and was based on batch (card)
computing using FTN4, later WATFIV.  They used a number of books.  The book
I had was from Waterloo and other than being blue and black in color, I
remember little from it - since I already knew how and the TA let me take
'self-taught' by turning in assignments/taking the tests without going to
class.  Like Freshman Physics and Calc, all intro science and engineering
majors were required to take it however, since the engineering depts were
sure what you would see when you graduated was FTN based code [which was
probably true for the more pure Science types].   Much later (many years
after I left)  the CS Dept finally convinced Mat Sci, Chem E and Mech E to
allow the course to be taught using Pascal.  I think they use either Java
or Python now, but I haven't checked.

On the other hand, at UCB the intro course was called CS-40 "Introduction
to Computing" which was required of all Letters and Science Majors.   When
I helped to teach it in the early 80s as a grad student, we could only
handle a thousand students and turned away over another thousand [for a
required undergrad course].   We used Clancy and Cooper's "Oh Pascal" as
the text and the UCB pi interpreter on the 11/70s running a flavor of V7 /
2BSD.  Before I got there, they must have taught it on the CDC machine
using FTN, but I'm not sure.

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

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

* Re: [TUHS] ratfor vibe
  2022-02-01 18:47 ` Clem Cole
@ 2022-02-01 19:10   ` Dan Cross
  2022-02-01 19:39     ` Clem Cole
  2022-02-01 19:39   ` Richard Salz
  2022-02-01 22:30   ` Erik E. Fair
  2 siblings, 1 reply; 28+ messages in thread
From: Dan Cross @ 2022-02-01 19:10 UTC (permalink / raw)
  To: Clem Cole; +Cc: TUHS main list, Noel Chiappa

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

On Tue, Feb 1, 2022 at 1:49 PM Clem Cole <clemc@ccc.com> wrote:

> [snip]
> FWIW:  Through the 60s, the early and into the later 70s, CMU used to call
> its 15-104 "Intro to Computer Programming" and was based on batch (card)
> computing using FTN4, later WATFIV.  They used a number of books.  The book
> I had was from Waterloo and other than being blue and black in color, I
> remember little from it - since I already knew how and the TA let me take
> 'self-taught' by turning in assignments/taking the tests without going to
> class.  Like Freshman Physics and Calc, all intro science and engineering
> majors were required to take it however, since the engineering depts were
> sure what you would see when you graduated was FTN based code [which was
> probably true for the more pure Science types].   Much later (many years
> after I left)  the CS Dept finally convinced Mat Sci, Chem E and Mech E to
> allow the course to be taught using Pascal.  I think they use either Java
> or Python now, but I haven't checked.
>

There was a bit of a stir about 10 years ago when CMU switched from Java (I
think?) to Python and SML for introductory computer science education. I
remember reading a report at the time, which I _think_ is this:
http://reports-archive.adm.cs.cmu.edu/anon/2010/CMU-CS-10-140.pdf

Though perhaps not, because it _really_ bit into Java and the whole OOP
thing.

Robert Harper had a blog post that I found interesting about exposing
freshmen to functional programming:
https://existentialtype.wordpress.com/2011/03/15/teaching-fp-to-freshmen/

        - Dan C.

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

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

* Re: [TUHS] ratfor vibe
  2022-02-01 18:47 ` Clem Cole
  2022-02-01 19:10   ` Dan Cross
@ 2022-02-01 19:39   ` Richard Salz
  2022-02-01 22:30   ` Erik E. Fair
  2 siblings, 0 replies; 28+ messages in thread
From: Richard Salz @ 2022-02-01 19:39 UTC (permalink / raw)
  To: Clem Cole; +Cc: TUHS main list, Noel Chiappa

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

> Interesting .. I trust you, but I had thought ( famously) you folks had
> required a LISP and/or Scheme in the required "intro to computers" course
> using the Gerald  Sussman and Hal Abelson "Structure of Computer
> Programs" [Scheme IIRC] until it was finally replaced a few years ago
> with a Python based one [I thought it was tjt that told me that, but I
> could easily have been misled/misunderstood].
>

I think that wasn't until 1981.  I took 6.912, which was an experimental
pre-cursor to the SICP class as a sophomore.  We did LISP programming on
Multics. I might have the years off by one -- it was when "Fear of Music"
came out. :) The mainstream intro classes used Algol on a PDP-11 I think?
To emphasize Noel's point about the distributed nature, the intro to
programming class in the MechE department, 2.10, was Fortran first on punch
cards and then interactive when they got a big-ass DEC 20 running Digital
software. Amusingly MIT AI got one shortly after, and there was some
controversy about leaving TOPS-20 or converting it to ITS; ITS lost.

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

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

* Re: [TUHS] ratfor vibe
  2022-02-01 19:10   ` Dan Cross
@ 2022-02-01 19:39     ` Clem Cole
  2022-02-01 21:21       ` Dan Cross
  0 siblings, 1 reply; 28+ messages in thread
From: Clem Cole @ 2022-02-01 19:39 UTC (permalink / raw)
  To: Dan Cross; +Cc: TUHS main list, Noel Chiappa

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

Dan - thanks.
Clem

On Tue, Feb 1, 2022 at 2:10 PM Dan Cross <crossd@gmail.com> wrote:

> On Tue, Feb 1, 2022 at 1:49 PM Clem Cole <clemc@ccc.com> wrote:
>
>> [snip]
>> FWIW:  Through the 60s, the early and into the later 70s, CMU used to
>> call its 15-104 "Intro to Computer Programming" and was based on batch
>> (card) computing using FTN4, later WATFIV.  They used a number of books.
>> The book I had was from Waterloo and other than being blue and black in
>> color, I remember little from it - since I already knew how and the TA let
>> me take 'self-taught' by turning in assignments/taking the tests without
>> going to class.  Like Freshman Physics and Calc, all intro science
>> and engineering majors were required to take it however, since the
>> engineering depts were sure what you would see when you graduated was FTN
>> based code [which was probably true for the more pure Science types].
>> Much later (many years after I left)  the CS Dept finally convinced Mat
>> Sci, Chem E and Mech E to allow the course to be taught using Pascal.  I
>> think they use either Java or Python now, but I haven't checked.
>>
>
> There was a bit of a stir about 10 years ago when CMU switched from Java
> (I think?) to Python and SML for introductory computer science education. I
> remember reading a report at the time, which I _think_ is this:
> http://reports-archive.adm.cs.cmu.edu/anon/2010/CMU-CS-10-140.pdf
>
> Though perhaps not, because it _really_ bit into Java and the whole OOP
> thing.
>
> Robert Harper had a blog post that I found interesting about exposing
> freshmen to functional programming:
> https://existentialtype.wordpress.com/2011/03/15/teaching-fp-to-freshmen/
>
>         - Dan C.
>
>

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

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

* Re: [TUHS] ratfor vibe
  2022-02-01 19:39     ` Clem Cole
@ 2022-02-01 21:21       ` Dan Cross
  2022-02-01 21:33         ` Clem Cole
  0 siblings, 1 reply; 28+ messages in thread
From: Dan Cross @ 2022-02-01 21:21 UTC (permalink / raw)
  To: Clem Cole; +Cc: TUHS main list, Noel Chiappa

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

On Tue, Feb 1, 2022 at 2:40 PM Clem Cole <clemc@ccc.com> wrote:

> Dan - thanks.
>

Sure thing.

By the way: the thing I was thinking about earlier that was so biting
towards OOP was an earlier version of Harper's post, in which he writes,
"Object-oriented programming is eliminated entirely from the introductory
curriculum, because it is both anti-modular and anti-parallel by its very
nature, and hence unsuitable for a modern CS curriculum."
https://web.archive.org/web/20110321004746/https://existentialtype.wordpress.com/2011/03/15/teaching-fp-to-freshmen/
(How's _that_ for an academic glove-slap?)

It would appear that language was softened to read "unsuitable for our
purposes" sometime in 2013, and then that rather inflammatory clause was
removed entirely by early March, 2015. I had read the original and felt
some schadenfreude.

        - Dan C.

On Tue, Feb 1, 2022 at 2:10 PM Dan Cross <crossd@gmail.com> wrote:
>
>> On Tue, Feb 1, 2022 at 1:49 PM Clem Cole <clemc@ccc.com> wrote:
>>
>>> [snip]
>>> FWIW:  Through the 60s, the early and into the later 70s, CMU used to
>>> call its 15-104 "Intro to Computer Programming" and was based on batch
>>> (card) computing using FTN4, later WATFIV.  They used a number of books.
>>> The book I had was from Waterloo and other than being blue and black in
>>> color, I remember little from it - since I already knew how and the TA let
>>> me take 'self-taught' by turning in assignments/taking the tests without
>>> going to class.  Like Freshman Physics and Calc, all intro science
>>> and engineering majors were required to take it however, since the
>>> engineering depts were sure what you would see when you graduated was FTN
>>> based code [which was probably true for the more pure Science types].
>>> Much later (many years after I left)  the CS Dept finally convinced Mat
>>> Sci, Chem E and Mech E to allow the course to be taught using Pascal.  I
>>> think they use either Java or Python now, but I haven't checked.
>>>
>>
>> There was a bit of a stir about 10 years ago when CMU switched from Java
>> (I think?) to Python and SML for introductory computer science education. I
>> remember reading a report at the time, which I _think_ is this:
>> http://reports-archive.adm.cs.cmu.edu/anon/2010/CMU-CS-10-140.pdf
>>
>> Though perhaps not, because it _really_ bit into Java and the whole OOP
>> thing.
>>
>> Robert Harper had a blog post that I found interesting about exposing
>> freshmen to functional programming:
>> https://existentialtype.wordpress.com/2011/03/15/teaching-fp-to-freshmen/
>>
>>         - Dan C.
>>
>>

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

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

* Re: [TUHS] ratfor vibe
  2022-02-01 21:21       ` Dan Cross
@ 2022-02-01 21:33         ` Clem Cole
  2022-02-01 23:12           ` John Cowan
  0 siblings, 1 reply; 28+ messages in thread
From: Clem Cole @ 2022-02-01 21:33 UTC (permalink / raw)
  To: Dan Cross; +Cc: TUHS main list, Noel Chiappa

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

On Tue, Feb 1, 2022 at 4:22 PM Dan Cross <crossd@gmail.com> wrote:

> On Tue, Feb 1, 2022 at 2:40 PM Clem Cole <clemc@ccc.com> wrote:
>
>> Dan - thanks.
>>
>
> Sure thing.
>
> By the way: the thing I was thinking about earlier that was so biting
> towards OOP was an earlier version of Harper's post, in which he writes,
> "Object-oriented programming is eliminated entirely from the introductory
> curriculum, because it is both anti-modular and anti-parallel by its very
> nature, and hence unsuitable for a modern CS curriculum."
> https://web.archive.org/web/20110321004746/https://existentialtype.wordpress.com/2011/03/15/teaching-fp-to-freshmen/
> (How's _that_ for an academic glove-slap?)
>
Amen...

My disagreement with them using scripting (python) as step one is the lack
of teaching data typing early AND python's silly use space/tabs to set up
structure instead of  real {} or B/E blocks.  Automatic data conversion has
never been a good idea in my experience because like many things that
happen magically, it almost never works as I expect.

Funny we were discussing the roff family and that is why I like it over
things like Word -- way too much hidden behind the screen for my taste.
I'm a make it explicit kinda guy I guess.  I hate surprises ...

Also, it remains to be seen if teaching FP early helps - which they are
clearly making play.  Who am I to say, as one of the earliest languages I
learned APL, so FP thinking was drilled into me in my youth.

Clem

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

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

* Re: [TUHS] ratfor vibe
  2022-02-01 18:19 [TUHS] ratfor vibe Noel Chiappa
  2022-02-01 18:47 ` Clem Cole
@ 2022-02-01 21:50 ` Win Treese
  1 sibling, 0 replies; 28+ messages in thread
From: Win Treese @ 2022-02-01 21:50 UTC (permalink / raw)
  To: The Unix Heritage Society


> On Feb 1, 2022, at 1:19 PM, Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote:
> 
>> From: Clem Cole
> 
>> So by the late 70s/early 80s, [except for MIT where LISP/Scheme reigned]
> 
> Not quite. The picture is complicated, because outside the EECS department,
> they all did their own thing - e.g. in the mid-70's I took a programming
> intro couse in the Civil Engineering department which used Fortran. But in
> EECS, in the mid-70's, their intro programming course used assembler
> (PDP-11), Algol, and LISP - very roughly, a third of the time in each. Later
> on, I think it used CLU (hey, that was MIT-grown :-). I think Scheme was used
> later. In both of these cases, I have no idea if it was _only_ CLU/Scheme, or
> if they did part of it in other languages.

I took 6.001 (with Scheme) in the spring of 1983, which was using a course
handout version of what became Structure and Interpretation of Computer
Programs by Sussman and Abelson. My impression was that it had been
around for a year before that, but not much more, and it was part of
revamping the EECS core curriculum at the time.

In at least the early 80s, CLU was used in 6.170, Software Engineering
Laboratory, in which a big project was writing a compiler.

And Fortran was still being taught for the other engineering departments.
In 1982(ish), those departments had the Joint Computing Facility for a lot
of their computing, of which the star then was a new VAX 11/782.

- Win


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

* Re: [TUHS] ratfor vibe
  2022-02-01 18:47 ` Clem Cole
  2022-02-01 19:10   ` Dan Cross
  2022-02-01 19:39   ` Richard Salz
@ 2022-02-01 22:30   ` Erik E. Fair
  2022-02-02  0:54     ` Yeechang Lee
  2 siblings, 1 reply; 28+ messages in thread
From: Erik E. Fair @ 2022-02-01 22:30 UTC (permalink / raw)
  To: Unix Historical Something or other

With regard to programming languages at UCB in 1980 ...

I'd done something of a survey of colleges, and in my mind at the time, there were two approaches to a CS degree: mostly or entirely theoretical (those CS departments that had grown out of Mathematics tended to have this focus), or more practical tools/techniques/operational theory (those CS departments that had grown out of Engineering tended to be this way). UCB was definitely the latter, and that's what I wanted.

I got to UCB in fall 1980, admitted to the College of Letters & Science. At the time, there were two ways to get intro to programming:

CS1 - FORTRAN IV, taught on the CDC 6400 running CalidoSCOPE in batch mode with real punch cards, punched up on IBM 029 keypunch machines.

CS3 - Pascal, as Clem described.

CS1 was for engineers & scientists, CS3 for students who wanted to get into the CS degree program in L&S. You could take CS1 in lieu of CS3, but that was frowned upon.

Two paths to a computer science degree: A.B. CS from L&S, or B.S. EECS from the College of Engineering (which you had to be explicitly admitted to before you got there).

There was a basic difference in emphasis between L&S and Engineering for CS: L&S was "software with a smattering of hardware" (cf. CS-150, CS-152), and Engineering's EECS (B.S.) degree was the inverse: "hardware with a smattering of software."

L&S was the largest "college" at UCB: everyone got into that one "undeclared", and for your freshman & sophmore years, you studied to accumulate course credits towards declaring a major once you had "sophmore standing" (however, if you were prudent, you accumulated credits towards a "backup" major if the undergraduate degree program you wanted wouldn't/couldn't let you in). If you couldn't declare major at sophmore standing, you were bounced out of the university. Some of this setup was hangover from anti-student radical policies from the 1960s: prevent "students" from hanging around the university forever (and fomenting).

The "weeder" course for L&S CS was CS40: more Pascal than you'd ever want to code in a lifetime. L&S CS needed that filter: just before I got there, they'd let anyone into the program, but in 1980 or 1981, they limited the class size to 200 undergrads because there was too much demand from students for that degree program for the department to handle - didn't make the cut? I hope you have a backup major ...

They didn't formally teach C to undergrads until "upper division" (declared major in CS, junior or senior standing), and IIRC, there wasn't a formal course in it - you were expected to pick it up as part of the upper division course in operating systems. After all, you already know Pascal and Assembly, right?

Of course, once you had an account on one of the PDP-11/70s running Unix, C and shell programming was entirely available to you, so I went for what amounted to self-directed learning (reading manuals & books) as fast as I could.

	Erik

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

* Re: [TUHS] ratfor vibe
  2022-02-01 21:33         ` Clem Cole
@ 2022-02-01 23:12           ` John Cowan
  0 siblings, 0 replies; 28+ messages in thread
From: John Cowan @ 2022-02-01 23:12 UTC (permalink / raw)
  To: Clem Cole; +Cc: TUHS main list, Noel Chiappa

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

On Tue, Feb 1, 2022 at 4:33 PM Clem Cole <clemc@ccc.com> wrote:


> My disagreement with them using scripting (python) as step one is the lack
> of teaching data typing early
>

Teaching types is very important.  But Python is strongly typed: a string
is not a number is not a hashtable.  When it's important for performance
reasons or consistency across a large codebase, you can add static type
information to your Python code without overloading n00b brains with
mandatory type annotations.

AND python's silly use space/tabs to set up structure instead of  real {}
> or B/E blocks.
>

Nobody would accept code that was incorrectly indented (although some
languages have more than one indentation convention, like C) in an
assignment or pull request.  And when looking at correct or mostly correct
code, we look at the indentation structure, not the braces.  That being so,
having both braces and indentation is fundamentally a DRY violation.

Automatic data conversion has never been a good idea in my experience
> because like many things that happen magically, it almost never works as
> I expect.
>

I think it was a customer revolt that persuaded IBM to add "mixed-mode"
expressions like "A + I" to Fortran IV; they had been disallowed in Fortran
II.  I haven't heard anyone saying we ought to revert that change.

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

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

* Re: [TUHS] ratfor vibe
  2022-02-01 22:30   ` Erik E. Fair
@ 2022-02-02  0:54     ` Yeechang Lee
  0 siblings, 0 replies; 28+ messages in thread
From: Yeechang Lee @ 2022-02-02  0:54 UTC (permalink / raw)
  To: tuhs

Erik E. Fair says:
> With regard to programming languages at UCB in 1980 ...
>
> I'd done something of a survey of colleges, and in my mind at the
> time, there were two approaches to a CS degree: mostly or entirely
> theoretical (those CS departments that had grown out of Mathematics
> tended to have this focus), or more practical
> tools/techniques/operational theory (those CS departments that had
> grown out of Engineering tended to be this way).

Quoting my 2019 message to the cctech mailing list:

----

Adam Thornton <athornton@gmail.com> says:
> The genealogy of Computer Science departments (and their curricula)
> (at least in the US) is also weird and historically-contingent.
> Basically it seems to have been a tossup at any given school whether
> it came out of the Electr[ical|onic] Engineering department, in
> which case it was memories and logic gates and a bottom-up,
> hardware-focused curriculum, or out of the Mathematics department,
> in which case it was algorithms and complexity analysis and a
> software-focused curriculum.

Yes, I've noticed the same thing. Example: Harvard's CS department is
originally from the math side, while MIT's is from EE (thus today's
EECS).

Berkeley = EE
Brown = Math
BYU = Math
Caltech = EE
Columbia = EE
Cornell = Operations research, math
Dartmouth = Math
Illinois = Math
NYU = Both (because Polytechnic developed its own CS program long
before NYU acquired it to regain an engineering school)
Penn = EE
UCLA = OR (probably because of the RAND heritage)

Caltech until very recently did not formally offer CS degrees;
students received degrees in Engineering and Applied Science, with a
focus on CS (or aeronautics, or civil, or ME).

Illinois is an example of a track we might call "other" or even
"defense". With government funding the university built its own
computers (including ILLIAC and PLATO), and the group that did so
became the CS department, but the undergraduate CS program began
within the math department. Harvard's and Penn's programs might also
qualify.

Undergraduate CS degrees are BA (Example: Harvard), BS (Example:
Penn), or both (Example: Columbia). At Penn one must be an engineering
student to major in CS. At Columbia one can major in CS in either the
liberal arts or engineering schools, but with different
curriculums. At Yale there is one undergraduate school, within which
one can receive a BA or BS in CS, with different curriculums. Cornell,
Northwestern, and Berkeley offer CS in their separate liberal arts and
engineering schools; undergraduates receive BA or BS degrees with
identical CS curriculums, with only other requirements differing.

I've read that medical schools are good at teaching either
pharmacology (drugs), or pathology (diseases); perhaps this is also
because of the expertise/specialty of their early faculty members.

----

> Two paths to a computer science degree: A.B. CS from L&S, or
> B.S. EECS from the College of Engineering (which you had to be
> explicitly admitted to before you got there).

Still true today. As I mention above, Berkeley's CS curriculum is identical regardless of the degree (or was the last time I checked), something not always true at other universities that offer multiple CS undergraduate degree options.

-- 
geo:37.783333,-122.416667

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

* Re: [TUHS] ratfor vibe
  2022-02-02  7:47     ` arnold
  2022-02-03 18:57       ` silas poulson
@ 2022-02-10 15:18       ` Ralph Corderoy
  1 sibling, 0 replies; 28+ messages in thread
From: Ralph Corderoy @ 2022-02-10 15:18 UTC (permalink / raw)
  To: tuhs

Hi Arnold,

> > I agree the original Software Tools is a must read, but having done
> > so, why would I suffer working through the hurdles put in place by
> > Pascal compared to Ratfor?  I never bothered so your recommendation
> > makes me wonder what I missed.  I did read Kernighan's ‘not my
> > favourite’ and took from that I wouldn't enjoy the Pascal book given
> > I'd read the original.
>
> As others mentioned, recursion and real data structures make code
> easier to read. They also refined the text some.
>
> But in general, I think the principle of "ANYTHING written by Brian
> Kernighan is worth reading, at least once" applies, even in this case.

Well, that's true.  I've read every other technical book of his apart
from the ‘AMPL: A Modeling Language for Mathematical Programming’.
https://amzn.to/3BdQ0dV

It was the quality of his writing which meant I could learn C and Unix
at home well enough to get a C programming job on Sun OS on leaving
school, which is sixteen over here.  Within a year or so, work sent me
to Sydney as part of shipping the flight simulator to Qantas.  Good
books have immeasurable worth across all their readers.

Thanks, it's ordered, arriving Valentine's Day, which will impress
SWMBO.  :-)

-- 
Cheers, Ralph.

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

* Re: [TUHS] ratfor vibe
  2022-02-04  8:26         ` arnold
@ 2022-02-04 19:41           ` John Cowan
  0 siblings, 0 replies; 28+ messages in thread
From: John Cowan @ 2022-02-04 19:41 UTC (permalink / raw)
  To: Aharon Robbins; +Cc: TUHS main list

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

On Fri, Feb 4, 2022 at 3:26 AM <arnold@skeeve.com> wrote:

No, he has not. I suspect it would have looked like the ratfor code
> but with real data structures and recursion, and without the need to
> build the standard I/O library (getc, putc, etc.).
>

See Jez Higgins's STinC++ (Software Tools in C++) project at <
https://www.jezuk.co.uk/tags/software-tools-in-c++.html>.  He's working
from ST in Pascal, but this is a rewrite from scratch, not a translation.
So far he's done Chapters 1, 2, and 5, implementing each tool as he goes.

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

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

* Re: [TUHS] ratfor vibe
  2022-02-04 17:35       ` Adam Thornton
@ 2022-02-04 17:44         ` Will Senn
  0 siblings, 0 replies; 28+ messages in thread
From: Will Senn @ 2022-02-04 17:44 UTC (permalink / raw)
  To: Adam Thornton, Ori Idan, The Eunuchs Hysterical Society

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

On 2/4/22 11:35 AM, Adam Thornton wrote:
>
>
> On Thu, Feb 3, 2022 at 11:07 PM Ori Idan <ori@heliconbooks.com> wrote:
>
>     As for EOF it is 0xFF which is not always -1, depending if your
>     char is signed or unsigned.
>
>
> Ha!  You fell into my trap!  getc() returns an int!  (I don't know if 
> EOF is _always_ "all bits set", and even if it is, that's only -1 on a 
> twos-complement machine, if we want to head off into some real 
> pedantry...)
>
> The need to use feof() and ferror() at least appear in the BUGS 
> section on my Mac.  Linux is not so gracious.  The real bug, if you 
> ask me, which no one did, is that getc() and pals return an int rather 
> than a char, which is surprising and certainly has tripped me up 
> several times across the decades (and yes, I understand that since any 
> character value is a legal character to have gotten, you need some 
> other way of signalling an error).
This is prolly why the authors steadfastly refused to commit to a 
particular value for EOF. Instead, they said in essence, that it was a 
matter of agreement, convention, if you will, and that whatever value 
was chosen, it should NEVER be a legal character. I made it -1, for v7, 
cuz it worked... and I wanted so badly to get a working ratfor program 
that I sacrificed any semblance of technical rigor to make it copy a 
character, onscreen, in real time, live. Heck, and it only took me a 
couple of days to figure out all how to get it working, EOF was easy, 
STDIN and STDOUT, not so much.


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

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

* Re: [TUHS] ratfor vibe
  2022-02-04  6:06     ` Ori Idan
@ 2022-02-04 17:35       ` Adam Thornton
  2022-02-04 17:44         ` Will Senn
  0 siblings, 1 reply; 28+ messages in thread
From: Adam Thornton @ 2022-02-04 17:35 UTC (permalink / raw)
  To: Ori Idan, The Eunuchs Hysterical Society

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

On Thu, Feb 3, 2022 at 11:07 PM Ori Idan <ori@heliconbooks.com> wrote:

> As for EOF it is 0xFF which is not always -1, depending if your char is
> signed or unsigned.
>
>
Ha!  You fell into my trap!  getc() returns an int!  (I don't know if EOF
is _always_ "all bits set", and even if it is, that's only -1 on a
twos-complement machine, if we want to head off into some real pedantry...)

The need to use feof() and ferror() at least appear in the BUGS section on
my Mac.  Linux is not so gracious.  The real bug, if you ask me, which no
one did, is that getc() and pals return an int rather than a char, which is
surprising and certainly has tripped me up several times across the decades
(and yes, I understand that since any character value is a legal character
to have gotten, you need some other way of signalling an error).

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

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

* Re: [TUHS] ratfor vibe
  2022-02-03 18:57       ` silas poulson
@ 2022-02-04  8:26         ` arnold
  2022-02-04 19:41           ` John Cowan
  0 siblings, 1 reply; 28+ messages in thread
From: arnold @ 2022-02-04  8:26 UTC (permalink / raw)
  To: silas8642, arnold; +Cc: tuhs

silas poulson <silas8642@hotmail.co.uk> wrote:

> > FWIW, Brian has told me more than once that he wishes they'd done
> > “Software Tools In C" instead of in Pascal, and that the Pascal book
> > was a failure to read the market correctly.
>
> Ah, but then we wouldn’t have had his wonderful *Why Pascal* paper!
>
> Has Brian ever said what would’ve been different if a C version had
> been written?

No, he has not. I suspect it would have looked like the ratfor code
but with real data structures and recursion, and without the need to
build the standard I/O library (getc, putc, etc.).

Arnold

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

* Re: [TUHS] ratfor vibe
  2022-02-03 20:00   ` Adam Thornton
@ 2022-02-04  6:06     ` Ori Idan
  2022-02-04 17:35       ` Adam Thornton
  0 siblings, 1 reply; 28+ messages in thread
From: Ori Idan @ 2022-02-04  6:06 UTC (permalink / raw)
  To: Adam Thornton; +Cc: The Eunuchs Hysterical Society

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

SPACE is 32 and NEWLINE is 10 is that the reason that space in ASCII is 32
As for EOF it is 0xFF which is not always -1, depending if your char is
signed or unsigned.

-- 
Ori Idan CEO Helicon Books
http://www.heliconbooks.com





On Thu, Feb 3, 2022 at 10:01 PM Adam Thornton <athornton@gmail.com> wrote:

>
>
> On Wed, Feb 2, 2022 at 9:01 PM Will Senn <will.senn@gmail.com> wrote:
>
>>
>> For example, even in the tiny copy program example, from the introductory
>> chapter, once you include the primitive getc and putc subroutines, there
>> are 7 symbolic constants: MAXLINE, MAXCARD, NEWLINE, STDIN, STDOUT, EOF,
>> SPACE and character, which is really an integer and gets replaced with
>> integer by some mythical preprocessor (chapter 8). Anyhow, in the modern
>> world, MAXLINE and MAXCARD don't really have meaning, but they can
>> magically be treated as lines of a file, the rest do have meaning, but they
>> don't evaluate to the same things in Fortran-land as in modern-land. STDIN
>> is 5 and STDOUT is 6 (card reader and punch LUNs, again some magic that
>> lets them be treated as terminal input and output),  EOF is -1, SPACE is
>> 32, NEWLINE is 10.
>>
>> Pretty sure that EOF is _still_ -1.  SPACE and NEWLINE also look pretty
>> familiar and their values haven't changed, although we might spell them a
>> little differently these days.
>>
>

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

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

* Re: [TUHS] ratfor vibe
  2022-02-03  4:00 ` Will Senn
  2022-02-03  4:31   ` Al Kossow
@ 2022-02-03 20:00   ` Adam Thornton
  2022-02-04  6:06     ` Ori Idan
  1 sibling, 1 reply; 28+ messages in thread
From: Adam Thornton @ 2022-02-03 20:00 UTC (permalink / raw)
  To: Will Senn, The Eunuchs Hysterical Society

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

On Wed, Feb 2, 2022 at 9:01 PM Will Senn <will.senn@gmail.com> wrote:

>
> For example, even in the tiny copy program example, from the introductory
> chapter, once you include the primitive getc and putc subroutines, there
> are 7 symbolic constants: MAXLINE, MAXCARD, NEWLINE, STDIN, STDOUT, EOF,
> SPACE and character, which is really an integer and gets replaced with
> integer by some mythical preprocessor (chapter 8). Anyhow, in the modern
> world, MAXLINE and MAXCARD don't really have meaning, but they can
> magically be treated as lines of a file, the rest do have meaning, but they
> don't evaluate to the same things in Fortran-land as in modern-land. STDIN
> is 5 and STDOUT is 6 (card reader and punch LUNs, again some magic that
> lets them be treated as terminal input and output),  EOF is -1, SPACE is
> 32, NEWLINE is 10.
>
> Pretty sure that EOF is _still_ -1.  SPACE and NEWLINE also look pretty
> familiar and their values haven't changed, although we might spell them a
> little differently these days.
>

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

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

* Re: [TUHS] ratfor vibe
  2022-02-02  7:47     ` arnold
@ 2022-02-03 18:57       ` silas poulson
  2022-02-04  8:26         ` arnold
  2022-02-10 15:18       ` Ralph Corderoy
  1 sibling, 1 reply; 28+ messages in thread
From: silas poulson @ 2022-02-03 18:57 UTC (permalink / raw)
  To: arnold; +Cc: Paul Ruizendaal via TUHS

> FWIW, Brian has told me more than once that he wishes they'd done
> “Software Tools In C" instead of in Pascal, and that the Pascal book
> was a failure to read the market correctly.

Ah, but then we wouldn’t have had his wonderful *Why Pascal* paper!

Has Brian ever said what would’ve been different if a C version had
been written?

Silas


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

* Re: [TUHS] ratfor vibe
  2022-02-03  4:31   ` Al Kossow
@ 2022-02-03  5:16     ` Warner Losh
  0 siblings, 0 replies; 28+ messages in thread
From: Warner Losh @ 2022-02-03  5:16 UTC (permalink / raw)
  To: Al Kossow; +Cc: TUHS main list

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

On Wed, Feb 2, 2022, 9:37 PM Al Kossow <aek@bitsavers.org> wrote:

> On 2/2/22 8:00 PM, Will Senn wrote:
>
> > Of course, it's criminal to have all those hardcoded magic numbers
>
> Graybeards chucking at the follies of youth.
>

Yea, this code is quite well written relative to most of the code of that
era...

Warner

>

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

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

* Re: [TUHS] ratfor vibe
  2022-02-03  4:00 ` Will Senn
@ 2022-02-03  4:31   ` Al Kossow
  2022-02-03  5:16     ` Warner Losh
  2022-02-03 20:00   ` Adam Thornton
  1 sibling, 1 reply; 28+ messages in thread
From: Al Kossow @ 2022-02-03  4:31 UTC (permalink / raw)
  To: tuhs

On 2/2/22 8:00 PM, Will Senn wrote:

> Of course, it's criminal to have all those hardcoded magic numbers

Graybeards chucking at the follies of youth.



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

* Re: [TUHS] ratfor vibe
  2022-01-31 20:46 Will Senn
  2022-02-01 15:37 ` arnold
@ 2022-02-03  4:00 ` Will Senn
  2022-02-03  4:31   ` Al Kossow
  2022-02-03 20:00   ` Adam Thornton
  1 sibling, 2 replies; 28+ messages in thread
From: Will Senn @ 2022-02-03  4:00 UTC (permalink / raw)
  To: TUHS main list

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

On 1/31/22 2:46 PM, Will Senn wrote:
> All,
>
> I have been doing some language exploration in v7/4.3bsd and came 
> across Software Tools (not the pascal version). It's written using 
> ratfor, which I had seen in the v7 UPM. I fired up v7 and tried my 
> hand at the first example:

I thought I'd close the loop on the language side of this thread. I am 
happy to report that ratfor (and fortran) is alive and well. It works on 
my mac! The Software Tools book is awesome, if challenging. The first 
chapter is particularly challenging as it takes a bit to figure out 
where the authors are coming from and what they include, exclude, and 
highlight... and why. The key to understanding the book, as a modern 
reader, is to understand that the authors assume their readers are 
fortran (or PL/I) programmers.  Because of this, they don't explain 
anything that would be obvious to said programmers (read, write, LUNs, 
Hollerith cards, format, etc). In addition, they will push down details 
of implementation until they practically disappear (think singularity... 
annoyingly consistent in this regard). When they say something like "EOF 
is a symbolic constant... We won't tell you what its value is, since the 
particular value doesn't matter", they really mean it. Unfortunately, in 
order to actually implement stuff, you gotta know what every symbolic 
constant and macro replacement is :).

For example, even in the tiny copy program example, from the 
introductory chapter, once you include the primitive getc and putc 
subroutines, there are 7 symbolic constants: MAXLINE, MAXCARD, NEWLINE, 
STDIN, STDOUT, EOF, SPACE and character, which is really an integer and 
gets replaced with integer by some mythical preprocessor (chapter 8). 
Anyhow, in the modern world, MAXLINE and MAXCARD don't really have 
meaning, but they can magically be treated as lines of a file, the rest 
do have meaning, but they don't evaluate to the same things in 
Fortran-land as in modern-land. STDIN is 5 and STDOUT is 6 (card reader 
and punch LUNs, again some magic that lets them be treated as terminal 
input and output),  EOF is -1, SPACE is 32, NEWLINE is 10. Anyhow, long 
story just a bit shorter, replace those constants, swap character for 
integer, and combine getc, putc, and copy and yahoo, a working copy 
program that works in v7, 4.xBSD, and Mac OS X Mojave (and BSD, etc), 
without any further modifications... at all.

Included for the curioius (copynew.r):

    # on v7
    # $ ratfor -C copynew.r > copynew.f
    # $ f77 -o copynew copynew.f
    # on mac
    # $ ratfor77 -C copynew.r > copynew.f
    # $ gfortran -o copynew copynew.f
    # $ ./copynew
    # This is a test.
    # This is a test.
    # CTRL-d
    # $

    # getc (simple version) - get characters from standard input
             integer function getc(c)
             integer buf(81), c
             integer i, lastc
             data lastc /81/,buf(81) /10/

             lastc = lastc + 1
             if(lastc > 81) {
                     read(5, 100, end=10) (buf(i), i = 1, 80)
                             100 format(80 a 1)
                     lastc = 1
                     }
             c = buf(lastc)
             getc = c
             return

    10      c = -1
             getc = -1
             return
             end

    # putc (simple version) - put characters on the standard output
             subroutine putc(c)
             integer buf(80), c
             integer i, lastc
             data lastc /0/

             if (lastc > 80 | c == 10) {
                     for (i = lastc + 1; i <= 80; i = i + 1)
                             buf(i) = 32
                     write(6, 100) (buf(i), i = 1, 80)
                             100 format(80 a 1)
                     lastc = 0
                     }
             if (c != 10) {
                     lastc = lastc + 1
                     buf(lastc) = c
                     }
             return
             end

    # copy - copy input characters to output
             integer getc
             integer c

             while(getc(c) != -1)
                     call putc(c)
             stop
             end

Of course, it's criminal to have all those hardcoded magic numbers, 
wouldn't it be swell if there were some sort of macro facility?... oh, 
wait, that's what Chapter 8's all about... I can't wait.

Will

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

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

* Re: [TUHS] ratfor vibe
  2022-02-01 15:52   ` Ralph Corderoy
  2022-02-01 16:58     ` Clem Cole
  2022-02-01 17:02     ` silas poulson
@ 2022-02-02  7:47     ` arnold
  2022-02-03 18:57       ` silas poulson
  2022-02-10 15:18       ` Ralph Corderoy
  2 siblings, 2 replies; 28+ messages in thread
From: arnold @ 2022-02-02  7:47 UTC (permalink / raw)
  To: tuhs, ralph

Ralph Corderoy <ralph@inputplus.co.uk> wrote:

> Hi Arnold,
>
> > In ~ 1981, Kernighan and Plauger rewrote the tools in Pascal and redid
> > the book to go with it. This is
> > https://www.amazon.com/Software-Tools-Pascal-Brian-Kernighan/dp/0201103427/
> > which I also recommend getting a copy of.
>
> I agree the original Software Tools is a must read, but having done so,
> why would I suffer working through the hurdles put in place by Pascal
> compared to Ratfor?  I never bothered so your recommendation makes me
> wonder what I missed.  I did read Kernighan's ‘not my favourite’
> and took from that I wouldn't enjoy the Pascal book given I'd read
> the original.
>
> -- 
> Cheers, Ralph.

As others mentioned, recursion and real data structures make code
easier to read. They also refined the text some.

But in general, I think the principle of "ANYTHING written by Brian
Kernighan is worth reading, at least once" applies, even in this case.

FWIW, Brian has told me more than once that he wishes they'd done "Software
Tools In C" instead of in Pascal, and that the Pascal book was a failure
to read the market correctly.

Long ago, I once dreamed that I found "Software Tools In C" in a bookstore;
the cover had green lettering instead of the red and blue used in the
real books. I was sorta disappointed when I woke up... :-)

HTH,

Arnold

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

* Re: [TUHS] ratfor vibe
  2022-02-01 15:52   ` Ralph Corderoy
  2022-02-01 16:58     ` Clem Cole
@ 2022-02-01 17:02     ` silas poulson
  2022-02-02  7:47     ` arnold
  2 siblings, 0 replies; 28+ messages in thread
From: silas poulson @ 2022-02-01 17:02 UTC (permalink / raw)
  To: Ralph Corderoy; +Cc: Paul Ruizendaal via TUHS

> On 1 Feb 2022, at 15:52, Ralph Corderoy <ralph@inputplus.co.uk> wrote:
> I never bothered so your recommendation makes me wonder what I missed.

Whilst I haven’t read the original, believe Kernighan and Plauger
state in preface that Pascal enabled recursive algorithms to be
written in their natural manner.

Don’t believe Fortran has record or set datatypes and imagine those
enabled code improvements between the Ratfor and the Pascal

> I did read Kernighan's ‘not my favourite’ and took from that I
> wouldn't enjoy the Pascal book given I'd read the original.

Not quite sure reading both editions of the book but would definitely
recommend examining the code which Arnold states is available on the
TUHS archive.

Silas


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

* Re: [TUHS] ratfor vibe
  2022-02-01 15:52   ` Ralph Corderoy
@ 2022-02-01 16:58     ` Clem Cole
  2022-02-01 17:02     ` silas poulson
  2022-02-02  7:47     ` arnold
  2 siblings, 0 replies; 28+ messages in thread
From: Clem Cole @ 2022-02-01 16:58 UTC (permalink / raw)
  To: Ralph Corderoy; +Cc: tuhs

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

On Tue, Feb 1, 2022 at 10:53 AM Ralph Corderoy <ralph@inputplus.co.uk>
wrote:

> I agree the original Software Tools is a must read, but having done so,
> why would I suffer working through the hurdles put in place by Pascal
> compared to Ratfor?

I'll take a stab.  Again set Arnold's  Way-Back machine to the late '60 and
through the mid 1970s.  The Algol vs. FTN war was raging.   FTN had 'won'
the Science and Engineering communities and Algol was the Math/CS types
[I'm over simplifying].   In fact, when I was at CMU in the mid-70s; my
professors all said *FTN was dead*  ( mind you production quality FTN code
has paid my salary in the HPC world my entire career ).  At CMU, the
compromise is all engineers were required to take an intro to computing
using in FTN/WATFIV course and then all other 200 level or greater CS
course after that were usualy based using an Algol/ or later Pascal.

The point being any reasonable computer system being brought to market
by a *credible
systems vendor* had at least an implementation of FTN4 that could pass the
ANSI test suite and many started to have one that support F77 [although
thank you DEC VMS FTN != F77].   But ... because of the push from the
teaching/CS side in most places, Pascal started to show up as a standard
offering [C did not - yet - have that backing].   I suspect if you check my
generation and for the next 10-20 years after, you will see Pascal was the
first language you saw in college.

So by the late 70s/early 80s, [except for MIT where LISP/Scheme reigned]
Pascal had become the primary teaching language for the CS communities at
most schools.   C was considered a tad 'dirty' [not as bad as assembler --
but close].  It might have been used in an OS or Compiler course.  In fact
in the grad Graphics course I took, which was taught by Xerox folks, I had
to get a special exception to use C.

But the fact is, at that time, if you read the literature, you would
believe that Pascal was going to be the future. Hence the concept of doing
the SWT in Pascal made sense >>in theory<<. Another important fact was that
while the P4 system made moving Pascal easier than many other languages, as
Rob pointed out, the Pascal I/O was so screwy and frankly not well bound to
the host OS, that every new implementation messed with it in some manner
[see Brian's wonderful tome for more details].   Similarly, the lack of
standardized way to do separate compilation for support libs (which had
been a prime idea in FTN and allowed a rich market for libraries), really
had a huge effect.  Again it was solved many times with each compiler
implementation, but each scheme tended to be a little different.

Fortran, of course, had been around long enough and had an ANSI standard
(and a test suite for it) at least made portable FTN possible.

So the theory was good -- Pascal was a 'better' language in theory and
everyone was coming out of school knowing it.

Again, reality ...  since UNIX came with C and was 'open source' in the
sense that everyone that had it, had the AT&T source code.  One of the
first things that happened was C was retargeted to a number of processors
-- often not by either the manufacturer or by the system vendor.
Interestingly, this was about 50/50 between Academics/Research and
Industry.   So while all the world's ISA were not a PDP-11, the fun part is
the code *could be made reasonably* portable - in fact *in practice*
[partly because C had a pre-processor which Pascal did not and of course is
what ratfor is] have one source base that could compile for different
targets.

The problem (as you note) these issues are >>obvious<< in hindsight, but
during that time -- it was not.  It certainly seems like Pascal had a lot
of momentum. They were a lot compilers for a lot of systems.   Look, it was
the language Apple used for the Lisa and Mac.  Things like UCSD Pascal was
being made by the press as 'the answer for 8 bit processors' [note MSFT had
a FTN for the 8080 on CPM in those days].   Turbo Pascal was, in fact,
an excellent compiler.  But C was starting to come on strong.

FWIW:  In the end, I personally believe that C 'won' because the practical
side made it cheaper to use (economics always beat architecture).  The
cynical part of me thinks that a big reason why C++ caught on is because a
lot of the pro-Pascal community got to sing the praises of OOP with C++ and
they could change sides without claiming C beat Pascal.  Hey, Microsoft
made a pretty good C for DOS and finally going C++ probably helped.  It
sold more than the FORTRAN and my guess is that people using FORTRAN at
that point were scientists and needed the address space that 8086 did not
have. The 386 with a linear address for using things like the PharLap tools
made it possible and frankly the Intel 8087 started to make that processor
a better target for science.

In the end, Pascal never had a code base like the FTN Scientific code base
or todays C and C++ code base.   FWIW: I can think of few production Pascal
codes from those days that are still being used [other than the Front-End
of the DEC/Intel FORTRAN compiler - which was moved from BLISS to Pascal
for all the same 'C is dirty' issues BTW].

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

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

* Re: [TUHS] ratfor vibe
  2022-02-01 15:37 ` arnold
@ 2022-02-01 15:52   ` Ralph Corderoy
  2022-02-01 16:58     ` Clem Cole
                       ` (2 more replies)
  0 siblings, 3 replies; 28+ messages in thread
From: Ralph Corderoy @ 2022-02-01 15:52 UTC (permalink / raw)
  To: tuhs

Hi Arnold,

> In ~ 1981, Kernighan and Plauger rewrote the tools in Pascal and redid
> the book to go with it. This is
> https://www.amazon.com/Software-Tools-Pascal-Brian-Kernighan/dp/0201103427/
> which I also recommend getting a copy of.

I agree the original Software Tools is a must read, but having done so,
why would I suffer working through the hurdles put in place by Pascal
compared to Ratfor?  I never bothered so your recommendation makes me
wonder what I missed.  I did read Kernighan's ‘not my favourite’
and took from that I wouldn't enjoy the Pascal book given I'd read
the original.

-- 
Cheers, Ralph.

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

* Re: [TUHS] ratfor vibe
  2022-01-31 20:46 Will Senn
@ 2022-02-01 15:37 ` arnold
  2022-02-01 15:52   ` Ralph Corderoy
  2022-02-03  4:00 ` Will Senn
  1 sibling, 1 reply; 28+ messages in thread
From: arnold @ 2022-02-01 15:37 UTC (permalink / raw)
  To: will.senn, tuhs

Will,

This will be a high level reply. I undoubtedly have some details wrong, as
I wasn't inside Bell Labs.

	Sherman, set the wayback machine for 1974.
		-- Mr. Peabody

In 1974, Unix was still young, and while C existed, it was not widespread.
The predominant programmng language in use at the time in Bell Labs
and in many, many other places, was Fortran.  For our purposes, Fortran IV
and Fortran 66 are the same thing: the only control flow constructs the
language had was 'if', 'goto' and a 'do' loop that could only count up.
The only data structure was the array.

Structured Programming had started to take hold in the Computer Science
community, with lots of discussion and papers about what the best control
flow structures were, and so on.

At the time there were preprocessors for Fortran that made it easier to
program in.  I don't know what got him started, by Brian Kernighan decided
to write one that would give Fortran control flow constructs similar or
identical to those of C.  This was ratfor, for RATional FORtran. He used
C and Yacc (which was also fairly young) to do this.

Recognizing that the Unix environment was very pleasant, but that the
wide world wouldn't drop everything they had to move to it, he and
P.J. (Bill) Plauger used ratfor to create a bunch of tools that provided
functionality similar or identical to many of the Unix utilities,
and wrote a book on the tools, using it as a platform to at the
same time teach good programming practices.  This is

https://www.amazon.com/Software-Tools-Brian-W-Kernighan/dp/020103669X/ref=sr_1_5?crid=LXBHQKV9D0QP&keywords=software+tools&qid=1643720166&s=books&sprefix=software+tools%2Cstripbooks%2C220&sr=1-5

which I STRONGLY recommend getting and reading, even almost 50 years
after it was published (1975 or 1976).

This book changed my life. Literally.

The original tools are in the TUHS archives. (If anyone has not synched
their copy, please do so, there were some errors in the files that I
have recently fixed and which Warren has put in place.)

(A modernized version of UNIX ratfor is at
https://github.com/arnoldrobbins/ratfor, so you don't have to use V7 to
get it. The doc is included and it's easy to make PDF of it.)

The book and tools were extremely popular into the early 80s, until Unix
itself started to spread.  Debbie Scherer can give the history of her
group, which took the tools and made them portable to all kinds of
computing environments. At Georgia Tech, 3 students took the tools and
adapted them into a lovely environment for use on Pr1me systems, which
were otherwise rather less user-friendly.

At Bell Labs, Brenda Baker wrote 'struct' which read Fortran and turned
it into ratfor; see the recent list archives for more on my efforts to bring
that program into the 21st century. (Apologies for the self plugs. :-)

In ~ 1981, Kernighan and Plauger rewrote the tools in Pascal and redid
the book to go with it. This is

https://www.amazon.com/Software-Tools-Pascal-Brian-Kernighan/dp/0201103427/ref=sr_1_3?keywords=software+tools+in+pascal&link_code=qs&qid=1643727958&sourceid=Mozilla-search&sr=8-3

which I also recommend getting a copy of. This in turn led to Kernighan's
famous "Pascal is not my favorite programming language" memo (which is also
in my github :-).

The Pascal tools are also in the TUHS archive.

I hope this helps.

Arnold


Will Senn <will.senn@gmail.com> wrote:

> All,
>
> I have been doing some language exploration in v7/4.3bsd and came across 
> Software Tools (not the pascal version). It's written using ratfor, 
> which I had seen in the v7 UPM. I fired up v7 and tried my hand at the 
> first example:
>
>     # copy - copy input characters to output
>              integer getc
>              integer c
>
>              while(getc(c) != EOF)
>                      call putc(c)
>              stop
>              end
>
> The first thing I noticed was that it read more like C than Fortran (I 
> know C quite well, Fortran just a smidge)... awesome, right? So I ran 
> the preprocessor on it and got the following f77 code:
>
>     c copy - copy input characters to output
>            integer getc
>            integer c
>     c     while
>     23000 if(.not.(getc(c) .ne. eof))goto 23001
>               call putc(c)
>               goto 23000
>     c     endwhile
>     23001 continue
>            stop
>            end
>
> Cool. The way it translated the EOF test is weird, but ok. Trying to 
> compile it results in complaints about missing getc and putc:
>
>     $ f77 copy.f
>     copy.f:
>         MAIN:
>     Undefined:
>     _getc_
>     _putc_
>     _end
>
> Ah well, no worries. I know that they're in the c lib, but don't about 
> fortran libs... Meanwhile, over on 4.3BSD, it compiles without issue. 
> But running it is no joy:
>
>     $ ./a.out
>     This is a test
>     $
>
> I remembered that the authors mentioned something about EOF, so I 
> tweaked the code (changed EOF to -1) and rebuilt/reran:
>
>     $ ./a.out
>     This is a test
>     This is a test
>     $
>
> Fascinating. Dunno why no complaints from F77 about the undefined EOF 
> (or maybe mis-defined), but hey, it works and it's fun.
>
> I'm curious how much ratfor was used in bell labs and other locations 
> running v6, v7, and the BSD's. When I first came across it, I was under 
> the impression that it was a wrapper to make f66 bearable, but the 
> manpage says it's best used with f77, so that's not quite right. As 
> someone coming from c, I totally appreciate what it does to make the 
> control structures I know and love available, but that wasn't the case 
> back then, was it? C was pretty new... Was it just a temporary fix to a 
> problem that just went away, or is there tons of ratfor out there in the 
> wild that I just haven't seen? I found ratfor77 and it runs just fine on 
> my mac with a few tweaks, so it's not dead:
>
>     ratfor77 -C copy.r | tee copy.f
>     C Output from Public domain Ratfor, version 1.0
>     C copy - copy input characters to output
>            integer getc
>            integer c
>     23000 if(getc(c) .ne. eof)then
>            call putc(c)
>            goto 23000
>            endif
>     23001 continue
>            stop
>            end
>
> What's the story? Oh, and in v6 it looks like it was rc - ratfor 
> compiler, which is not present in v7 or 4.3BSD - is there a backstory 
> there, too?
>
> Will
>
>
>

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

* [TUHS] ratfor vibe
@ 2022-01-31 20:46 Will Senn
  2022-02-01 15:37 ` arnold
  2022-02-03  4:00 ` Will Senn
  0 siblings, 2 replies; 28+ messages in thread
From: Will Senn @ 2022-01-31 20:46 UTC (permalink / raw)
  To: TUHS main list

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

All,

I have been doing some language exploration in v7/4.3bsd and came across 
Software Tools (not the pascal version). It's written using ratfor, 
which I had seen in the v7 UPM. I fired up v7 and tried my hand at the 
first example:

    # copy - copy input characters to output
             integer getc
             integer c

             while(getc(c) != EOF)
                     call putc(c)
             stop
             end

The first thing I noticed was that it read more like C than Fortran (I 
know C quite well, Fortran just a smidge)... awesome, right? So I ran 
the preprocessor on it and got the following f77 code:

    c copy - copy input characters to output
           integer getc
           integer c
    c     while
    23000 if(.not.(getc(c) .ne. eof))goto 23001
              call putc(c)
              goto 23000
    c     endwhile
    23001 continue
           stop
           end

Cool. The way it translated the EOF test is weird, but ok. Trying to 
compile it results in complaints about missing getc and putc:

    $ f77 copy.f
    copy.f:
        MAIN:
    Undefined:
    _getc_
    _putc_
    _end

Ah well, no worries. I know that they're in the c lib, but don't about 
fortran libs... Meanwhile, over on 4.3BSD, it compiles without issue. 
But running it is no joy:

    $ ./a.out
    This is a test
    $

I remembered that the authors mentioned something about EOF, so I 
tweaked the code (changed EOF to -1) and rebuilt/reran:

    $ ./a.out
    This is a test
    This is a test
    $

Fascinating. Dunno why no complaints from F77 about the undefined EOF 
(or maybe mis-defined), but hey, it works and it's fun.

I'm curious how much ratfor was used in bell labs and other locations 
running v6, v7, and the BSD's. When I first came across it, I was under 
the impression that it was a wrapper to make f66 bearable, but the 
manpage says it's best used with f77, so that's not quite right. As 
someone coming from c, I totally appreciate what it does to make the 
control structures I know and love available, but that wasn't the case 
back then, was it? C was pretty new... Was it just a temporary fix to a 
problem that just went away, or is there tons of ratfor out there in the 
wild that I just haven't seen? I found ratfor77 and it runs just fine on 
my mac with a few tweaks, so it's not dead:

    ratfor77 -C copy.r | tee copy.f
    C Output from Public domain Ratfor, version 1.0
    C copy - copy input characters to output
           integer getc
           integer c
    23000 if(getc(c) .ne. eof)then
           call putc(c)
           goto 23000
           endif
    23001 continue
           stop
           end

What's the story? Oh, and in v6 it looks like it was rc - ratfor 
compiler, which is not present in v7 or 4.3BSD - is there a backstory 
there, too?

Will




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

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

end of thread, other threads:[~2022-02-10 15:21 UTC | newest]

Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-02-01 18:19 [TUHS] ratfor vibe Noel Chiappa
2022-02-01 18:47 ` Clem Cole
2022-02-01 19:10   ` Dan Cross
2022-02-01 19:39     ` Clem Cole
2022-02-01 21:21       ` Dan Cross
2022-02-01 21:33         ` Clem Cole
2022-02-01 23:12           ` John Cowan
2022-02-01 19:39   ` Richard Salz
2022-02-01 22:30   ` Erik E. Fair
2022-02-02  0:54     ` Yeechang Lee
2022-02-01 21:50 ` Win Treese
  -- strict thread matches above, loose matches on Subject: below --
2022-01-31 20:46 Will Senn
2022-02-01 15:37 ` arnold
2022-02-01 15:52   ` Ralph Corderoy
2022-02-01 16:58     ` Clem Cole
2022-02-01 17:02     ` silas poulson
2022-02-02  7:47     ` arnold
2022-02-03 18:57       ` silas poulson
2022-02-04  8:26         ` arnold
2022-02-04 19:41           ` John Cowan
2022-02-10 15:18       ` Ralph Corderoy
2022-02-03  4:00 ` Will Senn
2022-02-03  4:31   ` Al Kossow
2022-02-03  5:16     ` Warner Losh
2022-02-03 20:00   ` Adam Thornton
2022-02-04  6:06     ` Ori Idan
2022-02-04 17:35       ` Adam Thornton
2022-02-04 17:44         ` Will Senn

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