* 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 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 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 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 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 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-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
* [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
* 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
* 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-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: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 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-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 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-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-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-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-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-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 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-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-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-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
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).