* [TUHS] Re: What would early alternatives to C have been?
@ 2025-03-10 2:03 Douglas McIlroy
2025-03-10 2:28 ` Charles H. Sauer
` (2 more replies)
0 siblings, 3 replies; 68+ messages in thread
From: Douglas McIlroy @ 2025-03-10 2:03 UTC (permalink / raw)
To: TUHS main list
[-- Attachment #1: Type: text/plain, Size: 604 bytes --]
> everyone should write for their first compiler in Pascal for a
> simple language and no cheating using YACC. You need to write the whole
> thing if you want to understand how parsing really works.
Yacc certainly makes it easier to write parsers for big grammars, but
it's far from cheating. You need to know a lot more about parsing to use
Yacc than you need to roll your own.
Hand parsing of a tiny grammar is almost a necessary step on the way to
understanding Yacc. But I think hand-building the whole parser for a
compiler is unnecessary torture--like doing trigonometry with log tables.
Doug
[-- Attachment #2: Type: text/html, Size: 837 bytes --]
^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-10 2:03 [TUHS] Re: What would early alternatives to C have been? Douglas McIlroy @ 2025-03-10 2:28 ` Charles H. Sauer 2025-03-11 2:26 ` [TUHS] Re: uphill both ways, was " John Levine 2025-03-10 4:10 ` [TUHS] " Rob Pike 2025-03-10 15:12 ` Clem Cole 2 siblings, 1 reply; 68+ messages in thread From: Charles H. Sauer @ 2025-03-10 2:28 UTC (permalink / raw) To: Douglas McIlroy; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 1267 bytes --] [While walking 5 miles through the snow …] > On Mar 9, 2025, at 9:03 PM, Douglas McIlroy <douglas.mcilroy@dartmouth.edu> wrote: > > > everyone should write for their first compiler in Pascal for a > > simple language and no cheating using YACC. You need to write the whole > > thing if you want to understand how parsing really works. > > Yacc certainly makes it easier to write parsers for big grammars, but it's far from cheating. You need to know a lot more about parsing to use Yacc than you need to roll your own. > > Hand parsing of a tiny grammar is almost a necessary step on the way to understanding Yacc. But I think hand-building the whole parser for a compiler is unnecessary torture--like doing trigonometry with log tables. > > Doug In 1971 compiler construction course at UT-Austin, we had to use CDC Fortran to build a compiler for a subset of Algol 60. Undergraduates used punch cards and RJE to the 6600/6400 shared by all but the privleged few. Charlie -- voice: +1.512.784.7526 e-mail: sauer@technologists.com <mailto:sauer@technologists.com> fax: +1.512.346.5240 web: https://technologists.com/sauer/ <http://technologists.com/sauer/> Facebook/Google/LinkedIn/mas.to: CharlesHSauer [-- Attachment #2: Type: text/html, Size: 3550 bytes --] ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: uphill both ways, was Re: What would early alternatives to C have been? 2025-03-10 2:28 ` Charles H. Sauer @ 2025-03-11 2:26 ` John Levine 0 siblings, 0 replies; 68+ messages in thread From: John Levine @ 2025-03-11 2:26 UTC (permalink / raw) To: tuhs It appears that Charles H. Sauer <sauer@technologists.com> said: >In 1971 compiler construction course at UT-Austin, we had to use CDC Fortran to build a compiler for a subset of Algol 60. Undergraduates >used punch cards and RJE to the 6600/6400 shared by all but the privleged few. In my 1971 compiler course at Yale, Alan Perlis made us try to write a compiler that translated a subset of APL into Basic. He suggested we write it in APL, which was a terrible idea, so I wrote it in Trac, for which I happened to have written my own interpreter. I think my compiler was the only one that worked, and it was pretty clever, turning the APL array expressions into structures with array boundaries and example expressions, with no array temporaries. It only generated the loops to evaluate the expressions when storing into another array. Someone got a PhD in 1978 for a similar compiling technique but in 1971 I was a 17 year old twerp so what did I know? R's, John ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-10 2:03 [TUHS] Re: What would early alternatives to C have been? Douglas McIlroy 2025-03-10 2:28 ` Charles H. Sauer @ 2025-03-10 4:10 ` Rob Pike 2025-03-10 15:19 ` John Cowan 2025-03-10 15:12 ` Clem Cole 2 siblings, 1 reply; 68+ messages in thread From: Rob Pike @ 2025-03-10 4:10 UTC (permalink / raw) To: Douglas McIlroy; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 1756 bytes --] A rare case where I disagree with you, Doug. If the language is reasonably regular (I do not mean in the strict Kleene sense), a recursive descent parser is not much harder to write than a yacc grammar, and much smoother at providing good error messages. Having done many yaccs and many RD parsers, I no longer go to yacc. To put it another way, there are few programming tasks I enjoy more than writing a recursive descent parser for a sane language. Now if the language is not so regular, my position might shift. I do recall Bjarne dynamically editing the generated tables mid-parse to get yacc to handle at least one stage of C++'s development. Another way to think of it is that if you are designing the language and it is undergoing frequent changes in grammar, yacc could certainly be move you along faster. But even then once things had settled I'd still redo it as RD, for the quality of the result. You can credit Stephen R. "Software" Steve for this change in my thinking. -rob On Mon, Mar 10, 2025 at 1:12 PM Douglas McIlroy < douglas.mcilroy@dartmouth.edu> wrote: > > everyone should write for their first compiler in Pascal for a > > simple language and no cheating using YACC. You need to write the whole > > thing if you want to understand how parsing really works. > > Yacc certainly makes it easier to write parsers for big grammars, but > it's far from cheating. You need to know a lot more about parsing to use > Yacc than you need to roll your own. > > Hand parsing of a tiny grammar is almost a necessary step on the way to > understanding Yacc. But I think hand-building the whole parser for a > compiler is unnecessary torture--like doing trigonometry with log tables. > > Doug > [-- Attachment #2: Type: text/html, Size: 3105 bytes --] ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-10 4:10 ` [TUHS] " Rob Pike @ 2025-03-10 15:19 ` John Cowan 2025-03-10 19:56 ` Dave Horsfall 2025-03-10 20:49 ` Bakul Shah via TUHS 0 siblings, 2 replies; 68+ messages in thread From: John Cowan @ 2025-03-10 15:19 UTC (permalink / raw) To: Rob Pike; +Cc: Douglas McIlroy, TUHS main list [-- Attachment #1: Type: text/plain, Size: 2649 bytes --] I was working at the whiteboard during a job interview once. I had been asked to write a function to report if its input had balanced parentheses. No problem: I wrote an RD parser in Python (which I prefer for whiteboarding) to detect balance and return True if the parse was successful and False if EOF was reached. I was starting to write some tests when the interviewer interrupted me. "What is that?" "It's a recursive descent parser. It detects if the input is well-formed." Blank look. I started to walk him through the code. He interrupted me. "Excuse me, I'll be back in a few minutes." Long wait, maybe 15-20 minutes. Someone else comes in. "Thank you, the recruiter will get back to you." That's the last I hear from them. On Mon, Mar 10, 2025, 12:10 AM Rob Pike <robpike@gmail.com> wrote: > A rare case where I disagree with you, Doug. If the language is reasonably > regular (I do not mean in the strict Kleene sense), a recursive descent > parser is not much harder to write than a yacc grammar, and much smoother > at providing good error messages. Having done many yaccs and many RD > parsers, I no longer go to yacc. > > To put it another way, there are few programming tasks I enjoy more than > writing a recursive descent parser for a sane language. > > Now if the language is not so regular, my position might shift. I do > recall Bjarne dynamically editing the generated tables mid-parse to get > yacc to handle at least one stage of C++'s development. > > Another way to think of it is that if you are designing the language and > it is undergoing frequent changes in grammar, yacc could certainly be move > you along faster. But even then once things had settled I'd still redo it > as RD, for the quality of the result. > > You can credit Stephen R. "Software" Steve for this change in my thinking. > > -rob > > > On Mon, Mar 10, 2025 at 1:12 PM Douglas McIlroy < > douglas.mcilroy@dartmouth.edu> wrote: > >> > everyone should write for their first compiler in Pascal for a >> > simple language and no cheating using YACC. You need to write the whole >> > thing if you want to understand how parsing really works. >> >> Yacc certainly makes it easier to write parsers for big grammars, but >> it's far from cheating. You need to know a lot more about parsing to use >> Yacc than you need to roll your own. >> >> Hand parsing of a tiny grammar is almost a necessary step on the way to >> understanding Yacc. But I think hand-building the whole parser for a >> compiler is unnecessary torture--like doing trigonometry with log tables. >> >> Doug >> > [-- Attachment #2: Type: text/html, Size: 4605 bytes --] ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-10 15:19 ` John Cowan @ 2025-03-10 19:56 ` Dave Horsfall 2025-03-10 20:49 ` Bakul Shah via TUHS 1 sibling, 0 replies; 68+ messages in thread From: Dave Horsfall @ 2025-03-10 19:56 UTC (permalink / raw) To: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 675 bytes --] On Mon, 10 Mar 2025, John Cowan wrote: > I was working at the whiteboard during a job interview once. I had been > asked to write a function to report if its input had balanced parentheses. > No problem: I wrote an RD parser in Python (which I prefer for > whiteboarding) to detect balance and return True if the parse was successful > and False if EOF was reached. RD is a bit over the top, isn't it? Pseudocode: set counter to 0 while !EOF do read char char == "(" -> counter++ char == ")" -> counter-- abort "Unbalanced: )" if counter < 0 done abort "Unbalanced: (" if counter > 0 Untested, of course :-) -- Dave ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-10 15:19 ` John Cowan 2025-03-10 19:56 ` Dave Horsfall @ 2025-03-10 20:49 ` Bakul Shah via TUHS 2025-03-10 23:12 ` Marc Rochkind 2025-03-11 5:15 ` [TUHS] Re: What would early alternatives to C have been? John Cowan 1 sibling, 2 replies; 68+ messages in thread From: Bakul Shah via TUHS @ 2025-03-10 20:49 UTC (permalink / raw) To: John Cowan; +Cc: TUHS main list Perhaps the interviewer was looking for something dumb like the following and not a full RD parser? int count = 0; while (*cp) { char c = *cp++; count += c == '(' ? 1 : c == ')' ? -1 : 0; if (count < 0) return -1; // FAIL: one too many ) } if (count > 0) return -1; // FAIL: too many ( return 0; // SUCCESS Though this will fall apart if you also want to also balance braces &/or brackets and must catch invalid cases like "(..[..)..]"! > On Mar 10, 2025, at 8:19 AM, John Cowan <cowan@ccil.org> wrote: > > I was working at the whiteboard during a job interview once. I had been asked to write a function to report if its input had balanced parentheses. No problem: I wrote an RD parser in Python (which I prefer for whiteboarding) to detect balance and return True if the parse was successful and False if EOF was reached. > > I was starting to write some tests when the interviewer interrupted me. > > "What is that?" > > "It's a recursive descent parser. It detects if the input is well-formed." > > Blank look. > > I started to walk him through the code. > > He interrupted me. "Excuse me, I'll be back in a few minutes." > > Long wait, maybe 15-20 minutes. Someone else comes in. "Thank you, the recruiter will get back to you." That's the last I hear from them. ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-10 20:49 ` Bakul Shah via TUHS @ 2025-03-10 23:12 ` Marc Rochkind 2025-03-10 23:49 ` Clem Cole [not found] ` <CAKH6PiW8J8=uFbadUTSaC9VcLGUJMFZaSFWOFDyCM3MpMTSayw@mail.gmail.com <CAMP=X_mchJuVgdpc4-AYHASwEVzUcJXMmqSDv_UvX6y0o0+LBQ@mail.gmail.com> 2025-03-11 5:15 ` [TUHS] Re: What would early alternatives to C have been? John Cowan 1 sibling, 2 replies; 68+ messages in thread From: Marc Rochkind @ 2025-03-10 23:12 UTC (permalink / raw) To: TUHS main list [-- Attachment #1: Type: text/plain, Size: 2759 bytes --] This thread started to be about what I thought were system programming languages (e.g., C, BLISS) and seems to have meandered into a general discussion of languages that were around in the 1960s and 1970s, so, what the heck, I'll add my own story. PL/0 is an education programming language introduced in the book, *Algorithms + Data Structures = Programs*, by Niklaus Wirth in 1976. It's a great language for teaching compiler writing because it contains interesting concepts, such as recursive functions, yet isn't overly complicated. I wrote a PL/0 compiler for the IBM 701 ( https://github.com/MarcRochkind/pl0compiler). Yeah, that's not a misprint. I wrote perhaps the world's only 701 emulator ( https://www.mrochkind.com/mrochkind/a-701.html), and my PL/0 compiler runs on it. Unfortunately, I can't verify that the compiled code runs on an actual 701, since I'm sure there haven't been any in operation for many decades. For those of you who haven't had the pleasure, programming the 701 is really hard. It had no index registers, and the sign bit didn't participate in shifts. Still, my compiler compiles full-blown PL/0. So there! ;-) Marc Rochkind On Mon, Mar 10, 2025 at 2:49 PM Bakul Shah via TUHS <tuhs@tuhs.org> wrote: > Perhaps the interviewer was looking for something dumb like the following > and not a full RD parser? > > int count = 0; > while (*cp) { > char c = *cp++; > count += c == '(' ? 1 : c == ')' ? -1 : 0; > if (count < 0) return -1; // FAIL: one too many ) > } > if (count > 0) return -1; // FAIL: too many ( > return 0; // SUCCESS > > Though this will fall apart if you also want to also balance braces &/or > brackets and must catch invalid cases like "(..[..)..]"! > > > On Mar 10, 2025, at 8:19 AM, John Cowan <cowan@ccil.org> wrote: > > > > I was working at the whiteboard during a job interview once. I had been > asked to write a function to report if its input had balanced parentheses. > No problem: I wrote an RD parser in Python (which I prefer for > whiteboarding) to detect balance and return True if the parse was > successful and False if EOF was reached. > > > > I was starting to write some tests when the interviewer interrupted me. > > > > "What is that?" > > > > "It's a recursive descent parser. It detects if the input is > well-formed." > > > > Blank look. > > > > I started to walk him through the code. > > > > He interrupted me. "Excuse me, I'll be back in a few minutes." > > > > Long wait, maybe 15-20 minutes. Someone else comes in. "Thank you, the > recruiter will get back to you." That's the last I hear from them. > > -- Subscribe to my Photo-of-the-Week emails at my website mrochkind.com. [-- Attachment #2: Type: text/html, Size: 3755 bytes --] ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-10 23:12 ` Marc Rochkind @ 2025-03-10 23:49 ` Clem Cole 2025-03-10 23:58 ` Marc Rochkind 2025-03-11 0:06 ` Ken Thompson [not found] ` <CAKH6PiW8J8=uFbadUTSaC9VcLGUJMFZaSFWOFDyCM3MpMTSayw@mail.gmail.com <CAMP=X_mchJuVgdpc4-AYHASwEVzUcJXMmqSDv_UvX6y0o0+LBQ@mail.gmail.com> 1 sibling, 2 replies; 68+ messages in thread From: Clem Cole @ 2025-03-10 23:49 UTC (permalink / raw) To: Marc Rochkind; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 3132 bytes --] Marc - check out OpenSIMH( https://opensimh.org) Check out over 40 different simulators including the I7000 which supports IBM 701,7010,7070,7080, 7090 - https://opensimh.org/simulators/ ᐧ On Mon, Mar 10, 2025 at 7:12 PM Marc Rochkind <mrochkind@gmail.com> wrote: > This thread started to be about what I thought were system programming > languages (e.g., C, BLISS) and seems to have meandered into a general > discussion of languages that were around in the 1960s and 1970s, so, what > the heck, I'll add my own story. > > PL/0 is an education programming language introduced in the book, *Algorithms > + Data Structures = Programs*, by Niklaus Wirth in 1976. It's a great > language for teaching compiler writing because it contains interesting > concepts, such as recursive functions, yet isn't overly complicated. I > wrote a PL/0 compiler for the IBM 701 ( > https://github.com/MarcRochkind/pl0compiler). > > Yeah, that's not a misprint. I wrote perhaps the world's only 701 emulator > (https://www.mrochkind.com/mrochkind/a-701.html), and my PL/0 compiler > runs on it. Unfortunately, I can't verify that the compiled code runs on an > actual 701, since I'm sure there haven't been any in operation for many > decades. For those of you who haven't had the pleasure, programming the 701 > is really hard. It had no index registers, and the sign bit didn't > participate in shifts. Still, my compiler compiles full-blown PL/0. > > So there! ;-) > > Marc Rochkind > > On Mon, Mar 10, 2025 at 2:49 PM Bakul Shah via TUHS <tuhs@tuhs.org> wrote: > >> Perhaps the interviewer was looking for something dumb like the following >> and not a full RD parser? >> >> int count = 0; >> while (*cp) { >> char c = *cp++; >> count += c == '(' ? 1 : c == ')' ? -1 : 0; >> if (count < 0) return -1; // FAIL: one too many ) >> } >> if (count > 0) return -1; // FAIL: too many ( >> return 0; // SUCCESS >> >> Though this will fall apart if you also want to also balance braces &/or >> brackets and must catch invalid cases like "(..[..)..]"! >> >> > On Mar 10, 2025, at 8:19 AM, John Cowan <cowan@ccil.org> wrote: >> > >> > I was working at the whiteboard during a job interview once. I had been >> asked to write a function to report if its input had balanced parentheses. >> No problem: I wrote an RD parser in Python (which I prefer for >> whiteboarding) to detect balance and return True if the parse was >> successful and False if EOF was reached. >> > >> > I was starting to write some tests when the interviewer interrupted me. >> > >> > "What is that?" >> > >> > "It's a recursive descent parser. It detects if the input is >> well-formed." >> > >> > Blank look. >> > >> > I started to walk him through the code. >> > >> > He interrupted me. "Excuse me, I'll be back in a few minutes." >> > >> > Long wait, maybe 15-20 minutes. Someone else comes in. "Thank you, the >> recruiter will get back to you." That's the last I hear from them. >> >> > > -- > Subscribe to my Photo-of-the-Week emails at my website mrochkind.com. > [-- Attachment #2: Type: text/html, Size: 5058 bytes --] ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-10 23:49 ` Clem Cole @ 2025-03-10 23:58 ` Marc Rochkind 2025-03-11 0:06 ` Ken Thompson 1 sibling, 0 replies; 68+ messages in thread From: Marc Rochkind @ 2025-03-10 23:58 UTC (permalink / raw) To: Clem Cole; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 456 bytes --] Clem, thanks... didn't know about those. MIne has two features that the other one perhaps doesn't: A fully functional control panel, and it operates at the speed of the 701. On Mon, Mar 10, 2025 at 5:49 PM Clem Cole <clemc@ccc.com> wrote: > Marc - check out OpenSIMH( https://opensimh.org) > Check out over 40 different simulators including the I7000 which > supports IBM 701,7010,7070,7080, 7090 - https://opensimh.org/simulators/ > > > [-- Attachment #2: Type: text/html, Size: 1164 bytes --] ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-10 23:49 ` Clem Cole 2025-03-10 23:58 ` Marc Rochkind @ 2025-03-11 0:06 ` Ken Thompson 2025-03-11 1:35 ` Larry McVoy 1 sibling, 1 reply; 68+ messages in thread From: Ken Thompson @ 2025-03-11 0:06 UTC (permalink / raw) To: Clem Cole; +Cc: Marc Rochkind, TUHS main list [-- Attachment #1: Type: text/plain, Size: 3503 bytes --] re yacc vs RD i agree that they are about the same, where the edge would tilt based on the parsed language. BUT when the parsed language (like go) is not yet defined, yacc is the only option. On Mon, Mar 10, 2025 at 4:50 PM Clem Cole <clemc@ccc.com> wrote: > Marc - check out OpenSIMH( https://opensimh.org) > Check out over 40 different simulators including the I7000 which > supports IBM 701,7010,7070,7080, 7090 - https://opensimh.org/simulators/ > > > ᐧ > > On Mon, Mar 10, 2025 at 7:12 PM Marc Rochkind <mrochkind@gmail.com> wrote: > >> This thread started to be about what I thought were system programming >> languages (e.g., C, BLISS) and seems to have meandered into a general >> discussion of languages that were around in the 1960s and 1970s, so, what >> the heck, I'll add my own story. >> >> PL/0 is an education programming language introduced in the book, *Algorithms >> + Data Structures = Programs*, by Niklaus Wirth in 1976. It's a great >> language for teaching compiler writing because it contains interesting >> concepts, such as recursive functions, yet isn't overly complicated. I >> wrote a PL/0 compiler for the IBM 701 ( >> https://github.com/MarcRochkind/pl0compiler). >> >> Yeah, that's not a misprint. I wrote perhaps the world's only 701 >> emulator (https://www.mrochkind.com/mrochkind/a-701.html), and my PL/0 >> compiler runs on it. Unfortunately, I can't verify that the compiled code >> runs on an actual 701, since I'm sure there haven't been any in operation >> for many decades. For those of you who haven't had the pleasure, >> programming the 701 is really hard. It had no index registers, and the sign >> bit didn't participate in shifts. Still, my compiler compiles full-blown >> PL/0. >> >> So there! ;-) >> >> Marc Rochkind >> >> On Mon, Mar 10, 2025 at 2:49 PM Bakul Shah via TUHS <tuhs@tuhs.org> >> wrote: >> >>> Perhaps the interviewer was looking for something dumb like the following >>> and not a full RD parser? >>> >>> int count = 0; >>> while (*cp) { >>> char c = *cp++; >>> count += c == '(' ? 1 : c == ')' ? -1 : 0; >>> if (count < 0) return -1; // FAIL: one too many ) >>> } >>> if (count > 0) return -1; // FAIL: too many ( >>> return 0; // SUCCESS >>> >>> Though this will fall apart if you also want to also balance braces &/or >>> brackets and must catch invalid cases like "(..[..)..]"! >>> >>> > On Mar 10, 2025, at 8:19 AM, John Cowan <cowan@ccil.org> wrote: >>> > >>> > I was working at the whiteboard during a job interview once. I had >>> been asked to write a function to report if its input had balanced >>> parentheses. No problem: I wrote an RD parser in Python (which I prefer >>> for whiteboarding) to detect balance and return True if the parse was >>> successful and False if EOF was reached. >>> > >>> > I was starting to write some tests when the interviewer interrupted me. >>> > >>> > "What is that?" >>> > >>> > "It's a recursive descent parser. It detects if the input is >>> well-formed." >>> > >>> > Blank look. >>> > >>> > I started to walk him through the code. >>> > >>> > He interrupted me. "Excuse me, I'll be back in a few minutes." >>> > >>> > Long wait, maybe 15-20 minutes. Someone else comes in. "Thank you, the >>> recruiter will get back to you." That's the last I hear from them. >>> >>> >> >> -- >> Subscribe to my Photo-of-the-Week emails at my website mrochkind.com. >> > [-- Attachment #2: Type: text/html, Size: 5731 bytes --] ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-11 0:06 ` Ken Thompson @ 2025-03-11 1:35 ` Larry McVoy 2025-03-11 5:07 ` Ken Thompson 0 siblings, 1 reply; 68+ messages in thread From: Larry McVoy @ 2025-03-11 1:35 UTC (permalink / raw) To: TUHS main list; +Cc: rob I'm guessing this is because yacc makes it easy to fiddle with the grammar? Does performance factor in? I'm actually curious because BitKeeper has what we call a dspec language which lets you wander through the revision history and print it out in a sort of awk/printf like language. If my memory serves me, we had a version in yacc (really flex but same thing) and Rob (cc-ed) rewrote it in a recursive-descent parser for performance reasons. If you are curious, this is a dspec that spits out history in JSON format that I wrote because one of my engineers said it was impossible (it wasn't): http://mcvoy.com/lm/bkdocs/dspec-changes-json-v.txt $0 .. $9 are variables. We used $if as a way to get an if statement rather than just say "if", :whatever: is a way to fish some field out of the history, Marc will get it, it's SCCS's :D: that means date, we just took it a lot further. I don't remember how much faster the RD version was but it was a lot, for sure more than a factor of 2 and maybe much more than that. All I remember is at some point the dspec parser was a performance issue and after Rob rewrote it, it wasn't. On Mon, Mar 10, 2025 at 05:06:13PM -0700, Ken Thompson wrote: > re yacc vs RD > > i agree that they are about the same, > where the edge would tilt based on the parsed language. > BUT when the parsed language (like go) is not yet defined, > yacc is the only option. > > > > On Mon, Mar 10, 2025 at 4:50???PM Clem Cole <clemc@ccc.com> wrote: > > > Marc - check out OpenSIMH( https://opensimh.org) > > Check out over 40 different simulators including the I7000 which > > supports IBM 701,7010,7070,7080, 7090 - https://opensimh.org/simulators/ > > > > > > ??? > > > > On Mon, Mar 10, 2025 at 7:12???PM Marc Rochkind <mrochkind@gmail.com> wrote: > > > >> This thread started to be about what I thought were system programming > >> languages (e.g., C, BLISS) and seems to have meandered into a general > >> discussion of languages that were around in the 1960s and 1970s, so, what > >> the heck, I'll add my own story. > >> > >> PL/0 is an education programming language introduced in the book, *Algorithms > >> + Data Structures = Programs*, by Niklaus Wirth in 1976. It's a great > >> language for teaching compiler writing because it contains interesting > >> concepts, such as recursive functions, yet isn't overly complicated. I > >> wrote a PL/0 compiler for the IBM 701 ( > >> https://github.com/MarcRochkind/pl0compiler). > >> > >> Yeah, that's not a misprint. I wrote perhaps the world's only 701 > >> emulator (https://www.mrochkind.com/mrochkind/a-701.html), and my PL/0 > >> compiler runs on it. Unfortunately, I can't verify that the compiled code > >> runs on an actual 701, since I'm sure there haven't been any in operation > >> for many decades. For those of you who haven't had the pleasure, > >> programming the 701 is really hard. It had no index registers, and the sign > >> bit didn't participate in shifts. Still, my compiler compiles full-blown > >> PL/0. > >> > >> So there! ;-) > >> > >> Marc Rochkind > >> > >> On Mon, Mar 10, 2025 at 2:49???PM Bakul Shah via TUHS <tuhs@tuhs.org> > >> wrote: > >> > >>> Perhaps the interviewer was looking for something dumb like the following > >>> and not a full RD parser? > >>> > >>> int count = 0; > >>> while (*cp) { > >>> char c = *cp++; > >>> count += c == '(' ? 1 : c == ')' ? -1 : 0; > >>> if (count < 0) return -1; // FAIL: one too many ) > >>> } > >>> if (count > 0) return -1; // FAIL: too many ( > >>> return 0; // SUCCESS > >>> > >>> Though this will fall apart if you also want to also balance braces &/or > >>> brackets and must catch invalid cases like "(..[..)..]"! > >>> > >>> > On Mar 10, 2025, at 8:19???AM, John Cowan <cowan@ccil.org> wrote: > >>> > > >>> > I was working at the whiteboard during a job interview once. I had > >>> been asked to write a function to report if its input had balanced > >>> parentheses. No problem: I wrote an RD parser in Python (which I prefer > >>> for whiteboarding) to detect balance and return True if the parse was > >>> successful and False if EOF was reached. > >>> > > >>> > I was starting to write some tests when the interviewer interrupted me. > >>> > > >>> > "What is that?" > >>> > > >>> > "It's a recursive descent parser. It detects if the input is > >>> well-formed." > >>> > > >>> > Blank look. > >>> > > >>> > I started to walk him through the code. > >>> > > >>> > He interrupted me. "Excuse me, I'll be back in a few minutes." > >>> > > >>> > Long wait, maybe 15-20 minutes. Someone else comes in. "Thank you, the > >>> recruiter will get back to you." That's the last I hear from them. > >>> > >>> > >> > >> -- > >> Subscribe to my Photo-of-the-Week emails at my website mrochkind.com. > >> > > -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-11 1:35 ` Larry McVoy @ 2025-03-11 5:07 ` Ken Thompson 0 siblings, 0 replies; 68+ messages in thread From: Ken Thompson @ 2025-03-11 5:07 UTC (permalink / raw) To: Larry McVoy; +Cc: TUHS main list, rob [-- Attachment #1: Type: text/plain, Size: 5488 bytes --] i find that SD and yacc have about the same time performance. yacc gets a bad rep when it uses lex as its front-end. then it is pig-slow. On Mon, Mar 10, 2025 at 6:52 PM Larry McVoy <lm@mcvoy.com> wrote: > I'm guessing this is because yacc makes it easy to fiddle with the grammar? > Does performance factor in? > > I'm actually curious because BitKeeper has what we call a dspec language > which lets you wander through the revision history and print it out in > a sort of awk/printf like language. If my memory serves me, we had a > version in yacc (really flex but same thing) and Rob (cc-ed) rewrote > it in a recursive-descent parser for performance reasons. If you are > curious, this is a dspec that spits out history in JSON format that > I wrote because one of my engineers said it was impossible (it wasn't): > > http://mcvoy.com/lm/bkdocs/dspec-changes-json-v.txt > > $0 .. $9 are variables. We used $if as a way to get an if statement > rather than just say "if", :whatever: is a way to fish some field out > of the history, Marc will get it, it's SCCS's :D: that means date, we > just took it a lot further. > > I don't remember how much faster the RD version was but it was a lot, > for sure more than a factor of 2 and maybe much more than that. All > I remember is at some point the dspec parser was a performance issue > and after Rob rewrote it, it wasn't. > > On Mon, Mar 10, 2025 at 05:06:13PM -0700, Ken Thompson wrote: > > re yacc vs RD > > > > i agree that they are about the same, > > where the edge would tilt based on the parsed language. > > BUT when the parsed language (like go) is not yet defined, > > yacc is the only option. > > > > > > > > On Mon, Mar 10, 2025 at 4:50???PM Clem Cole <clemc@ccc.com> wrote: > > > > > Marc - check out OpenSIMH( https://opensimh.org) > > > Check out over 40 different simulators including the I7000 which > > > supports IBM 701,7010,7070,7080, 7090 - > https://opensimh.org/simulators/ > > > > > > > > > ??? > > > > > > On Mon, Mar 10, 2025 at 7:12???PM Marc Rochkind <mrochkind@gmail.com> > wrote: > > > > > >> This thread started to be about what I thought were system programming > > >> languages (e.g., C, BLISS) and seems to have meandered into a general > > >> discussion of languages that were around in the 1960s and 1970s, so, > what > > >> the heck, I'll add my own story. > > >> > > >> PL/0 is an education programming language introduced in the book, > *Algorithms > > >> + Data Structures = Programs*, by Niklaus Wirth in 1976. It's a great > > >> language for teaching compiler writing because it contains interesting > > >> concepts, such as recursive functions, yet isn't overly complicated. I > > >> wrote a PL/0 compiler for the IBM 701 ( > > >> https://github.com/MarcRochkind/pl0compiler). > > >> > > >> Yeah, that's not a misprint. I wrote perhaps the world's only 701 > > >> emulator (https://www.mrochkind.com/mrochkind/a-701.html), and my > PL/0 > > >> compiler runs on it. Unfortunately, I can't verify that the compiled > code > > >> runs on an actual 701, since I'm sure there haven't been any in > operation > > >> for many decades. For those of you who haven't had the pleasure, > > >> programming the 701 is really hard. It had no index registers, and > the sign > > >> bit didn't participate in shifts. Still, my compiler compiles > full-blown > > >> PL/0. > > >> > > >> So there! ;-) > > >> > > >> Marc Rochkind > > >> > > >> On Mon, Mar 10, 2025 at 2:49???PM Bakul Shah via TUHS <tuhs@tuhs.org> > > >> wrote: > > >> > > >>> Perhaps the interviewer was looking for something dumb like the > following > > >>> and not a full RD parser? > > >>> > > >>> int count = 0; > > >>> while (*cp) { > > >>> char c = *cp++; > > >>> count += c == '(' ? 1 : c == ')' ? -1 : 0; > > >>> if (count < 0) return -1; // FAIL: one too many ) > > >>> } > > >>> if (count > 0) return -1; // FAIL: too many ( > > >>> return 0; // SUCCESS > > >>> > > >>> Though this will fall apart if you also want to also balance braces > &/or > > >>> brackets and must catch invalid cases like "(..[..)..]"! > > >>> > > >>> > On Mar 10, 2025, at 8:19???AM, John Cowan <cowan@ccil.org> wrote: > > >>> > > > >>> > I was working at the whiteboard during a job interview once. I had > > >>> been asked to write a function to report if its input had balanced > > >>> parentheses. No problem: I wrote an RD parser in Python (which I > prefer > > >>> for whiteboarding) to detect balance and return True if the parse was > > >>> successful and False if EOF was reached. > > >>> > > > >>> > I was starting to write some tests when the interviewer > interrupted me. > > >>> > > > >>> > "What is that?" > > >>> > > > >>> > "It's a recursive descent parser. It detects if the input is > > >>> well-formed." > > >>> > > > >>> > Blank look. > > >>> > > > >>> > I started to walk him through the code. > > >>> > > > >>> > He interrupted me. "Excuse me, I'll be back in a few minutes." > > >>> > > > >>> > Long wait, maybe 15-20 minutes. Someone else comes in. "Thank you, > the > > >>> recruiter will get back to you." That's the last I hear from them. > > >>> > > >>> > > >> > > >> -- > > >> Subscribe to my Photo-of-the-Week emails at my website mrochkind.com. > > >> > > > > > -- > --- > Larry McVoy Retired to fishing > http://www.mcvoy.com/lm/boat > [-- Attachment #2: Type: text/html, Size: 7947 bytes --] ^ permalink raw reply [flat|nested] 68+ messages in thread
[parent not found: <CAKH6PiW8J8=uFbadUTSaC9VcLGUJMFZaSFWOFDyCM3MpMTSayw@mail.gmail.com <CAMP=X_mchJuVgdpc4-AYHASwEVzUcJXMmqSDv_UvX6y0o0+LBQ@mail.gmail.com>]
* [TUHS] Re: parsing tools, was What would early alternatives [not found] ` <CAKH6PiW8J8=uFbadUTSaC9VcLGUJMFZaSFWOFDyCM3MpMTSayw@mail.gmail.com <CAMP=X_mchJuVgdpc4-AYHASwEVzUcJXMmqSDv_UvX6y0o0+LBQ@mail.gmail.com> @ 2025-03-12 1:36 ` John Levine 2025-03-12 2:22 ` Rich Salz 2025-03-12 5:11 ` Greg A. Woods 0 siblings, 2 replies; 68+ messages in thread From: John Levine @ 2025-03-12 1:36 UTC (permalink / raw) To: tuhs According to Ken Thompson <kenbob@gmail.com>: >-=-=-=-=-=- > >i find that SD and yacc have about the same >time performance. yacc gets a bad rep when >it uses lex as its front-end. then it is pig-slow. Parsing is never a performance issue since its time is generally O(n) where n is the number of tokens emitted by the lexer and the constant is not large. The lexer always is because it's the only part of the compiler that has to look at every input character separately. If a compiler does a lot of optimization, the analysis for that can be slow, too. Lex was a dog. Flex, which as far as I know was a complete rewrite that shared no code with lex, are not bad. -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: parsing tools, was What would early alternatives 2025-03-12 1:36 ` [TUHS] Re: parsing tools, was What would early alternatives John Levine @ 2025-03-12 2:22 ` Rich Salz 2025-03-12 3:35 ` Larry McVoy 2025-03-12 16:35 ` John R Levine 2025-03-12 5:11 ` Greg A. Woods 1 sibling, 2 replies; 68+ messages in thread From: Rich Salz @ 2025-03-12 2:22 UTC (permalink / raw) To: John Levine; +Cc: tuhs [-- Attachment #1: Type: text/plain, Size: 961 bytes --] > > Lex was a dog. Flex, which as far as I know was a complete rewrite > that shared no code with lex, are not bad. > Yes, "it's true what they say about lex" was a common phrase. (I think I first saw it in the pathalias paper.) There was a Usenix presentation -- late 80's (Washington?) but I couldn't find it. -- by Vern Paxson about his rewrite called flex. I think he said that the main reason lex was slow was the clever folding it had to do of its internal tables to fit. Sadly Vern never got his paper in, but the presentation showed a group with three lines, one at the top being slow lex, the next two much lower on the Y axis being very close. He said the second line was flex. Someone said what about the third, fastest, line? His answer "that's cat" Vern worked with Van on early network improvements (web-search the both of them for a fun time). Flex first posted to Usenet in 1988, https://groups.google.com/g/comp.sources.unix/c/LZ_EHqd7XBg [-- Attachment #2: Type: text/html, Size: 1386 bytes --] ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: parsing tools, was What would early alternatives 2025-03-12 2:22 ` Rich Salz @ 2025-03-12 3:35 ` Larry McVoy 2025-03-12 16:35 ` John R Levine 1 sibling, 0 replies; 68+ messages in thread From: Larry McVoy @ 2025-03-12 3:35 UTC (permalink / raw) To: Rich Salz; +Cc: John Levine, tuhs On Tue, Mar 11, 2025 at 10:22:00PM -0400, Rich Salz wrote: > Vern worked with Van on early network improvements (web-search the both of > them for a fun time). Van was my networking hero until Drew at Netfix did the two side by side stacks. I'm not sure who is better, but I'm sure they are both better than me and I don't suck. I agree with Rich, check Van out, check Drew out. ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: parsing tools, was What would early alternatives 2025-03-12 2:22 ` Rich Salz 2025-03-12 3:35 ` Larry McVoy @ 2025-03-12 16:35 ` John R Levine 1 sibling, 0 replies; 68+ messages in thread From: John R Levine @ 2025-03-12 16:35 UTC (permalink / raw) To: Rich Salz; +Cc: tuhs On Tue, 11 Mar 2025, Rich Salz wrote: >> Lex was a dog. Flex, which as far as I know was a complete rewrite >> that shared no code with lex, are not bad. > There was a Usenix presentation -- late 80's (Washington?) but I couldn't > find it. -- by Vern Paxson about his rewrite called flex. I think he said > that the main reason lex was slow was the clever folding it had to do of > its internal tables to fit. Maybe, maybe not just great programming. It was mostly written by a summer student named Eric Schmidt. I wonder what happened to him. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: parsing tools, was What would early alternatives 2025-03-12 1:36 ` [TUHS] Re: parsing tools, was What would early alternatives John Levine 2025-03-12 2:22 ` Rich Salz @ 2025-03-12 5:11 ` Greg A. Woods 1 sibling, 0 replies; 68+ messages in thread From: Greg A. Woods @ 2025-03-12 5:11 UTC (permalink / raw) To: The Unix Heritage Society mailing list [-- Attachment #1: Type: text/plain, Size: 639 bytes --] At 12 Mar 2025 01:36:09 -0000, "John Levine" <johnl@taugh.com> wrote: Subject: [TUHS] Re: parsing tools, was What would early alternatives > > Lex was a dog. Flex, which as far as I know was a complete rewrite > that shared no code with lex, are not bad. I've always understood the 'F' in Flex stood for "Fast". In fact it says as much right in the title of the manual page (right from the first post to Usenet): flex - fast lexical analyzer generator -- Greg A. Woods <gwoods@acm.org> Kelowna, BC +1 250 762-7675 RoboHack <woods@robohack.ca> Planix, Inc. <woods@planix.com> Avoncote Farms <woods@avoncote.ca> [-- Attachment #2: OpenPGP Digital Signature --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-10 20:49 ` Bakul Shah via TUHS 2025-03-10 23:12 ` Marc Rochkind @ 2025-03-11 5:15 ` John Cowan 1 sibling, 0 replies; 68+ messages in thread From: John Cowan @ 2025-03-11 5:15 UTC (permalink / raw) To: Bakul Shah; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 1777 bytes --] Very probably. But under pressure I went with what I knew I could get right. In hindsight it was like one of those non-quantitative multiple-choice tests where you have to figure out not the correct answer but the answer that the test author is most likely to believe to be correct. On Mon, Mar 10, 2025, 4:49 PM Bakul Shah <bakul@iitbombay.org> wrote: > Perhaps the interviewer was looking for something dumb like the following > and not a full RD parser? > > int count = 0; > while (*cp) { > char c = *cp++; > count += c == '(' ? 1 : c == ')' ? -1 : 0; > if (count < 0) return -1; // FAIL: one too many ) > } > if (count > 0) return -1; // FAIL: too many ( > return 0; // SUCCESS > > Though this will fall apart if you also want to also balance braces &/or > brackets and must catch invalid cases like "(..[..)..]"! > > > On Mar 10, 2025, at 8:19 AM, John Cowan <cowan@ccil.org> wrote: > > > > I was working at the whiteboard during a job interview once. I had been > asked to write a function to report if its input had balanced parentheses. > No problem: I wrote an RD parser in Python (which I prefer for > whiteboarding) to detect balance and return True if the parse was > successful and False if EOF was reached. > > > > I was starting to write some tests when the interviewer interrupted me. > > > > "What is that?" > > > > "It's a recursive descent parser. It detects if the input is > well-formed." > > > > Blank look. > > > > I started to walk him through the code. > > > > He interrupted me. "Excuse me, I'll be back in a few minutes." > > > > Long wait, maybe 15-20 minutes. Someone else comes in. "Thank you, the > recruiter will get back to you." That's the last I hear from them. > > [-- Attachment #2: Type: text/html, Size: 2339 bytes --] ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-10 2:03 [TUHS] Re: What would early alternatives to C have been? Douglas McIlroy 2025-03-10 2:28 ` Charles H. Sauer 2025-03-10 4:10 ` [TUHS] " Rob Pike @ 2025-03-10 15:12 ` Clem Cole 2025-03-10 15:24 ` Dan Cross 2 siblings, 1 reply; 68+ messages in thread From: Clem Cole @ 2025-03-10 15:12 UTC (permalink / raw) To: Douglas McIlroy; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 2075 bytes --] below... (At the risk of a case of being in disagreement with someone I rarely am). On Sun, Mar 9, 2025 at 10:03 PM Douglas McIlroy < douglas.mcilroy@dartmouth.edu> wrote: > > Yacc certainly makes it easier to write parsers for big grammars, but > it's far from cheating. You need to know a lot more about parsing to use > Yacc than you need to roll your own. > I disagree here. I have wtchged too many young programmers that I realized did not understand what yacc was doing and came to understanding that never built a simple parse before. I'm not asking them to rebuild a parser for Algol68 or C++ in a one semester course. I asking that to you take something like Dennis Allisons "tiny basic" assignment for his Stanfrodf students in the lat 1970s and ask them to build that. Peter Hibbard gave us a super small Algol-ish language, and we generated code for the "CMU Mini" (which was basically Gordon Bell's the precursor to the PDP-8 (see ISP below) - in my time the "Dragon Book was not yet written BTW. I really understood what Stev had accomplished. The interesting thing is while I tend to use yacc for most parsers, I've found myself building recursive descent parsers in a couple of cases where it seems to make better sense. > > Hand parsing of a tiny grammar is almost a necessary step on the way to > understanding Yacc. But I think hand-building the whole parser for a > compiler is unnecessary torture--like doing trigonometry with log tables. > Point table ... however a funny thing to consider. My father was a high school math teacher for 40 years. He noted that the loss of slide rules and trig tables made his "modern" (post-calculator) students not understand interpolation.To me, learning to use mathematical tables is a skill that never hurts. I don't even think of asking people "to walk uphill both ways to school in the snow and rain instead of riding a heated, dry yellow school bus." I am asking the student to learn foundational ideas and build skills up top of core understanding. ᐧ [-- Attachment #2: Type: text/html, Size: 4867 bytes --] ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-10 15:12 ` Clem Cole @ 2025-03-10 15:24 ` Dan Cross 0 siblings, 0 replies; 68+ messages in thread From: Dan Cross @ 2025-03-10 15:24 UTC (permalink / raw) To: Clem Cole; +Cc: Douglas McIlroy, TUHS main list On Mon, Mar 10, 2025 at 11:13 AM Clem Cole <clemc@ccc.com> wrote: > On Sun, Mar 9, 2025 at 10:03 PM Douglas McIlroy <douglas.mcilroy@dartmouth.edu> wrote: >> Yacc certainly makes it easier to write parsers for big grammars, but it's far from cheating. You need to know a lot more about parsing to use Yacc than you need to roll your own. > > I disagree here. I have wtchged too many young programmers that I realized did not understand what yacc was doing and came to understanding that never built a simple parse before. Funny, I agree with both of you, and with Rob. :-) If I'm not mistaken, I think what Doug was suggesting was that, to really understand what YACC is _doing_ requires understanding a lot more about the theory of parsing, grammars, and so on, than one needs to understand to write a fairly simple RD parser. RD makes a lot of sense intuitively, but once you introduce table-driven parsing, LALR(1), etc, you get into a whole different level of theory and rigor. Of course, by design the tool abstracts that away from you, so to just _use_ it you don't necessarily need to understand as much. >[...] > The interesting thing is while I tend to use yacc for most parsers, I've found myself building recursive descent parsers in a couple of cases where it seems to make better sense. Funny, I'm the opposite: I've used YACC for a few parsers, but prefer to roll my own. I find that I'm either parsing something very simple, in which case reaching for YACC feels like cutting butter with a chainsaw, or I need to do something that YACC isn't super great at (like run in a multithreaded environment). YACC is superb at what it does, but not something I feel like I need that often. - Dan C. ^ permalink raw reply [flat|nested] 68+ messages in thread
[parent not found: <174154718981.615624.15831772136951719489@minnie.tuhs.org>]
* [TUHS] Re: What would early alternatives to C have been? [not found] <174154718981.615624.15831772136951719489@minnie.tuhs.org> @ 2025-03-09 21:01 ` Paul McJones 2025-03-10 0:38 ` Ken Thompson 0 siblings, 1 reply; 68+ messages in thread From: Paul McJones @ 2025-03-09 21:01 UTC (permalink / raw) To: Ken Thompson; +Cc: tuhs [-- Attachment #1: Type: text/plain, Size: 925 bytes --] Ken, Was smalgol also known as BC Algol, as described here: https://www.softwarepreservation.org/projects/ALGOL/algol60impl/#BC_ALGOL > On Mar 9, 2025, at 12:06 PM, Ken Thompson <kenbob@gmail.com <mailto:kenbob@gmail.com>> > wrote: > > how about smalgol? > > it was an algol-like language with just int and float types. > i dont know its history, but it came out of berkeley near > when Niklaus Wirth was there. it compiled for the ibm 7094 > in normal batch processing fashion. i converted it to a jit > into memory in order to skip the loading phase. i used > it for a lot of my fun-work. (1965-66) > > mainframe time, then, was a big factor in the computing process. > smalgol could compile, load, and run in about 1 cpu-second. > > smalgol was all ibm-cards, but it was on my mind through > the bcpl to b to nb phases. i would use the modern word > "influencer.” Paul McJones [-- Attachment #2: Type: text/html, Size: 10734 bytes --] ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-09 21:01 ` Paul McJones @ 2025-03-10 0:38 ` Ken Thompson 0 siblings, 0 replies; 68+ messages in thread From: Ken Thompson @ 2025-03-10 0:38 UTC (permalink / raw) To: Paul McJones; +Cc: tuhs [-- Attachment #1: Type: text/plain, Size: 1510 bytes --] > Was smalgol also known as BC Algol, as described here: no, bc algol was a phd thesis of ralph love. i was an RA for ralph. he was a phd student for wirth. it was supposed to be the first (only?) complete implementation of algol 60. (thats an interesting statement: think of integer labels, and recursive call by name.) i coded most of the compile-to-byte-code pass of the compiler. ralph designed it. later i wrote a byte-code interpreter on a pdp-8s, which showed the memory state graphically. On Sun, Mar 9, 2025 at 2:01 PM Paul McJones <paul@mcjones.org> wrote: > Ken, > > Was smalgol also known as BC Algol, as described here: > > https://www.softwarepreservation.org/projects/ALGOL/algol60impl/#BC_ALGOL > > On Mar 9, 2025, at 12:06 PM, Ken Thompson <kenbob@gmail.com> > > wrote: > > how about smalgol? > > it was an algol-like language with just int and float types. > i dont know its history, but it came out of berkeley near > when Niklaus Wirth was there. it compiled for the ibm 7094 > in normal batch processing fashion. i converted it to a jit > into memory in order to skip the loading phase. i used > it for a lot of my fun-work. (1965-66) > > mainframe time, then, was a big factor in the computing process. > smalgol could compile, load, and run in about 1 cpu-second. > > smalgol was all ibm-cards, but it was on my mind through > the bcpl to b to nb phases. i would use the modern word > "influencer.” > > > > Paul McJones > > > [-- Attachment #2: Type: text/html, Size: 9190 bytes --] ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] What would early alternatives to C have been? @ 2025-03-09 3:46 Dan Cross 2025-03-09 6:14 ` [TUHS] " George Michaelson ` (3 more replies) 0 siblings, 4 replies; 68+ messages in thread From: Dan Cross @ 2025-03-09 3:46 UTC (permalink / raw) To: TUHS As I mentioned in the discussion about C, it's easy to look back with a modern perspective and cast aspersions on C. But this got me thinking, what would possible alternatives have been? In the context of the very late 1960s heading into the early 70s, and given the constraints of the PDP-7 and early PDP-11s, what languages would one consider for implementing a system like early Unix? Dennis's history paper mentioned a very short-lived effort at Fortran, and I asked about that a few years ago, but no one really remembered much about it; I gather this was an experiment that lasted a few days or weeks and was quickly abandoned. But what else? My short list included PL/1, Algol/W, Fortran, and Pascal. Fortran was already mentioned. I don't think PL/1 (or PL/I) could have fit on those machines. Pascal was really targeted towards teaching and would have required pretty extensive work to be usable. The big question mark in my mind is Algol/W; how well known was it at the time? Was any consideration for it made? Obviously, the decision to go with BCPL (as the basis for B, which beget C) was made and the rest is history. But I'm really curious about how, in the research culture at the time, information about new programming languages made its way through the community. - Dan C. ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-09 3:46 [TUHS] " Dan Cross @ 2025-03-09 6:14 ` George Michaelson 2025-03-09 12:29 ` Clem Cole ` (2 subsequent siblings) 3 siblings, 0 replies; 68+ messages in thread From: George Michaelson @ 2025-03-09 6:14 UTC (permalink / raw) To: Dan Cross; +Cc: TUHS [-- Attachment #1: Type: text/plain, Size: 1498 bytes --] Bliss. After all, DEC stuck to it either Bliss 32. On Sun, 9 Mar 2025, 1:47 pm Dan Cross, <crossd@gmail.com> wrote: > As I mentioned in the discussion about C, it's easy to look back with > a modern perspective and cast aspersions on C. But this got me > thinking, what would possible alternatives have been? In the context > of the very late 1960s heading into the early 70s, and given the > constraints of the PDP-7 and early PDP-11s, what languages would one > consider for implementing a system like early Unix? Dennis's history > paper mentioned a very short-lived effort at Fortran, and I asked > about that a few years ago, but no one really remembered much about > it; I gather this was an experiment that lasted a few days or weeks > and was quickly abandoned. But what else? > > My short list included PL/1, Algol/W, Fortran, and Pascal. Fortran was > already mentioned. I don't think PL/1 (or PL/I) could have fit on > those machines. Pascal was really targeted towards teaching and would > have required pretty extensive work to be usable. The big question > mark in my mind is Algol/W; how well known was it at the time? Was any > consideration for it made? > > Obviously, the decision to go with BCPL (as the basis for B, which > beget C) was made and the rest is history. But I'm really curious > about how, in the research culture at the time, information about new > programming languages made its way through the community. > > - Dan C. > [-- Attachment #2: Type: text/html, Size: 1842 bytes --] ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-09 3:46 [TUHS] " Dan Cross 2025-03-09 6:14 ` [TUHS] " George Michaelson @ 2025-03-09 12:29 ` Clem Cole 2025-03-09 13:18 ` G. Branden Robinson 2025-03-09 20:13 ` John Levine 2025-03-10 1:31 ` Bakul Shah via TUHS 3 siblings, 1 reply; 68+ messages in thread From: Clem Cole @ 2025-03-09 12:29 UTC (permalink / raw) To: Dan Cross; +Cc: TUHS [-- Attachment #1: Type: text/plain, Size: 1412 bytes --] ESPOL was basically first, with BCPL, PL/360, and, as George mentioned, BLISS showing up soon thereafter. On Sat, Mar 8, 2025 at 10:47 PM Dan Cross <crossd@gmail.com> wrote: > The big question mark in my mind is Algol/W; how well known was it at the > time? Any 360 shop, particularly if it was targeted for teaching students, would likely have had Wirth's compiler. Remember, as BCPL was to CPL, PL/360 was to Algol-W. Unlike BCPL, I don't know of any port of PL/360 outside of the IBM world. Algol-W would later be implemented in C, but that was later after Wirth tried again with Pascal. > Was any consideration for it made? > Only Ken can answer that. My guess is that Algol-W would have failed for the same reasons Pascal ultimately failed. It really was directed at students and lacked many of the tools C had. Many of the issues exposed in Brian's treatise *"Why is Pascal not my favorite programming language"* also apply to Algol-W. At the time, BLISS had the advantage of the first "Green Book" style optimizer, so in comparison to the original B and later C compilers, their code generators were almost toys. I believe that the killer for BLISS was DEC's choice to charge $5K per/cpu and to few places were willing to pay it. But as Paul points out BLISS was word-oriented, which, from a technical point of view, made it more difficult to use than C. ᐧ [-- Attachment #2: Type: text/html, Size: 3609 bytes --] ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-09 12:29 ` Clem Cole @ 2025-03-09 13:18 ` G. Branden Robinson 2025-03-09 17:29 ` Clem Cole 0 siblings, 1 reply; 68+ messages in thread From: G. Branden Robinson @ 2025-03-09 13:18 UTC (permalink / raw) To: TUHS [-- Attachment #1: Type: text/plain, Size: 3045 bytes --] At 2025-03-09T08:29:43-0400, Clem Cole wrote: > On Sat, Mar 8, 2025 at 10:47 PM Dan Cross <crossd@gmail.com> wrote: > > Was any consideration for it made? > > > Only Ken can answer that. My guess is that Algol-W would have failed > for the same reasons Pascal ultimately failed. It really was > directed at students and lacked many of the tools C had. Many of the > issues exposed in Brian's treatise *"Why is Pascal not my favorite > programming language"* also apply to Algol-W. I think it's worth noting that, as I undertand it from having read the paper, old Pascal manuals, and ISO 7185 (and, a long time ago, experience with Borland Turbo Pascal), most or all of the defects Kernighan pointed out were addressed by vendored versions of Pascal and ultimately by its ISO standard form. I think even UCSD Pascal had extensions, though I don't recall what they were. My grasp of the chronology is poor, though, and I'd concede that Wirth's Pascal of his 1973 memorandum wears most or all of the mud Kernighan threw at it. For the most part, solving the problems Kerngihan observed did not require doing violence to the language (in other words, they could be solved with extensions rather than by altering the semantics of valid 1973 Pascal syntax). Maybe this is what it means to have been "directed at students"--that easy wins in terms of language improvement were not implemented because covering them topically in a semester-long university course would not have been practical. If so, that may make the tragedy of Pascal greater, not smaller. Though even that doesn't explain why Wirth didn't spec Pascal functions to admit polymorphism (perhaps optionally) in array length. That's an essential property for all sorts of work, even that undertaken by students. (Say you want them to write a function that multiplies matrices. You shouldn't have to specialize the function by matrix dimensions. The obvious pinch point for a Unix programmer is massive inconvenience if you want to handle variable-length strings.) Perusing its manual some months ago, it occurred to me that if someone had had the foresight to implement the language core of Turbo Pascal 7.0, ignoring the libraries/"modules" entirely, and omitting the crap necessary to work with the x86 segmented memory model, I don't think Kernighan would have had much, if anything, to complain about. And, in my opinion, we'd be living in a better timeline. But I guess Pascal just didn't get good enough, soon enough. And I wonder how big such a compiler would be, even if coded competently. Chronology bedevils us in another way. A _lot_ of C language features its advocates are proud of were not present in 1973 or even when Kernighan wrote CSTR #100 around 1980. It is an error to substitute the ANSI C of 1989 for the C that actually existed at the time when asking who'd win in a fight between C and Pascal taking place in, say, 1977. https://gunkies.org/wiki/Typesetter_C Regards, Branden [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-09 13:18 ` G. Branden Robinson @ 2025-03-09 17:29 ` Clem Cole 2025-03-09 19:06 ` Ken Thompson 2025-03-09 19:41 ` G. Branden Robinson 0 siblings, 2 replies; 68+ messages in thread From: Clem Cole @ 2025-03-09 17:29 UTC (permalink / raw) To: G. Branden Robinson; +Cc: TUHS [-- Attachment #1: Type: text/plain, Size: 10132 bytes --] On Sun, Mar 9, 2025 at 9:18 AM G. Branden Robinson < g.branden.robinson@gmail.com> wrote: > At 2025-03-09T08:29:43-0400, Clem Cole wrote: > > On Sat, Mar 8, 2025 at 10:47 PM Dan Cross <crossd@gmail.com> wrote: > > > Was any consideration for it made? > > > > > Only Ken can answer that. My guess is that Algol-W would have failed > > for the same reasons Pascal ultimately failed. It really was > > directed at students and lacked many of the tools C had. Many of the > > issues exposed in Brian's treatise *"Why is Pascal not my favorite > > programming language"* also apply to Algol-W. > > I think it's worth noting that, as I undertand it from having read the > paper, old Pascal manuals, and ISO 7185 (and, a long time ago, > experience with Borland Turbo Pascal), most or all of the defects > Kernighan pointed out were addressed by vendored versions of Pascal and > ultimately by its ISO standard form. I think even UCSD Pascal had > extensions, though I don't recall what they were. > Branden — respectfully, if you download the standard https://archive.org/details/iso-iec-7185-1990-Pascal or look at versions that have been converted to HTML such as https://wiki.freepascal.org/Standard_Pascal, that statement is a tad hollow. Sadly, that is the issue with Pascal. The fundamental flaws of the core Pascal language remained as described in Brian’s paper as: 1. Since the size of an array is part of its type, it is not possible to write general-purpose routines, that is, to deal with arrays of different sizes. In particular, string handling is very difficult. 2. The lack of static variables, initialization, and a way to communicate non-hierarchically combine to destroy the ‘‘locality’’ of a program — variables require much more scope than they ought to. 3. The language's one-pass nature forces procedures and functions to be presented in an unnatural order; the enforced separation of various declarations scatters program components that logically belong together. 4. The lack of separate compilation impedes the development of large programs and makes using external libraries impossible. 5. The order of logical expression evaluation cannot be controlled, which leads to convoluted code and extraneous variables. 6. The case statement is emasculated because there is no default clause. 7. The standard I/O is defective. There is no sensible provision for dealing with files or program arguments as part of the standard language and no extension mechanism. 8. The language lacks most of the tools needed for assembling large programs, most notably file inclusion. 9. There is no escape. > My grasp of the chronology is poor, though, and I'd concede that Wirth's > Pascal of his 1973 memorandum wears most or all of the mud Kernighan > threw at it. For the most part, solving the problems Kerngihan observed > did not require doing violence to the language (in other words, they > could be solved with extensions rather than by altering the semantics of > valid 1973 Pascal syntax). > You >>are<< correct that many (not all) of the defects Brian and Dave ran into when updating/rewriting the Software Tools book from FORTRAN (Ratfor) to Pascal >>could<< have been fixed. The core issue with Pascal is that if an implementation did add an extension,* every implementation did it differently.* Now, the truth is that having different implementations from different vendors was not unusual. The whole reason ASA developed FORTRAN-66, which begat the many versions that followed [I believe FORTRAN-2018 is the last verified version, but I'm told by Dr. FORTRAN [Steve Lionel] that they are preparing an updated draft. BASIC had it in spades. In fact, at one of the early 'Hatfield/McCoy" parties between my friends at HP and Tektronix, we count 14 different flavors of "HP BASIC" and 6 different flavors of "Tek Pascal." > > Maybe this is what it means to have been "directed at students"--that > easy wins in terms of language improvement were not implemented because > covering them topically in a semester-long university course would not > have been practical. If so, that may make the tragedy of Pascal > greater, not smaller. > History. Wirth was teaching at Stanford when Algol-X was proposed. In the late 1960s, the International Federation for Information Processing (IFIP) held the International responsibility for the definition of the programming language ALGOL 60, chartered IFIP Working Group 2.1 to develop a replacement for the language which had been identified, notably the lack of a standardized string subsystem. This effort was dubbed ALGOL X. You can use an internet search to find several of them, but one of the proposals was submitted by Niklaus Wirth and Tony Hoare. When their proposal was not accepted, the language ALGOL 68 would be developed under these auspices. The committee decided that the Wirth/Hoare proposal was an insufficient advance over ALGOL 60, and the proposal was published as a contribution to the development of ALGOL in CACM after making slight modifications to the language. Wirth eventually decided to develop his proposal and created an implementation targeting the IBM System/360 at Stanford University. He called the new language Algol-W [used in many universities, and I used it at CMU, and I have friends that used it at Cornell and Princeton]. At the time, Wirth's original target was a tool to teach his students at Stanford. It was not a "production quality" compiler in the sense of IBM's FORTRAN-H, which was considered the "best" production compiler at the time. Also, remember the whole assembler/compiled code was hardly a settled debate. Wulf's findings showed BLISS was as good as the best PDP-10/PDP-11 programmers, which was still a few years in the future. As I've said elsewhere, it took enough students trained in the ideas from the Green Book a few years to get into the world to start to develop the optimizers we now expect as the norm. > > Though even that doesn't explain why Wirth didn't spec Pascal functions > to admit polymorphism (perhaps optionally) in array length. That's an > essential property for all sorts of work, even that undertaken by > students. (Say you want them to write a function that multiplies > matrices. You shouldn't have to specialize the function by matrix > dimensions. The obvious pinch point for a Unix programmer is massive > inconvenience if you want to handle variable-length strings.) > Again, it was not considered an issue for what they were trying to solve. Read the IFPS meeting notes. > > Perusing its manual some months ago, it occurred to me that if someone > had had the foresight to implement the language core of Turbo Pascal > 7.0, ignoring the libraries/"modules" entirely, and omitting the crap > necessary to work with the x86 segmented memory model, I don't think > Kernighan would have had much, if anything, to complain about. And, in > my opinion, we'd be living in a better timeline. > Turbo Pascal was a flavor of Pascal that came much later. At the time, UCB Pascal and UCSD Pascal were the two popular implementations for students, and commercial folks used Whitesmiths and, later, OMSI. The first three were the compilers Brian and PJ used (I believe all were running a V7 Unix, but I'm not positive about the target OS). FWIW: today's popular Pascal is Free Pascal (freepascal.org), and it accepts all of the syntax of Turbo, Object Pascal, and Delphi as input. But it was too late. > > But I guess Pascal just didn't get good enough, soon enough. > No, it was not agreed upon. Everyone developing a Pascal implementation was pushing their flavor (sound familiar). Turbo "won" when they targeted DOS, which, at the time, was being ignored by the traditional "professional" programmers (DOS was too much of a "toy" to be serious. - Minicomputers were the bread and butter). When PharLap created an OS extension that allowed for a real 32-bit C for the 386, UNIX and C had already taken the mantel, and Pascal was losing favor in the DOS world. > > And I wonder how big such a compiler would be, even if coded > competently. > Look at OMSI, which primarily targeted the PDP-11. It has many of these extensions [it basically started as one of the Tek Pascal's, BTW. Jon and I worked with some folks who developed it.] > > Chronology bedevils us in another way. A _lot_ of C language features > its advocates are proud of were not present in 1973 or even when > Kernighan wrote CSTR #100 around 1980. Please be careful here. The point is that in 1980, Pascal and C, as described by Brain, C did not have the issues I listed above, but the popular Pascal implementations being used in the wild did. > It is an error to substitute the ANSI C of 1989 for the C that actually > existed at the time when asking > who'd win in a fight between C and Pascal taking place in, say, 1977. > I don't since I lived it. > > https://gunkies.org/wiki/Typesetter_C Need to work with Noel to update that page -- that name was because it came with the original ditroff - which used libS.a to replace Lesk's portable I/O library. It was less an issue of new compiler language features and more the requirement for a new I/O library. Remember, C and BLISS, as examples are defined without an I/O library in their origin stories. They both use the local OS's IO interface. C does not formally get an I/O library until Typesetter C and White Book. Simply, until C moved to the Honeywell and 360 nd people started to "port" code, that Lesk started to codify an IO library that could be used regardless of the local OS. Look at the documentation in V6. You'll see some interesting like fd = -1 and other artifacts that Mike had in so that earlier code would recompile and relink. With typesetter C, Dennis forced a small rewrite of your code to use libS.a. As I said, I lived this whole war. Crumudgingly yours, Clem ᐧ [-- Attachment #2: Type: text/html, Size: 17636 bytes --] ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-09 17:29 ` Clem Cole @ 2025-03-09 19:06 ` Ken Thompson 2025-03-09 19:41 ` G. Branden Robinson 1 sibling, 0 replies; 68+ messages in thread From: Ken Thompson @ 2025-03-09 19:06 UTC (permalink / raw) To: Clem Cole; +Cc: TUHS [-- Attachment #1: Type: text/plain, Size: 11150 bytes --] how about smalgol? it was an algol-like language with just int and float types. i dont know its history, but it came out of berkeley near when Niklaus Wirth was there. it compiled for the ibm 7094 in normal batch processing fashion. i converted it to a jit into memory in order to skip the loading phase. i used it for a lot of my fun-work. (1965-66) mainframe time, then, was a big factor in the computing process. smalgol could compile, load, and run in about 1 cpu-second. smalgol was all ibm-cards, but it was on my mind through the bcpl to b to nb phases. i would use the modern word "influencer." On Sun, Mar 9, 2025 at 10:37 AM Clem Cole <clemc@ccc.com> wrote: > > > On Sun, Mar 9, 2025 at 9:18 AM G. Branden Robinson < > g.branden.robinson@gmail.com> wrote: > >> At 2025-03-09T08:29:43-0400, Clem Cole wrote: >> > On Sat, Mar 8, 2025 at 10:47 PM Dan Cross <crossd@gmail.com> wrote: >> > > Was any consideration for it made? >> > > >> > Only Ken can answer that. My guess is that Algol-W would have failed >> > for the same reasons Pascal ultimately failed. It really was >> > directed at students and lacked many of the tools C had. Many of the >> > issues exposed in Brian's treatise *"Why is Pascal not my favorite >> > programming language"* also apply to Algol-W. >> >> I think it's worth noting that, as I undertand it from having read the >> paper, old Pascal manuals, and ISO 7185 (and, a long time ago, >> experience with Borland Turbo Pascal), most or all of the defects >> Kernighan pointed out were addressed by vendored versions of Pascal and >> ultimately by its ISO standard form. I think even UCSD Pascal had >> extensions, though I don't recall what they were. >> > Branden — respectfully, if you download the standard > https://archive.org/details/iso-iec-7185-1990-Pascal or look at versions > that have been converted to HTML such as > https://wiki.freepascal.org/Standard_Pascal, that statement is a tad > hollow. Sadly, that is the issue with Pascal. The fundamental flaws of > the core Pascal language remained as described in Brian’s paper as: > > 1. Since the size of an array is part of its type, it is not possible to > write general-purpose routines, that is, to deal with arrays of different > sizes. In particular, string handling is very difficult. > > 2. The lack of static variables, initialization, and a way to communicate > non-hierarchically combine to destroy the ‘‘locality’’ of a program — > variables require much more scope than they ought to. > > 3. The language's one-pass nature forces procedures and functions to be > presented in an unnatural order; the enforced separation of various > declarations scatters program components that logically belong together. > > 4. The lack of separate compilation impedes the development of large > programs and makes using external libraries impossible. > > 5. The order of logical expression evaluation cannot be controlled, which > leads to convoluted code and extraneous variables. > > 6. The case statement is emasculated because there is no default clause. > > 7. The standard I/O is defective. There is no sensible provision for > dealing with files or program arguments as part of the standard language > and no extension mechanism. > > 8. The language lacks most of the tools needed for assembling large > programs, most notably file inclusion. > > 9. There is no escape. > > > >> My grasp of the chronology is poor, though, and I'd concede that Wirth's >> Pascal of his 1973 memorandum wears most or all of the mud Kernighan >> threw at it. For the most part, solving the problems Kerngihan observed >> did not require doing violence to the language (in other words, they >> could be solved with extensions rather than by altering the semantics of >> valid 1973 Pascal syntax). >> > You >>are<< correct that many (not all) of the defects Brian and Dave ran > into when updating/rewriting the Software Tools book from FORTRAN (Ratfor) > to Pascal >>could<< have been fixed. The core issue with Pascal is that > if an implementation did add an extension,* every implementation did it > differently.* > > Now, the truth is that having different implementations from different > vendors was not unusual. The whole reason ASA developed FORTRAN-66, which > begat the many versions that followed [I believe FORTRAN-2018 is the last > verified version, but I'm told by Dr. FORTRAN [Steve Lionel] that they are > preparing an updated draft. BASIC had it in spades. In fact, at one of the > early 'Hatfield/McCoy" parties between my friends at HP and Tektronix, we > count 14 different flavors of "HP BASIC" and 6 different flavors of "Tek > Pascal." > >> >> Maybe this is what it means to have been "directed at students"--that >> easy wins in terms of language improvement were not implemented because >> covering them topically in a semester-long university course would not >> have been practical. If so, that may make the tragedy of Pascal >> greater, not smaller. >> > History. Wirth was teaching at Stanford when Algol-X was proposed. In > the late 1960s, the International Federation for Information Processing > (IFIP) held the International responsibility for the definition of the > programming language ALGOL 60, chartered IFIP Working Group 2.1 to develop > a replacement for the language which had been identified, notably the lack > of a standardized string subsystem. This effort was dubbed ALGOL X. You > can use an internet search to find several of them, but one of the > proposals was submitted by Niklaus Wirth and Tony Hoare. When their > proposal was not accepted, the language ALGOL 68 would be developed under > these auspices. > > The committee decided that the Wirth/Hoare proposal was an insufficient > advance over ALGOL 60, and the proposal was published as a contribution to > the development of ALGOL in CACM after making slight modifications to the > language. Wirth eventually decided to develop his proposal and created an > implementation targeting the IBM System/360 at Stanford University. He > called the new language Algol-W [used in many universities, and I used it > at CMU, and I have friends that used it at Cornell and Princeton]. > > At the time, Wirth's original target was a tool to teach his students at > Stanford. It was not a "production quality" compiler in the sense of IBM's > FORTRAN-H, which was considered the "best" production compiler at the time. > Also, remember the whole assembler/compiled code was hardly a settled > debate. Wulf's findings showed BLISS was as good as the best PDP-10/PDP-11 > programmers, which was still a few years in the future. As I've said > elsewhere, it took enough students trained in the ideas from the Green Book > a few years to get into the world to start to develop the optimizers we now > expect as the norm. > >> >> Though even that doesn't explain why Wirth didn't spec Pascal functions >> to admit polymorphism (perhaps optionally) in array length. That's an >> essential property for all sorts of work, even that undertaken by >> students. (Say you want them to write a function that multiplies >> matrices. You shouldn't have to specialize the function by matrix >> dimensions. The obvious pinch point for a Unix programmer is massive >> inconvenience if you want to handle variable-length strings.) >> > Again, it was not considered an issue for what they were trying to solve. > Read the IFPS meeting notes. > >> >> Perusing its manual some months ago, it occurred to me that if someone >> had had the foresight to implement the language core of Turbo Pascal >> 7.0, ignoring the libraries/"modules" entirely, and omitting the crap >> necessary to work with the x86 segmented memory model, I don't think >> Kernighan would have had much, if anything, to complain about. And, in >> my opinion, we'd be living in a better timeline. >> > Turbo Pascal was a flavor of Pascal that came much later. At the time, UCB > Pascal and UCSD Pascal were the two popular implementations for students, > and commercial folks used Whitesmiths and, later, OMSI. The first three > were the compilers Brian and PJ used (I believe all were running a V7 Unix, > but I'm not positive about the target OS). > > FWIW: today's popular Pascal is Free Pascal (freepascal.org), and it > accepts all of the syntax of Turbo, Object Pascal, and Delphi as input. > But it was too late. > >> >> But I guess Pascal just didn't get good enough, soon enough. >> > No, it was not agreed upon. Everyone developing a Pascal implementation > was pushing their flavor (sound familiar). Turbo "won" when they targeted > DOS, which, at the time, was being ignored by the traditional > "professional" programmers (DOS was too much of a "toy" to be serious. - > Minicomputers were the bread and butter). When PharLap created an OS > extension that allowed for a real 32-bit C for the 386, UNIX and C had > already taken the mantel, and Pascal was losing favor in the DOS world. > >> >> And I wonder how big such a compiler would be, even if coded >> competently. >> > Look at OMSI, which primarily targeted the PDP-11. It has many of these > extensions [it basically started as one of the Tek Pascal's, BTW. Jon > and I worked with some folks who developed it.] > >> >> Chronology bedevils us in another way. A _lot_ of C language features >> its advocates are proud of were not present in 1973 or even when >> Kernighan wrote CSTR #100 around 1980. > > Please be careful here. The point is that in 1980, Pascal and C, as > described by Brain, C did not have the issues I listed above, but the > popular Pascal implementations being used in the wild did. > > > >> It is an error to substitute the ANSI C of 1989 for the C that actually >> existed at the time when asking >> who'd win in a fight between C and Pascal taking place in, say, 1977. >> > I don't since I lived it. > >> >> https://gunkies.org/wiki/Typesetter_C > > Need to work with Noel to update that page -- that name was because it > came with the original ditroff - which used libS.a to replace Lesk's > portable I/O library. It was less an issue of new compiler language > features and more the requirement for a new I/O library. Remember, C and > BLISS, as examples are defined without an I/O library in their origin > stories. They both use the local OS's IO interface. C does not formally > get an I/O library until Typesetter C and White Book. Simply, until C > moved to the Honeywell and 360 nd people started to "port" code, that Lesk > started to codify an IO library that could be used regardless of the local > OS. Look at the documentation in V6. You'll see some interesting like fd > = -1 and other artifacts that Mike had in so that earlier code would > recompile and relink. With typesetter C, Dennis forced a small rewrite of > your code to use libS.a. > > As I said, I lived this whole war. > Crumudgingly yours, > Clem > ᐧ > [-- Attachment #2: Type: text/html, Size: 18695 bytes --] ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-09 17:29 ` Clem Cole 2025-03-09 19:06 ` Ken Thompson @ 2025-03-09 19:41 ` G. Branden Robinson 2025-03-09 19:57 ` Bakul Shah via TUHS ` (2 more replies) 1 sibling, 3 replies; 68+ messages in thread From: G. Branden Robinson @ 2025-03-09 19:41 UTC (permalink / raw) To: TUHS [-- Attachment #1: Type: text/plain, Size: 20373 bytes --] Hi Clem, Thanks for you detailed response. I appreciate getting perspectives from people who fought in the wars I'm too young to remember; I visit the memorials and try to imagine what things were like. At 2025-03-09T13:29:55-0400, Clem Cole wrote: > On Sun, Mar 9, 2025 at 9:18 AM G. Branden Robinson < > g.branden.robinson@gmail.com> wrote: > > At 2025-03-09T08:29:43-0400, Clem Cole wrote: > > > On Sat, Mar 8, 2025 at 10:47 PM Dan Cross <crossd@gmail.com> wrote: > > > > Was any consideration for it made? > > > Only Ken can answer that. My guess is that Algol-W would have > > > failed for the same reasons Pascal ultimately failed. It really > > > was directed at students and lacked many of the tools C had. Many > > > of the issues exposed in Brian's treatise *"Why is Pascal not my > > > favorite programming language"* also apply to Algol-W. > > > > I think it's worth noting that, as I undertand it from having read > > the paper, old Pascal manuals, and ISO 7185 (and, a long time ago, > > experience with Borland Turbo Pascal), most or all of the defects > > Kernighan pointed out were addressed by vendored versions of Pascal > > and ultimately by its ISO standard form. I think even UCSD Pascal > > had extensions, though I don't recall what they were. > > > Branden — respectfully, if you download the standard > https://archive.org/details/iso-iec-7185-1990-Pascal I keep a copy on my tablet! Alongside two Free Pascal and the Turbo Pascal 7.0 manuals. I didn't have to fight in the trenches using Pascal for very long (and when I did, it was with Borland's generously expanded dialects, a few years apart). > or look at versions that have been converted to HTML such as > https://wiki.freepascal.org/Standard_Pascal, that statement is a tad > hollow. Sadly, that is the issue with Pascal. Okay. I'll take it as homework to double-check how feedble ISO Pascal is compared to the version critiqued by Kernighan. Hmm, I can already see that I might have confused ISO Standard Pascal (ISO 7185) with ISO Extended Pascal (ISO 10206). Both standards, but only one named "Standard". I apologize for my error. > The fundamental flaws of the core Pascal language remained as > described in Brian’s paper as: > > 1. Since the size of an array is part of its type, it is not possible > to write general-purpose routines, that is, to deal with arrays of > different sizes. In particular, string handling is very difficult. Yeah. That's a brutal flaw that every defender of Wirth Pascal has to concede at the risk of not being taken seriously. > 2. The lack of static variables, initialization, and a way to > communicate non-hierarchically combine to destroy the ‘‘locality’’ of > a program — variables require much more scope than they ought to. That's also a flaw, but C doesn't distinguish itself strongly here; `static` function linkage should have been the default. We should have had a `public` keyword (or synonym) instead. (Rust, to my great surprise, seems to have convinced people that `const` default is good too--hence `let mut`--and it is, for many reasons including concurrency. Even my beloved Ada was not so forward-looking.) > 3. The language's one-pass nature forces procedures and functions to > be presented in an unnatural order; the enforced separation of various > declarations scatters program components that logically belong > together. But that was true of C for a long time as well; as I understand it, one-pass C compilers were important enough that intermixed statements and declarations were allowed into the standard only in C99. That's a long time after CSTR #100. And for me, writing to minimize forward declarations _is_ the natural order. Just as in documentation, we want to avoid employing concepts before we've introduced them. (If your `main()` is either really short or strictly a sequence of calls to functions returning `void`, such that it reads like a procedural checklist, only then would I tolerate it at the top of the source file.) > 4. The lack of separate compilation impedes the development of large > programs and makes using external libraries impossible. This one's about as brutal as point 1. It requires concession. Modularity is critical. > 5. The order of logical expression evaluation cannot be controlled, > which leads to convoluted code and extraneous variables. Some of this blows back onto C. Yes, short-circuit logical evaluation operators are desirable, but apart from that the order of expression evaluation in C (a) is frequenly not specified so that compilers can generate fast code for the hardware; or (b) demands that the programmer remember something like 15 levels of operator precedence, which is savage cruelty in my opinion. Here I am recently correcting a dopey mistake of mine along those lines. https://git.savannah.gnu.org/cgit/groff.git/commit/?id=a0171c9dc12daa8e70b9178bfac63aa11745110b > 6. The case statement is emasculated because there is no default > clause. I'll freely grant this one, too, and go still farther and say that both Pascal _and_ C should have required Haskell-style exhaustive coverage of the controlling variable's domain. C's support for sum types was (and is) bad, and Pascal's started down the right road but then gave it up partway, to amplify Kernighan's point. > 7. The standard I/O is defective. There is no sensible provision for > dealing with files or program arguments as part of the standard language > and no extension mechanism. To my horror, when learning Java I discovered that it had managed to discard the basic competence of console/terminal I/O supported by C's stdio library. I don't dispute that C shone here. I think Korn and Vo have solid critiques of other aspects of stdio, and I find the irregularity of function names, argument order, and some aspects of behavior (such as whether an output function appends a newline or not) annoying, but I would not dispute that it's easier than in most languages I've dealt with to get a simple "conversational" terminal application stood up with C. Yes, you often want a "serious" UI in curses or a windowing system later (or none at all, relying on argv[] and the standard I/O streams to do everything as in the filter model), but that's no reason to fumble the ball on simple Teletype-style I/O. Yet too many languages did. Still, scanf() was a bad idea, or at least overapplied, and should not be taught to students as a tool for interactive I/O handling (as it was to me--did anyone else have this misfortune?). For that, a simple lexical analyzer is necessary because humans produce undisciplined input. It's never too early to teach a beginner how to write a finite state machine. > 8. The language lacks most of the tools needed for assembling large > programs, most notably file inclusion. Once you have separate compilation, this seems mostly like either (a) a linker problem or (b) a problem better solved by a real macro language like m4. The C preprocessor was merely adequate when it could have been brilliant. In case anyone feels a dark premonition of where that idea leads: yes, I'm saying the CSRC should have given us Autoconf instead of the C preprocessor. >:-) If they had, it would be far less hated. > 9. There is no escape. And that's why everybody added inline assembly and some added foreign function interfaces. > You >>are<< correct that many (not all) of the defects Brian and Dave > ran into when updating/rewriting the Software Tools book from FORTRAN > (Ratfor) to Pascal >>could<< have been fixed. The core issue with > Pascal is that if an implementation did add an extension,* every > implementation did it differently.* > > Now, the truth is that having different implementations from different > vendors was not unusual. The whole reason ASA developed FORTRAN-66, > which begat the many versions that followed [I believe FORTRAN-2018 is > the last verified version, but I'm told by Dr. FORTRAN [Steve Lionel] > that they are preparing an updated draft. BASIC had it in spades. In > fact, at one of the early 'Hatfield/McCoy" parties between my friends > at HP and Tektronix, we count 14 different flavors of "HP BASIC" and 6 > different flavors of "Tek Pascal." I guess standardization of Pascal started too late; but both C and C++ took a long time to get to their initial standards too. What do you think accounts for C and C++'s greater success, in the specific sense that vendor extensions didn't cripple the language's development? What force kept these languages better governed? > > Maybe this is what it means to have been "directed at > > students"--that easy wins in terms of language improvement were not > > implemented because covering them topically in a semester-long > > university course would not have been practical. If so, that may > > make the tragedy of Pascal greater, not smaller. > > > History. Wirth was teaching at Stanford when Algol-X was proposed. In > the late 1960s, the International Federation for Information > Processing (IFIP) held the International responsibility for the > definition of the programming language ALGOL 60, chartered IFIP > Working Group 2.1 to develop a replacement for the language which had > been identified, notably the lack of a standardized string subsystem. > This effort was dubbed ALGOL X. You can use an internet search to find > several of them, but one of the proposals was submitted by Niklaus > Wirth and Tony Hoare. When their proposal was not accepted, the > language ALGOL 68 would be developed under these auspices. I've read Lindsey's "A history of ALGOL 68" in HOPL 2 (1996). Intriguing stuff. I have no strong opinions about any of it, probably because no one's either forced me to write in ALGOL 68, nor forbidden me from doing so. I do admire its nearly universal loop structure: [ for index ] [ from first ] [ by increment ] [ to last ] [ while condition ] do statements od "Nearly" because it's not obvious to me how you'd simulate C's do-while, which is underrated and under-taught. And in case anyone's not aware of it, you can play with Algol 68 today. https://www.theregister.com/2025/01/07/algol_68_comes_to_gcc/ > The committee decided that the Wirth/Hoare proposal was an > insufficient advance over ALGOL 60, and the proposal was published as > a contribution to the development of ALGOL in CACM after making slight > modifications to the language. Wirth eventually decided to develop > his proposal and created an implementation targeting the IBM > System/360 at Stanford University. He called the new language Algol-W > [used in many universities, and I used it at CMU, and I have friends > that used it at Cornell and Princeton]. > > At the time, Wirth's original target was a tool to teach his students > at Stanford. It was not a "production quality" compiler in the sense > of IBM's FORTRAN-H, which was considered the "best" production > compiler at the time. Also, remember the whole assembler/compiled > code was hardly a settled debate. That was still a live issue when I was learning, but back then (on home 8-bit micros), you had to shell out money to get anything but the BASIC interpreter that was stored in ROM. We penurious kids, if pressed, would hand-assemble code to and poke it into memory to escape the shackles of the vendor's languid BASIC interpreter (usually under license from Microsoft). Made a lot of mistakes and froze the machine that way. No illegal instruction traps and no handler for such traps if we'd had 'em. Just push reset and hope you'd saved your work. "a.out?" https://www.nokia.com/bell-labs/about/dennis-m-ritchie/odd.html > Wulf's findings showed BLISS was as good as the best PDP-10/PDP-11 > programmers, which was still a few years in the future. As I've said > elsewhere, it took enough students trained in the ideas from the Green > Book a few years to get into the world to start to develop the > optimizers we now expect as the norm. I'd like to talk to some of that cohort about Ada. > > Though even that doesn't explain why Wirth didn't spec Pascal > > functions to admit polymorphism (perhaps optionally) in array > > length. That's an essential property for all sorts of work, even > > that undertaken by students. (Say you want them to write a function > > that multiplies matrices. You shouldn't have to specialize the > > function by matrix dimensions. The obvious pinch point for a Unix > > programmer is massive inconvenience if you want to handle > > variable-length strings.) > > > Again, it was not considered an issue for what they were trying to > solve. Read the IFPS meeting notes. That shocks me, but okay. I realize I'm probably abusing the term "polymorphism" here, since that's usually applied to distinguishable data types. It bluescreens my brain to think that "iterate along this vector of identically typed elements until reaching a known terminating value" was regarded as a technique with any hint of the exotic. What am I missing? > > Perusing its manual some months ago, it occurred to me that if > > someone had had the foresight to implement the language core of > > Turbo Pascal 7.0, ignoring the libraries/"modules" entirely, and > > omitting the crap necessary to work with the x86 segmented memory > > model, I don't think Kernighan would have had much, if anything, to > > complain about. And, in my opinion, we'd be living in a better > > timeline. > > > Turbo Pascal was a flavor of Pascal that came much later. Yes, TP 1.0 was late 1983; Wirth's spec paper was 1973, UCSD Pascal 1977, and I can't find a date for UCB Pascal, but... > At the time, UCB Pascal ...Thompson had a hand in writing that one, didn't he? During his sabbatical that spawned the CSRG? If so, that was 1975. > and UCSD Pascal were the two popular implementations for students, and > commercial folks used Whitesmiths and, later, OMSI. The first three > were the compilers Brian and PJ used (I believe all were running a V7 > Unix, but I'm not positive about the target OS). > > FWIW: today's popular Pascal is Free Pascal (freepascal.org), and it > accepts all of the syntax of Turbo, Object Pascal, and Delphi as > input. But it was too late. It's still a highly active project, and one I keep an eye on. On the one hand, ports to RISC-V and WASM, and on the other, fixes to its m68k backend and TP-style text-mode IDE have all seen commits in the past month. They also seem to take their documentation seriously, a significant sign of health in my view. I have no expectation that it will displace C, but its developers have my admiration for pushing forward. Maybe that's because, in maintaining a typesetting system that _isn't_ TeX, I recognize potentially kindred spirits. > > But I guess Pascal just didn't get good enough, soon enough. > > > No, it was not agreed upon. Everyone developing a Pascal > implementation was pushing their flavor (sound familiar). Turbo "won" > when they targeted DOS, which, at the time, was being ignored by the > traditional "professional" programmers (DOS was too much of a "toy" to > be serious. - Well, the professionals weren't wrong. MS-DOS was a crap OS on a crap ISA. They were both market placeholders. But we don't work, or live, in a meritocracy. As ever, the surest route to the head of the line is to be deposited there at birth by your ancestor. > Minicomputers were the bread and butter). When PharLap created an OS > extension that allowed for a real 32-bit C for the 386, UNIX and C had > already taken the mantel, and Pascal was losing favor in the DOS > world. > > > And I wonder how big such a compiler would be, even if coded > > competently. > > > Look at OMSI, which primarily targeted the PDP-11. It has many of > these extensions [it basically started as one of the Tek Pascal's, > BTW. Jon and I worked with some folks who developed it.] Oof, for RT-11. I've booted RSX-11--once--on my PiDP-11. It was a jarring experience. Booting 2.11BSD was headily nostalgic, and took me _way_ back. I haven't seen a boot sequence like that in a long time. > > Chronology bedevils us in another way. A _lot_ of C language > > features its advocates are proud of were not present in 1973 or even > > when Kernighan wrote CSTR #100 around 1980. > > Please be careful here. The point is that in 1980, Pascal and C, as > described by Brain, C did not have the issues I listed above, I can't completely agree with you here because as I understand the critique, C still has _some_ of them _today_. Often not as badly as in the past, and almost certainly not as bad as the Pascals of the day. > but the popular Pascal implementations being used in the wild did. > > > It is an error to substitute the ANSI C of 1989 for the C that > > actually existed at the time when asking who'd win in a fight > > between C and Pascal taking place in, say, 1977. > > I don't since I lived it. Yes, but I'm not always aiming at you personally. :) > > https://gunkies.org/wiki/Typesetter_C > > Need to work with Noel to update that page -- that name was because it > came with the original ditroff - which used libS.a to replace Lesk's > portable I/O library. I was (am) a bit confused because like you I thought "Typesetter C" was something else, something later, that was described in the 1-page article in the V7 manual "Recent Changes to C", which introduced (per its headings) "Structure assignment" and [an] "Enumeration type". _But_, that's dated November 15, 1978, which seems a tad early for Kernighan's device-independent troff work. "...in the spring of 1979, I set about to modify TROFF so that it would run henceforth without change on a variety of typesetters." (CSTR #97) London and Reiser's 1979 paper describing their group's port of Unix to the VAX-11 (I gather from other sources that the CSRC was upset with DEC and refused to do it) identifies barriers that the C of the day erected to portable programming. Most of them were addressed by ANSI C. I had thought that device-independent troff directly drove some changes to the C language (not just support libraries), but maybe I'm wrong. I have no idea how the Ritchie compiler or PCC evolved after Seventh Edition (1979). Apart from a couple of books (Hancock & Krieger, _C Primer Plus_, and _Notes on the Draft C Standard_, Tom Plum), I have no insight into 1980s C. The main thing I know about it is that if an implementation targeted x86, it added `near` and `far` keywords to accommodate segmented memory and/or DOS-style object file formats. I'd have learned C (or tried to) a lot younger if I could have afforded a compiler for it. Instead I had to wait for GCC. And a real computer. > It was less an issue of new compiler language features and more the > requirement for a new I/O library. Remember, C and BLISS, as examples > are defined without an I/O library in their origin stories. They both > use the local OS's IO interface. C does not formally get an I/O > library until Typesetter C and White Book. Simply, until C moved to > the Honeywell and 360 nd people started to "port" code, that Lesk > started to codify an IO library that could be used regardless of the > local OS. Look at the documentation in V6. You'll see some > interesting like fd = -1 and other artifacts that Mike had in so that > earlier code would recompile and relink. With typesetter C, Dennis > forced a small rewrite of your code to use libS.a. Well, you _could_ bypass it and use read() and write() directly. Say, in cat(1), the way Pike intended. ;-) > As I said, I lived this whole war. I appreciate hearing it and I don't mind being corrected (or challenged on my questionable taste). I'm a contrarian about C because triumphalism and other forms of sore winning are not good looks for engineers. Every time I blunder into Pascal-style pseudocode, I experience a pleasant jolt of recognition. Warmest regards, Branden [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-09 19:41 ` G. Branden Robinson @ 2025-03-09 19:57 ` Bakul Shah via TUHS 2025-03-09 22:47 ` Dave Horsfall 2025-03-09 22:58 ` Clem Cole 2 siblings, 0 replies; 68+ messages in thread From: Bakul Shah via TUHS @ 2025-03-09 19:57 UTC (permalink / raw) To: G. Branden Robinson; +Cc: TUHS On Mar 9, 2025, at 12:41 PM, G. Branden Robinson <g.branden.robinson@gmail.com> wrote: > > And in case anyone's not aware of it, you can play with Algol 68 today. > > https://www.theregister.com/2025/01/07/algol_68_comes_to_gcc/ a68 has been available for quite a while on Unix (FreeBSD): See https://www.freshports.org/lang/algol68g The Algol 68 Genie project preserves Algol 68 out of educational as well as scientific-historical interest, by making a modern, well-featured hybrid compiler-interpreter written from scratch, which ranks among the most complete Algol 68 implementations. It features arbitrary precision arithmetic, complex numbers, parallel processing, partial parameterization, and formatted transput, as well as support for curses, regular expressions, and sound. ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-09 19:41 ` G. Branden Robinson 2025-03-09 19:57 ` Bakul Shah via TUHS @ 2025-03-09 22:47 ` Dave Horsfall 2025-03-09 22:58 ` Clem Cole 2 siblings, 0 replies; 68+ messages in thread From: Dave Horsfall @ 2025-03-09 22:47 UTC (permalink / raw) To: The Eunuchs Hysterical Society On Sun, 9 Mar 2025, G. Branden Robinson wrote: > [...] I appreciate getting perspectives from people who fought in the > wars I'm too young to remember; I visit the memorials and try to imagine > what things were like. I really enjoyed using ALGOLW in my student days, but not so much Pascal (especially the one that ran under CDC KRONOS, as its read-ahead meant that you were presented with a "?" prompt before any output was seen). -- Dave ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-09 19:41 ` G. Branden Robinson 2025-03-09 19:57 ` Bakul Shah via TUHS 2025-03-09 22:47 ` Dave Horsfall @ 2025-03-09 22:58 ` Clem Cole 2025-03-09 23:12 ` Larry McVoy 2025-03-10 23:25 ` Greg A. Woods 2 siblings, 2 replies; 68+ messages in thread From: Clem Cole @ 2025-03-09 22:58 UTC (permalink / raw) To: G. Branden Robinson; +Cc: TUHS [-- Attachment #1: Type: text/plain, Size: 12350 bytes --] On Sun, Mar 9, 2025 at 3:42 PM G. Branden Robinson < g.branden.robinson@gmail.com> wrote: > Hi Clem, > > Thanks for you detailed response. Most welcome. > I appreciate getting perspectives > from people who fought in the wars I'm too young to remember; I visit > the memorials and try to imagine what things were like. > I think a huge issue is your introduction to computing was on a PC, not on a mainframe or even a mini. IMHO the #1 biggest issue with the PC were so little learnings from either systems was used and so much was re-invented. As some on once said, instead of standing on the shoulders of the giants from before, computer scientists seems to step each other other toes. > > Hmm, I can already see that I might have confused ISO Standard Pascal > (ISO 7185) with ISO Extended Pascal (ISO 10206). Both standards, but > only one named "Standard". I apologize for my error. > No worries, by 1990 when ISO 10206 came about, Pascal had already morphed even by Wirth himself. I liked Modula-II (and so called Mod-III the DEC SRC implementation). One of my favorite early workstations was Wirth's Lilith a Mod-22 based system that was an Alto clone like the Perq (a.k.a the PascAlto). > > > That's also a flaw, but C doesn't distinguish itself strongly here; > `static` function linkage should have been the default. You can argue both ways. Asmblers of the day worked like C did. > > But that was true of C for a long time as well; as I understand it, > Hmm look at the sources or at least at Dennis' Tour document. Ken or Steve Bourne can correct me he as I started with Fifth Edition and pretty sure Dennis' compiler was multipass. Some passed were separate programs due to the address space limits of the PDP-11. But by 1978 and Typesetter C, much less 80/81 when Brian and PJ did SW Tools in Pascal, Brian's statement hold. > > And for me, writing to minimize forward declarations _is_ the natural > order. Hey, I was taught that way also. I knew FORTRAN, Algol-W, SAIL, BLISS, as well as Pascal (much less a few assembler languages) before I learned C and the PDP-11. The White book did not exist, BTW. I started learning before Lesk's IO library - although we got V6, I have few memories of anything interesting by me being written without using Lesk's library or later libS.a from Typesetter C. I understand Brian's complaint, and coming from Ratfor/FORTRAN, Pascal's rigor certainly would have been awkward, but I liked having the flexibility that C provided. Frankly, I hate more modern C code when the first thing you see is a lot of functions, and then main() is declared much later. But then again, I like to keep main() and maybe one or two primary functions in the program.c file and all my subroutines in either subr.c or like, then in program.h declare everything. > > > > 5. The order of logical expression evaluation cannot be controlled, > > which leads to convoluted code and extraneous variables. > > Some of this blows back onto C. Yes, short-circuit logical evaluation > operators are desirable, Absolutely. > but apart from that the order of expression > evaluation in C (a) is frequenly not specified so that compilers can > generate fast code for the hardware; or (b) demands that the programmer > remember something like 15 levels of operator precedence, which is > savage cruelty in my opinion. > That's more about the implementation of a coding style. Post students of Wulf's Green Book, the compiler should not care. It should generate optimal code. Anyway, I frankly prefer to see explicit parens, so the precedence is clear — it's easier to read and less error-prone for the maintainer. > > Still, scanf() was a bad idea, or at least overapplied, Remember printf() and scanf() come from FORTRAN in heritage. The idea was that the format statements worked in both places. I'll not argue that scanf() is a mess; I have generally avoided it. > and should not > be taught to students as a tool for interactive I/O handling (as it was > to me--did anyone else have this misfortune?). I seriously hope you were not given the C Programming Language as a teaching language — shame on your instructors. We don't put new pilots in an F15. Even in the military, they start on straightforward fixed-wing aircraft similar to the Piper Cub or Cessna 150 [just as my father did when he was a fighter instructor for the Army in the 1940s, BTW]. Use the tools for what they were designed for. I still think Pascal is the best teaching language around, and Clancy and Cooper's book "Oh Pascal" is the best way to introduce programmers to systems thinking. But give them professional tools as they start to do harder things, and their skills will improve. It's funny as she has since graduated college and works for a local SW firm, but a young woman I mentored a few years ago; I taught her using "Oh Pascal" while her HS was trying to use C++ (and she was very confused by it - the teacher was poor and the book wasn't great either — Dietel and Dietel). She later went to WPI, and she thanked me for "forcing her" to learn to do the simple stuff and understand it. She saw Java in college courses, and things made much more sense to her. > For that, a simple > lexical analyzer is necessary because humans produce undisciplined > input. It's never too early to teach a beginner how to write a finite > state machine. > I agree — everyone should write for their first compiler in Pascal for a simple language and no cheating using YACC. You need to write the whole thing if you want to understand how parsing really works. > > I guess standardization of Pascal started too late; but both C There was a standard. Everyone had the sources to Dennis and later Steve's compilers. 😉 > and C++ took a long time to get to their initial standards too. What do > you > think accounts for C and C++'s greater success, in the specific sense > that vendor extensions didn't cripple the language's development? What > force kept these languages better governed? > In C's case, the committees were controlled as long as Dennis was there. Two of Dennis's most famous quotes are: *"When I read commentary about suggestions for where C should go, I often think back and give thanks that it wasn't developed under the advice of a worldwide crowd."* and *“C is quirky, flawed, and an enormous success.”* I find where the C standard folks falling into the C++ trap and letting people pee it. CC++ is a disaster — primarily because everyone added their favorite feature. That's while I like Go for applications work, and if I were to do OS (near the HW development) today and not use C, I would have to consider Rust. > > > I've read Lindsey's "A history of ALGOL 68" in HOPL 2 (1996). > Intriguing stuff. I have no strong opinions about any of it, probably > because no one's either forced me to write in ALGOL 68, nor forbidden me > from doing so. I do admire its nearly universal loop structure: > I'll leave it to srb to reply to that. CMU had a budding A68 team led by Peter Hibbard, but I never used it. I had Peter for compilers, so we read a number of the papers at the time, but after I graduated, work that led to Ada had started. I liked what I saw with Red; it follows 'Tartan,' which Wulf and his students, like Hilfiger, put together. as a "Hail Mary" when it started to be clear Green was going to "win." When I was a grad student, and Paul had finished his PhD and started teaching at UCB, I took his comparative language seminar. I learned to hate Ada (*a.k.a.* "Green") a bit less. But that's a different email thread with fewer Unix orientations, so it belongs elsewhere. > > > That was still a live issue when I was learning, but back then (on home > 8-bit micros), you had to shell out money to get anything but the BASIC > interpreter that was stored in ROM. > I understand. The more significant issue is that "production quality" compilers did not target those systems (yet). This came up a while back on Quora: https://www.quora.com/When-did-C-compilers-start-generating-optimized-code-that-runs-faster-than-average-assembly-programmers-code/answer/Clem-Cole I'd like to talk to some of that cohort about Ada. > Sure, move it, COFF. > > That shocks me, but okay ... What am I missing? > Simple: a different set of problems at the time. Read my answer: https://www.quora.com/How-did-we-make-the-first-computer-operating-system-if-we-didnt-have-computers-to-make-them-on/answer/Clem-Cole > > > > ...Thompson had a hand in writing that one, didn't he? During his > sabbatical that spawned the CSRG? If so, that was 1975. > Pascal escapes UCB with what we now call "1BSD," the original BSD tape that Joy wrote either 77 or 78. It's written in a flavor of pre-typesetter C - which was a UCB modified V6 dmr compiler (and eyacc UCB' extended Yacc IIRC) > > I have no expectation that it will displace C, but its developers have > my admiration for pushing forward. Maybe that's because, in maintaining > a typesetting system that _isn't_ TeX, I recognize potentially kindred > spirits. > I've used Free Pascal as a teaching tool for the last few years. They did a nice job. > > Well, the professionals weren't wrong. MS-DOS was a crap OS on a crap > ISA. They were both market placeholders. But we don't work, or live, > in a meritocracy. As ever, the surest route to the head of the line is > to be deposited there at birth by your ancestor. > Cole's Law: "*Simple Economics always beats Sophisticated Design*" The PCs were cheap, and >>eventually<< people got them to do the things they needed. This is classic Christenson 'Disruptive Technology." The "lessor" technology beat the "better" one by creating a new market with different set of customer and can build faster and over time the features of the 'lessor' technology will catch up because its on a faster growth curve. > Oof, for RT-11. OMSI Pascal ran on RT/RSX/RSTS and Unix. But they sold the most copies for RT and RSX. > I've booted RSX-11--once--on my PiDP-11. It was a jarring experience. Yep. > Booting 2.11BSD was headily nostalgic, and took me > _way_ back. I haven't seen a boot sequence like that in a long time. > Did you try V5, V6 or V7? > > > I can't completely agree with you here because as I understand the > critique, C still has _some_ of them _today_. Often not as badly as in > the past, and almost certainly not as bad as the Pascals of the day. > See Dennis' quotes from above. > > I had thought that device-independent troff directly drove some changes > to the C language (not just support libraries), but maybe I'm wrong. It likely did. Steve may be able to add color here. > I have no idea how the Ritchie compiler or PCC evolved after Seventh > Edition (1979). PCC took the mantel, and eventually, PCC2 took that -- look in SVR4 sources for the latter. > The main thing I know about it is that if an > implementation targeted x86, it added `near` and `far` keywords to > accommodate segmented memory and/or DOS-style object file formats. I think Lattice C did that first, and it was picked up by the DOS crew. Most of us thought it was an abomination, but we had switched to 32-bits by then and Vaxen and 68000s. > Well, you _could_ bypass it and use read() and write() directly. Say, > in cat(1), the way Pike intended. ;-) > And people did since that was the >>UNIX<< IO system, but it was not the Honeywell or MVS system (or ITS for the Synder PDP-10 compiler). As I said, please remember that systems programming languages were like assemblers; the local OS supplied the I/O library. Lesk codified a scheme that could be made to work on multiple target OSes. Dennis rethought and reimplemented a similar idea with fewer issues: libS.a. With the White Book, libS.a was formalized, and only then did C have an IO library. In fact, when Lattice did their first DOS compiler, they provided an IO scheme for DOS and only sort of kinda did Standard I/O. Best wishes. Clem [-- Attachment #2: Type: text/html, Size: 24258 bytes --] ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-09 22:58 ` Clem Cole @ 2025-03-09 23:12 ` Larry McVoy 2025-03-09 23:18 ` Steve Nickolas 2025-03-09 23:39 ` Lawrence Stewart 2025-03-10 23:25 ` Greg A. Woods 1 sibling, 2 replies; 68+ messages in thread From: Larry McVoy @ 2025-03-09 23:12 UTC (permalink / raw) To: Clem Cole; +Cc: TUHS > Anyway, I frankly prefer to see explicit parens, so the precedence > is clear ??? it's easier to read and less error-prone for the maintainer. This, a thousand times, this. I taught my guys "think of coding as write once, read many. I could care less how much more work it is, write code such that it is the easiest to understand". ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-09 23:12 ` Larry McVoy @ 2025-03-09 23:18 ` Steve Nickolas 2025-03-09 23:39 ` Lawrence Stewart 1 sibling, 0 replies; 68+ messages in thread From: Steve Nickolas @ 2025-03-09 23:18 UTC (permalink / raw) To: TUHS On Sun, 9 Mar 2025, Larry McVoy wrote: >> Anyway, I frankly prefer to see explicit parens, so the precedence >> is clear ??? it's easier to read and less error-prone for the maintainer. > > This, a thousand times, this. I taught my guys "think of coding as write > once, read many. I could care less how much more work it is, write code > such that it is the easiest to understand". > I assume compiler braindeath and always code around it. An extra pair of parentheses never hurt. -uso. ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-09 23:12 ` Larry McVoy 2025-03-09 23:18 ` Steve Nickolas @ 2025-03-09 23:39 ` Lawrence Stewart 2025-03-10 0:55 ` Stuff Received 1 sibling, 1 reply; 68+ messages in thread From: Lawrence Stewart @ 2025-03-09 23:39 UTC (permalink / raw) To: The Unix Heritage Society mailing list; +Cc: Lawrence Stewart [-- Attachment #1: Type: text/plain, Size: 1270 bytes --] The C operator precedence table has 15 precedence levels, from “++" down to “," (see https://en.cppreference.com/w/c/language/operator_precedence) This is nuts. I don’t remember them and I wouldn’t trust an engineer who claimed to. Around 2005, when I was doing some chip verification, I found a hard to notice operator precedence bug (in VHDL, but it is the same issue) that would have cost us a half-million dollar mask spin. If there is more than one operator, I use parens (I do write a[x] + b[x], that one I know.) Our K-12 system isn’t doing us any favors when they think PEMDAS is “mathematics”. -L PS I’ve been a little angry about this since my 6th grader got marked down for using “extra” parentheses in class. https://larry.stewart.org/2010/12/05/order-of-operations-evil-and-pernicious/ > On Mar 9, 2025, at 19:12, Larry McVoy <lm@mcvoy.com> wrote: > >> Anyway, I frankly prefer to see explicit parens, so the precedence >> is clear ??? it's easier to read and less error-prone for the maintainer. > > This, a thousand times, this. I taught my guys "think of coding as write > once, read many. I could care less how much more work it is, write code > such that it is the easiest to understand". [-- Attachment #2.1: Type: text/html, Size: 4703 bytes --] [-- Attachment #2.2: favicon.ico --] [-- Type: image/vnd.microsoft.icon, Size: 4119 bytes --] ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-09 23:39 ` Lawrence Stewart @ 2025-03-10 0:55 ` Stuff Received 2025-03-10 1:19 ` Rob Pike 2025-03-10 3:06 ` Larry McVoy 0 siblings, 2 replies; 68+ messages in thread From: Stuff Received @ 2025-03-10 0:55 UTC (permalink / raw) To: tuhs On 2025-03-09 19:39, Lawrence Stewart wrote: > The C operator precedence table has 15 precedence levels, from “++" down > to “," > (see https://en.cppreference.com/w/c/language/operator_precedence > <https://en.cppreference.com/w/c/language/operator_precedence>) > > This is nuts. I don’t remember them and I wouldn’t trust an engineer > who claimed to. > > Around 2005, when I was doing some chip verification, I found a hard to > notice operator precedence bug (in VHDL, but it is the same issue) that > would have cost us a half-million dollar mask spin. > > If there is more than one operator, I use parens (I do write a[x] + > b[x], that one I know.) > > Our K-12 system isn’t doing us any favors when they think PEMDAS is > “mathematics”. > > -L > > PS I’ve been a little angry about this since my 6th grader got marked > down for using “extra” parentheses in class. Parentheses around expressions were required in our coding style. S. ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-10 0:55 ` Stuff Received @ 2025-03-10 1:19 ` Rob Pike 2025-03-10 3:06 ` Larry McVoy 1 sibling, 0 replies; 68+ messages in thread From: Rob Pike @ 2025-03-10 1:19 UTC (permalink / raw) To: Stuff Received; +Cc: tuhs [-- Attachment #1: Type: text/plain, Size: 716 bytes --] I have a shell script that helps: % cat bin/ops #!/usr/local/plan9/bin/rc cat <<! 1 () [] -> . left 2 ! ~ ++ -- - (type) * & sizeof right 3 * / % left 4 + - left 5 >> << left 6 < <= > >= left 7 == != left 8 & left 9 ^ left 10 | left 11 && left 12 || left 13 ?: right 14 = op= right 15 , left ! % I used to use it regularly. Later I did the obvious followup: % cat bin/goops #!/bin/sh cat <<! 6 * / % << >> & &^ 5 + - | ^ 4 == != < <= > >= 3 <- 2 && 1 || ! % The difference besides the obvious is that it turned out I never need goops. (Also gofmt uses spaces cleverly to show grouping.) -rob [-- Attachment #2: Type: text/html, Size: 20595 bytes --] ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-10 0:55 ` Stuff Received 2025-03-10 1:19 ` Rob Pike @ 2025-03-10 3:06 ` Larry McVoy 2025-03-10 9:12 ` arnold 1 sibling, 1 reply; 68+ messages in thread From: Larry McVoy @ 2025-03-10 3:06 UTC (permalink / raw) To: Stuff Received; +Cc: tuhs On Sun, Mar 09, 2025 at 08:55:20PM -0400, Stuff Received wrote: > On 2025-03-09 19:39, Lawrence Stewart wrote: > >The C operator precedence table has 15 precedence levels, from ???++" down > >to ???," > >(see https://en.cppreference.com/w/c/language/operator_precedence > ><https://en.cppreference.com/w/c/language/operator_precedence>) > > > >This is nuts. ??I don???t remember them and I wouldn???t trust an engineer > >who claimed to. > > > >Around 2005, when I was doing some chip verification, I found a hard to > >notice operator precedence bug (in VHDL, but it is the same issue) that > >would have cost us a half-million dollar mask spin. > > > >If there is more than one operator, I use parens (I do write a[x] + b[x], > >that one I know.) > > > >Our K-12 system isn???t doing us any favors when they think PEMDAS is > >???mathematics???. > > > >-L > > > >PS I???ve been a little angry about this since my 6th grader got marked > >down for using ???extra??? parentheses in class. > > Parentheses around expressions were required in our coding style. Good for you, we were the same. It's not that hard to make the code easier to read. --lm ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-10 3:06 ` Larry McVoy @ 2025-03-10 9:12 ` arnold 2025-03-10 14:41 ` Larry McVoy 0 siblings, 1 reply; 68+ messages in thread From: arnold @ 2025-03-10 9:12 UTC (permalink / raw) To: stuff, lm; +Cc: tuhs Larry McVoy <lm@mcvoy.com> wrote: > > Parentheses around expressions were required in our coding style. > > Good for you, we were the same. It's not that hard to make the code > easier to read. I think, as in all things, "always use parentheses" can be carried too far. I find if (a == b && c == d) perfectly reasonable, but if ((a == b) && (c == d)) to be just silly. That said, when mixing && and ||, I do parenthesize: if ((a == b && c == d) || (p == q && x == y)) If there are lots of OR conditions, I break lines: if ( (a == b && c == d) || (e == f && g == h) || (i == j && k == l) || (p == q && x == y)) I will also use parentheses with the bitwise operators. As in many things related to style, taste and judgement are needed, not just slavish adherence to instructions without any understanding of them. My two cents. Arnold (P.S. Don't get me started on `if (NULL == pointer)' and `if (42 != foo)'. Grrrr...) ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-10 9:12 ` arnold @ 2025-03-10 14:41 ` Larry McVoy 2025-03-10 14:52 ` Clem Cole 2025-03-10 14:57 ` Dan Cross 0 siblings, 2 replies; 68+ messages in thread From: Larry McVoy @ 2025-03-10 14:41 UTC (permalink / raw) To: arnold; +Cc: stuff, tuhs On Mon, Mar 10, 2025 at 03:12:06AM -0600, arnold@skeeve.com wrote: > I think, as in all things, "always use parentheses" can be carried > too far. I find > > if (a == b && c == d) > > perfectly reasonable, but > > if ((a == b) && (c == d)) > > to be just silly. Color me silly then. My eyes parse the "silly" form faster. And I was the boss so my eyes won. Over time, everyone at my shop came to agree with me. One mans silly is another mans faster reading. If you worked for me, you did the silly form. And everyone came around to liking it. It's just faster to read. ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-10 14:41 ` Larry McVoy @ 2025-03-10 14:52 ` Clem Cole 2025-03-10 15:06 ` Larry McVoy 2025-03-10 14:57 ` Dan Cross 1 sibling, 1 reply; 68+ messages in thread From: Clem Cole @ 2025-03-10 14:52 UTC (permalink / raw) To: tuhs [-- Attachment #1: Type: text/plain, Size: 834 bytes --] On Mon, Mar 10, 2025 at 10:41 AM Larry McVoy <lm@mcvoy.com> wrote: > On Mon, Mar 10, 2025 at 03:12:06AM -0600, arnold@skeeve.com wrote: > > I think, as in all things, "always use parentheses" can be carried > > too far. I find > > > > if (a == b && c == d) > > > > perfectly reasonable, but > > > > if ((a == b) && (c == d)) > > > > to be just silly. > > Color me silly then. Me too. > My eyes parse the "silly" form faster. Exactly. > And I was the boss so my eyes won. Over time, everyone at my shop came > to agree with me. > One mans silly is another mans faster reading. > The problem is that in the first form, you have to slow down to ensure you have the order correctly, Maybe it's my dyslexia speaking, but the "extra" parens make it clear without having to slow down. ᐧ [-- Attachment #2: Type: text/html, Size: 2488 bytes --] ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-10 14:52 ` Clem Cole @ 2025-03-10 15:06 ` Larry McVoy 2025-03-10 15:27 ` Dan Cross 0 siblings, 1 reply; 68+ messages in thread From: Larry McVoy @ 2025-03-10 15:06 UTC (permalink / raw) To: Clem Cole; +Cc: tuhs On Mon, Mar 10, 2025 at 10:52:20AM -0400, Clem Cole wrote: > On Mon, Mar 10, 2025 at 10:41???AM Larry McVoy <lm@mcvoy.com> wrote: > > > On Mon, Mar 10, 2025 at 03:12:06AM -0600, arnold@skeeve.com wrote: > > > I think, as in all things, "always use parentheses" can be carried > > > too far. I find > > > > > > if (a == b && c == d) > > > > > > perfectly reasonable, but > > > > > > if ((a == b) && (c == d)) > > > > > > to be just silly. > > > > Color me silly then. > > Me too. > > > My eyes parse the "silly" form faster. > > Exactly. > > > And I was the boss so my eyes won. Over time, everyone at my shop came > > to agree with me. > > One mans silly is another mans faster reading. > > > The problem is that in the first form, you have to slow down to ensure you > have the order correctly, Maybe it's my dyslexia speaking, but the "extra" > parens make it clear without having to slow down. Exactly. It's not that Clem and I are stupid, we aren't. It's that we want to use our brains to work on stuff that is actually hard. Making us spend effort on "silly" stuff is just rude, just don't do that. You are entitled to your opinion for sure, but you are less entitled when that opinion creates pointless work for other people. ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-10 15:06 ` Larry McVoy @ 2025-03-10 15:27 ` Dan Cross 2025-03-10 15:46 ` Larry McVoy 2025-03-10 15:47 ` Warner Losh 0 siblings, 2 replies; 68+ messages in thread From: Dan Cross @ 2025-03-10 15:27 UTC (permalink / raw) To: Larry McVoy; +Cc: tuhs On Mon, Mar 10, 2025 at 11:12 AM Larry McVoy <lm@mcvoy.com> wrote: > On Mon, Mar 10, 2025 at 10:52:20AM -0400, Clem Cole wrote: > > On Mon, Mar 10, 2025 at 10:41???AM Larry McVoy <lm@mcvoy.com> wrote: > > > On Mon, Mar 10, 2025 at 03:12:06AM -0600, arnold@skeeve.com wrote: > > > > I think, as in all things, "always use parentheses" can be carried > > > > too far. I find > > > > > > > > if (a == b && c == d) > > > > > > > > perfectly reasonable, but > > > > > > > > if ((a == b) && (c == d)) > > > > > > > > to be just silly. > > > > > > Color me silly then. > > > > Me too. > > > > > My eyes parse the "silly" form faster. > > > > Exactly. > > > > > And I was the boss so my eyes won. Over time, everyone at my shop came > > > to agree with me. > > > One mans silly is another mans faster reading. > > > > > The problem is that in the first form, you have to slow down to ensure you > > have the order correctly, Maybe it's my dyslexia speaking, but the "extra" > > parens make it clear without having to slow down. > > Exactly. It's not that Clem and I are stupid, we aren't. Oh goodness; I hope we can all agree that no one was suggesting that! > [snip] creates pointless work for other people. Along these lines, I can't stand when people write, `if (!strcmp(a, b)) { /* strings are equal */ }` While true, I find the negation particularly annoying in this context, and prefer either `if (strcmp(a, b) == 0) { ... }` or writing a small `streq()` function that returns boolean true/false. - Dan C. ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-10 15:27 ` Dan Cross @ 2025-03-10 15:46 ` Larry McVoy 2025-03-10 15:47 ` Warner Losh 1 sibling, 0 replies; 68+ messages in thread From: Larry McVoy @ 2025-03-10 15:46 UTC (permalink / raw) To: Dan Cross; +Cc: tuhs On Mon, Mar 10, 2025 at 11:27:46AM -0400, Dan Cross wrote: > > [snip] creates pointless work for other people. > > Along these lines, I can't stand when people write, `if (!strcmp(a, > b)) { /* strings are equal */ }` > > While true, I find the negation particularly annoying in this context, > and prefer either `if (strcmp(a, b) == 0) { ... }` or writing a small > `streq()` function that returns boolean true/false. From bitkeeper's style.h: #define streq(a,b) (!strcmp((a),(b))) and #define unless(e) if (!(e)) Maybe I should post the whole file :-) ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-10 15:27 ` Dan Cross 2025-03-10 15:46 ` Larry McVoy @ 2025-03-10 15:47 ` Warner Losh 1 sibling, 0 replies; 68+ messages in thread From: Warner Losh @ 2025-03-10 15:47 UTC (permalink / raw) To: Dan Cross; +Cc: tuhs [-- Attachment #1: Type: text/plain, Size: 2771 bytes --] On Mon, Mar 10, 2025 at 9:28 AM Dan Cross <crossd@gmail.com> wrote: > On Mon, Mar 10, 2025 at 11:12 AM Larry McVoy <lm@mcvoy.com> wrote: > > On Mon, Mar 10, 2025 at 10:52:20AM -0400, Clem Cole wrote: > > > On Mon, Mar 10, 2025 at 10:41???AM Larry McVoy <lm@mcvoy.com> wrote: > > > > On Mon, Mar 10, 2025 at 03:12:06AM -0600, arnold@skeeve.com wrote: > > > > > I think, as in all things, "always use parentheses" can be carried > > > > > too far. I find > > > > > > > > > > if (a == b && c == d) > > > > > > > > > > perfectly reasonable, but > > > > > > > > > > if ((a == b) && (c == d)) > > > > > > > > > > to be just silly. > > > > > > > > Color me silly then. > > > > > > Me too. > > > > > > > My eyes parse the "silly" form faster. > > > > > > Exactly. > > > > > > > And I was the boss so my eyes won. Over time, everyone at my shop > came > > > > to agree with me. > > > > One mans silly is another mans faster reading. > > > > > > > The problem is that in the first form, you have to slow down to ensure > you > > > have the order correctly, Maybe it's my dyslexia speaking, but the > "extra" > > > parens make it clear without having to slow down. > > > > Exactly. It's not that Clem and I are stupid, we aren't. > > Oh goodness; I hope we can all agree that no one was suggesting that! > Yea. That's the problem with style debates: It's all about taste, preference and workflow. Those items differ wildly, are core to one's identity (to a degree not usually appreciated) and so it turns personal w/o people intending it to do so. I saw a presentation years ago that went over all the human factors and showed that there's too many 80/20 60/40 divides in how people's brains work to have a universal style that would be friction free for everybody. I searched for it just now, but couldn't find it. I'm team "If you want that many parens, use LISP" not team "Explicit parens make it clearer" myself, but as you see, my internal framing isn't exactly respectul while trying to be funny... Another hazard of style debates. > > [snip] creates pointless work for other people. > > Along these lines, I can't stand when people write, `if (!strcmp(a, > b)) { /* strings are equal */ }` > > While true, I find the negation particularly annoying in this context, > and prefer either `if (strcmp(a, b) == 0) { ... }` or writing a small > `streq()` function that returns boolean true/false. > There's a number of things in C that we'd do differently in other languages... FreeBSD encourages the latter style over the former and is an odd choice of concise and verbose when it comes to notation (sometimes delete the extra parens, sometimes have extra == 0 or != 0). Warner [-- Attachment #2: Type: text/html, Size: 3950 bytes --] ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-10 14:41 ` Larry McVoy 2025-03-10 14:52 ` Clem Cole @ 2025-03-10 14:57 ` Dan Cross 2025-03-10 15:09 ` Larry McVoy 1 sibling, 1 reply; 68+ messages in thread From: Dan Cross @ 2025-03-10 14:57 UTC (permalink / raw) To: Larry McVoy; +Cc: stuff, tuhs On Mon, Mar 10, 2025 at 10:41 AM Larry McVoy <lm@mcvoy.com> wrote: > On Mon, Mar 10, 2025 at 03:12:06AM -0600, arnold@skeeve.com wrote: > > I think, as in all things, "always use parentheses" can be carried > > too far. I find > > > > if (a == b && c == d) > > > > perfectly reasonable, but > > > > if ((a == b) && (c == d)) > > > > to be just silly. > > Color me silly then. My eyes parse the "silly" form faster. And I was the > boss so my eyes won. Over time, everyone at my shop came to agree with me. > One mans silly is another mans faster reading. > > If you worked for me, you did the silly form. And everyone came around to > liking it. It's just faster to read. I'm with Arnold on this one in terms of preference, but I think there's a meta point that's interesting to consider: style localizations facilitate understanding and knowledge transfer across large code bases. Google has a codebase measured in the BLOC (B as in billion), and very strict style guides; they're really more hard and fast rules as opposed to a soft thing that the term "guide" tends to imply. Personally, I hated Google's style formats; but after a month or two they largely disappeared for me and I stopped thinking about them. I still thought and continue to think they're ugly, but the network effects of being able to `cd` anywhere in that massive monorepo and be able to read a file without the cognitive overhead of internalizing that this programmer preferred to put the braces somewhere else relative to the last programmer was a huge win, far outweighing my aesthetic objections. This directly contributed to allowing the organization to scale to tens of thousands of programmers working in the same code base simultaneously. Supported by tools like automatic formatters, folks concentrated on the problem at hand and not the minutiae of formatting. Uniform style also facilitated things like large-scale, automated refactorings; another huge win in evolving code to newer standards, fixing old problems, and so forth. So even though I didn't like the specifics of the local standard, I respected what it did for us. So I don't think the specifics of whether you put parentheses around every boolean expression matter as much as whether you aggressively commit to consistency everywhere and support that with tooling and automation. - Dan C. ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-10 14:57 ` Dan Cross @ 2025-03-10 15:09 ` Larry McVoy 2025-03-10 16:30 ` arnold 0 siblings, 1 reply; 68+ messages in thread From: Larry McVoy @ 2025-03-10 15:09 UTC (permalink / raw) To: Dan Cross; +Cc: stuff, tuhs On Mon, Mar 10, 2025 at 10:57:39AM -0400, Dan Cross wrote: > So I don't think the specifics of whether you put parentheses around > every boolean expression matter as much as whether you aggressively > commit to consistency everywhere and support that with tooling and > automation. Amen. I've contributed to GNU C code, and while I _HATE_ their coding style, my contributions were in that style. It's their house, their rules, and Dan is spot on as to why that is important. ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-10 15:09 ` Larry McVoy @ 2025-03-10 16:30 ` arnold 2025-03-10 18:18 ` segaloco via TUHS ` (2 more replies) 0 siblings, 3 replies; 68+ messages in thread From: arnold @ 2025-03-10 16:30 UTC (permalink / raw) To: lm, crossd; +Cc: tuhs, stuff Larry McVoy <lm@mcvoy.com> wrote: > On Mon, Mar 10, 2025 at 10:57:39AM -0400, Dan Cross wrote: > > So I don't think the specifics of whether you put parentheses around > > every boolean expression matter as much as whether you aggressively > > commit to consistency everywhere and support that with tooling and > > automation. > > Amen. I've contributed to GNU C code, and while I _HATE_ their coding > style, my contributions were in that style. It's their house, their > rules, and Dan is spot on as to why that is important. I agree 110% with Dan as well. And with Larry about GNU code. Long ago I worked in a startup, and early on the developers got together and wrote up a coding style to use. A year later a new guy came on board, who refused to follow it. It was then easy to see when what's-his-name had touched a part of the code. (I forgot what his name was.) Quite annoying. Arnold ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-10 16:30 ` arnold @ 2025-03-10 18:18 ` segaloco via TUHS 2025-03-10 18:39 ` Stuff Received 2025-03-10 18:56 ` Bakul Shah via TUHS 2 siblings, 0 replies; 68+ messages in thread From: segaloco via TUHS @ 2025-03-10 18:18 UTC (permalink / raw) To: The Eunuchs Hysterical Society Sent with Proton Mail secure email. On Monday, March 10th, 2025 at 9:30 AM, arnold@skeeve.com <arnold@skeeve.com> wrote: > Larry McVoy lm@mcvoy.com wrote: > > > On Mon, Mar 10, 2025 at 10:57:39AM -0400, Dan Cross wrote: > > > > > So I don't think the specifics of whether you put parentheses around > > > every boolean expression matter as much as whether you aggressively > > > commit to consistency everywhere and support that with tooling and > > > automation. > > > > Amen. I've contributed to GNU C code, and while I HATE their coding > > style, my contributions were in that style. It's their house, their > > rules, and Dan is spot on as to why that is important. > > > I agree 110% with Dan as well. And with Larry about GNU code. > > Long ago I worked in a startup, and early on the developers got > together and wrote up a coding style to use. A year later a new > guy came on board, who refused to follow it. It was then > easy to see when what's-his-name had touched a part of the code. (I forgot > what his name was.) Quite annoying. > > Arnold I'm quite enjoying following along in this thread as my current work team is in a growth pattern. For the first year of the project it was mainly just myself and my manager slinging code. We had been bumped over from the same project so already had a pretty good synergy. Then we brought in a few new folks and managed to settle into a good groove, we weren't using automated style enforcement but didn't tend to step on each others toes. This year the team has expanded both a few times over in numbers as well as in geographic footprint and the divergences in approach are finally becoming "a thing" that needs to be addressed intentionally rather than organically. It's proving quite a pain, I used to be a stickler for style and have in the past several years tried to relax that attitude...which now with the growing need to pay attention to that again, it's a bit jarring to now see the pendulum swing in the opposite direction. I generally like deferring to folks tasked with a problem to come up with all the minutiae surrounding their solution, but with the size our team is growing to, I'm coming to recognize where having those structural guardrails saves everyone headaches in the long run. Generally I'm a more parens is fine if it makes meaning clear kind of person, annoyingly though with some assembler projects. Since parentheses are more context-sensitive in different assembler languages, I've found plenty of situations where I use parentheses in a macro or equate definition only to find later when they're used with some operation, they trigger an addressing mode that I didn't intend. - Matt G. ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-10 16:30 ` arnold 2025-03-10 18:18 ` segaloco via TUHS @ 2025-03-10 18:39 ` Stuff Received 2025-03-10 18:56 ` Bakul Shah via TUHS 2 siblings, 0 replies; 68+ messages in thread From: Stuff Received @ 2025-03-10 18:39 UTC (permalink / raw) To: tuhs On 2025-03-10 12:30, arnold@skeeve.com wrote: > Larry McVoy <lm@mcvoy.com> wrote: > >> On Mon, Mar 10, 2025 at 10:57:39AM -0400, Dan Cross wrote: >>> So I don't think the specifics of whether you put parentheses around >>> every boolean expression matter as much as whether you aggressively >>> commit to consistency everywhere and support that with tooling and >>> automation. >> >> Amen. I've contributed to GNU C code, and while I _HATE_ their coding >> style, my contributions were in that style. It's their house, their >> rules, and Dan is spot on as to why that is important. > > I agree 110% with Dan as well. And with Larry about GNU code. > > Long ago I worked in a startup, and early on the developers got > together and wrote up a coding style to use. A year later a new > guy came on board, who refused to follow it. It was then > easy to see when what's-his-name had touched a part of the code. (I forgot > what his name was.) Quite annoying. > > Arnold We foresaw that and ensured that different code could be reformatted with indent. S. ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-10 16:30 ` arnold 2025-03-10 18:18 ` segaloco via TUHS 2025-03-10 18:39 ` Stuff Received @ 2025-03-10 18:56 ` Bakul Shah via TUHS 2 siblings, 0 replies; 68+ messages in thread From: Bakul Shah via TUHS @ 2025-03-10 18:56 UTC (permalink / raw) To: arnold; +Cc: tuhs, stuff On Mar 10, 2025, at 9:30 AM, arnold@skeeve.com wrote: > > Long ago I worked in a startup, and early on the developers got > together and wrote up a coding style to use. A year later a new > guy came on board, who refused to follow it. It was then > easy to see when what's-his-name had touched a part of the code. (I forgot > what his name was.) Quite annoying. Most every company where I worked did this (agreed upon a coding style). One of my best engineers, who usually said very little, preferred a very different style but he set up scripts so that in the editor he saw *his* favorite style and before checking in a file he ran indent to conform to the agreed upon style. ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-09 22:58 ` Clem Cole 2025-03-09 23:12 ` Larry McVoy @ 2025-03-10 23:25 ` Greg A. Woods 2025-03-10 23:35 ` segaloco via TUHS ` (2 more replies) 1 sibling, 3 replies; 68+ messages in thread From: Greg A. Woods @ 2025-03-10 23:25 UTC (permalink / raw) To: The Unix Heritage Society mailing list [-- Attachment #1: Type: text/plain, Size: 2749 bytes --] At Sun, 9 Mar 2025 18:58:14 -0400, Clem Cole <clemc@ccc.com> wrote: Subject: [TUHS] Re: What would early alternatives to C have been? > > I find where the C standard folks falling into the C++ trap and letting > people pee it. CC++ is a disaster ― primarily because everyone added their > favorite feature. That's while I like Go for applications work, and if I > were to do OS (near the HW development) today and not use C, I would have > to consider Rust. Perhaps Rust gets/deserves its name from the corrosion caused by everyone peeing into it too. For me it's way too much of a kitchen sink of what seem to me to be half-baked ideas. W.r.t. Unix history, and any alternatives to C, well I did mention TUNIS a bit ago, and the fact it was implemented in Concurrent Euclid. That's quite a bit later than the first C though. I would guess though that even its parent, Euclid, which came along a little earlier, would still have been too late to have been useful for early Unix. It's mostly just another Algol derivative anyway. It did have some big funding from the military in the early days, but look where that got it. I think one of the most loved innovations C (and B just before it) brought to programming languages was the use of braces instead of begin/end, along with the elimination of some of the other extra unnecessary keywords like "then". These syntactical changes made programming a lot more fun for many of us. I for one dreaded having to use Pascal, or heaven forbid PL/1, after I got used to C just because of the wordy syntax alone (I was still too inexperienced at the time to appreciate BWK's criticisms of Pascal). I had the "fun" experience of learning BASIC and a bit of Pascal in high school, then being thrown into Pascal, C, PL/1, and lisp, all as learning languages, in first year (the first two on Unix, the second two on Multics). Which reminds me, wasn't there was some mention of difficulties with Pascal et al w.r.t. separate compilation earlier in this thread.... Wasn't that one of the features of Berkeley Pascal? I know separate compilation is a definitely a feature by the time it makes it to SunOS/Solaris-2. I remember trying to figure it out once for a class assignment and the TA scowled at me and asked me why on earth I would ever want to do that, so I never trusted that TA on programming languages, or much of anything else, ever again. Proper and elegant and simple modules for a systems programming language would seem a pre-requisite these days though. Preprocessors and headers be gone! -- Greg A. Woods <gwoods@acm.org> Kelowna, BC +1 250 762-7675 RoboHack <woods@robohack.ca> Planix, Inc. <woods@planix.com> Avoncote Farms <woods@avoncote.ca> [-- Attachment #2: OpenPGP Digital Signature --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-10 23:25 ` Greg A. Woods @ 2025-03-10 23:35 ` segaloco via TUHS 2025-03-11 1:14 ` Dan Cross 2025-03-11 0:01 ` Clem Cole 2025-03-11 2:18 ` John Levine 2 siblings, 1 reply; 68+ messages in thread From: segaloco via TUHS @ 2025-03-10 23:35 UTC (permalink / raw) To: The Unix Heritage Society mailing list On Monday, March 10th, 2025 at 4:25 PM, Greg A. Woods <woods@robohack.ca> wrote: > > ... > > Which reminds me, wasn't there was some mention of difficulties with > Pascal et al w.r.t. separate compilation earlier in this thread.... > Wasn't that one of the features of Berkeley Pascal? I know separate > compilation is a definitely a feature by the time it makes it to > SunOS/Solaris-2. I remember trying to figure it out once for a class > assignment and the TA scowled at me and asked me why on earth I would > ever want to do that, so I never trusted that TA on programming > languages, or much of anything else, ever again. > > ... > > -- > Greg A. Woods gwoods@acm.org > > > Kelowna, BC +1 250 762-7675 RoboHack woods@robohack.ca > > Planix, Inc. woods@planix.com Avoncote Farms woods@avoncote.ca If by separate compilation you mean the compiler spits out (possibly optionally) human-readable assembler, I would assume that is nearly crucial for any systems language, otherwise you're putting a lot of faith in an ABI when it comes to linking with your machdep assembly files no? I'd be nervous to use something for bare metal programming that I couldn't easily inspect the resulting assembler code from... - Matt G. ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-10 23:35 ` segaloco via TUHS @ 2025-03-11 1:14 ` Dan Cross 0 siblings, 0 replies; 68+ messages in thread From: Dan Cross @ 2025-03-11 1:14 UTC (permalink / raw) To: segaloco; +Cc: The Unix Heritage Society mailing list On Mon, Mar 10, 2025 at 8:12 PM segaloco via TUHS <tuhs@tuhs.org> wrote: > On Monday, March 10th, 2025 at 4:25 PM, Greg A. Woods <woods@robohack.ca> wrote: > > ... > > > > Which reminds me, wasn't there was some mention of difficulties with > > Pascal et al w.r.t. separate compilation earlier in this thread.... > > Wasn't that one of the features of Berkeley Pascal? I know separate > > compilation is a definitely a feature by the time it makes it to > > SunOS/Solaris-2. I remember trying to figure it out once for a class > > assignment and the TA scowled at me and asked me why on earth I would > > ever want to do that, so I never trusted that TA on programming > > languages, or much of anything else, ever again. > > If by separate compilation you mean the compiler spits out (possibly optionally) > human-readable assembler, I would assume that is nearly crucial for any systems > language, otherwise you're putting a lot of faith in an ABI when it comes to > linking with your machdep assembly files no? I'd be nervous to use something > for bare metal programming that I couldn't easily inspect the resulting > assembler code from... No, typically that means that you've got two or more source files, say a.pas and b.pas; you separately compile those into object files, such as a.o and b.o, and then link them into a file executable binary. Early Pascal systems were not generally modular in that way, while C was. Yes, you are putting some faith into the linker and ABI, but on early Unix, they came from the same folks who wrote the compiler. Generating assembly listings (or disassembling object files/a,out) is a separate matter. - Dan C. ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-10 23:25 ` Greg A. Woods 2025-03-10 23:35 ` segaloco via TUHS @ 2025-03-11 0:01 ` Clem Cole 2025-03-11 2:18 ` John Levine 2 siblings, 0 replies; 68+ messages in thread From: Clem Cole @ 2025-03-11 0:01 UTC (permalink / raw) To: The Unix Heritage Society mailing list [-- Attachment #1: Type: text/plain, Size: 780 bytes --] On Mon, Mar 10, 2025 at 7:25 PM Greg A. Woods <woods@robohack.ca> wrote: > > > Which reminds me, wasn't there was some mention of difficulties with > Pascal et al w.r.t. separate compilation earlier in this thread.... > Wasn't that one of the features of Berkeley Pascal? Yes - had extensions for that so: compiling to *.o and using external libraries was possible. man pc will describe the -c switch pc was the hooks into the pcc system for the vax, but I'm not sure if it was backported the PDP-11. It was moved to the 68k by a couple different teams, including Sun for SunOS. Maybe Larry or Rob G can answer if they ever moved it to SPARC. By that time, they had there own compiler suite and may have started to abandon anything based on pcc. ᐧ [-- Attachment #2: Type: text/html, Size: 1741 bytes --] ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-10 23:25 ` Greg A. Woods 2025-03-10 23:35 ` segaloco via TUHS 2025-03-11 0:01 ` Clem Cole @ 2025-03-11 2:18 ` John Levine 2025-03-11 4:00 ` G. Branden Robinson 2 siblings, 1 reply; 68+ messages in thread From: John Levine @ 2025-03-11 2:18 UTC (permalink / raw) To: tuhs It appears that Greg A. Woods <tuhs@tuhs.org> said: >I think one of the most loved innovations C (and B just before it) >brought to programming languages was the use of braces instead of >begin/end, along with the elimination of some of the other extra >unnecessary keywords like "then". ... I suspect that's because they came along just late enough that everything used ASCII, and they got those cool Model 37 Teletypes, so they could assume that devices could generate and print punctuation like { } [ ] | < > The C standards used to have (still have?) trigraph equivalents for much of the punctuation for people on systems that don't have the characters. R's, John ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-11 2:18 ` John Levine @ 2025-03-11 4:00 ` G. Branden Robinson 2025-03-11 4:14 ` George Michaelson 0 siblings, 1 reply; 68+ messages in thread From: G. Branden Robinson @ 2025-03-11 4:00 UTC (permalink / raw) To: tuhs [-- Attachment #1: Type: text/plain, Size: 1144 bytes --] At 2025-03-10T22:18:43-0400, John Levine wrote: > I suspect that's because they came along just late enough that > everything used ASCII, and they got those cool Model 37 Teletypes, so > they could assume that devices could generate and print punctuation > like { } [ ] | < > "begin" and "end" were fine. I've heard a story that Pascal was unpopular in the Middle East; every programming student wanted to know why they had to pay homage to Israeli Prime Minister Menachem Begin in every program, which tells you how old this story is. > The C standards used to have (still have?) trigraph equivalents for > much of the punctuation for people on systems that don't have the > characters. My understanding of the feedback procedure for ISO C23 finalization is that some NBs (national bodies) fought pretty hard to keep trigraphs. I _think_ they're gone from the final version of the standard, but I don't have an official version, just a "final" draft, and my impression of the WG14 meeting minutes from last year was that this particular issue was fought to the bitter end. So maybe they snuck back in at the 11th hour. Regards, Branden [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-11 4:00 ` G. Branden Robinson @ 2025-03-11 4:14 ` George Michaelson 2025-03-11 15:18 ` Ron Natalie 0 siblings, 1 reply; 68+ messages in thread From: George Michaelson @ 2025-03-11 4:14 UTC (permalink / raw) To: tuhs [-- Attachment #1: Type: text/plain, Size: 1405 bytes --] Is nobody going to tell stories about the #define of Bourne Shell fame? -G On Tue, Mar 11, 2025 at 2:00 PM G. Branden Robinson < g.branden.robinson@gmail.com> wrote: > At 2025-03-10T22:18:43-0400, John Levine wrote: > > I suspect that's because they came along just late enough that > > everything used ASCII, and they got those cool Model 37 Teletypes, so > > they could assume that devices could generate and print punctuation > > like { } [ ] | < > > > "begin" and "end" were fine. > > I've heard a story that Pascal was unpopular in the Middle East; > every programming student wanted to know why they had to pay homage to > Israeli Prime Minister Menachem Begin in every program, which tells you > how old this story is. > > > The C standards used to have (still have?) trigraph equivalents for > > much of the punctuation for people on systems that don't have the > > characters. > > My understanding of the feedback procedure for ISO C23 finalization is > that some NBs (national bodies) fought pretty hard to keep trigraphs. > > I _think_ they're gone from the final version of the standard, but I > don't have an official version, just a "final" draft, and my impression > of the WG14 meeting minutes from last year was that this particular > issue was fought to the bitter end. > > So maybe they snuck back in at the 11th hour. > > Regards, > Branden > [-- Attachment #2: Type: text/html, Size: 1870 bytes --] ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-11 4:14 ` George Michaelson @ 2025-03-11 15:18 ` Ron Natalie 2025-03-11 21:52 ` Rob Pike 0 siblings, 1 reply; 68+ messages in thread From: Ron Natalie @ 2025-03-11 15:18 UTC (permalink / raw) To: tuhs [-- Attachment #1: Type: text/plain, Size: 504 bytes --] Gosh, I had the misfortune of working on the shell (and I think ADB) when they had those darned marcros. I was so happy when 5R2 came around and I found someone had undone them all and turned it back into normal C. ------ Original Message ------ From "George Michaelson" <ggm@algebras.org> To tuhs@tuhs.org Date 3/11/2025 12:14:56 AM Subject [TUHS] Re: What would early alternatives to C have been? >Is nobody going to tell stories about the #define of Bourne Shell fame? > >-G [-- Attachment #2: Type: text/html, Size: 1976 bytes --] ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-11 15:18 ` Ron Natalie @ 2025-03-11 21:52 ` Rob Pike 0 siblings, 0 replies; 68+ messages in thread From: Rob Pike @ 2025-03-11 21:52 UTC (permalink / raw) To: Ron Natalie; +Cc: tuhs The rapscallion who removed the macros, at least for the version I worked on for the v8 shell (sadly missed) was called Steve Bourne. -rob On Wed, Mar 12, 2025 at 2:19 AM Ron Natalie <ron@ronnatalie.com> wrote: > > Gosh, I had the misfortune of working on the shell (and I think ADB) when they had those darned marcros. I was so happy when 5R2 came around and I found someone had undone them all and turned it back into normal C. > > > > ------ Original Message ------ > From "George Michaelson" <ggm@algebras.org> > To tuhs@tuhs.org > Date 3/11/2025 12:14:56 AM > Subject [TUHS] Re: What would early alternatives to C have been? > > Is nobody going to tell stories about the #define of Bourne Shell fame? > > -G ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-09 3:46 [TUHS] " Dan Cross 2025-03-09 6:14 ` [TUHS] " George Michaelson 2025-03-09 12:29 ` Clem Cole @ 2025-03-09 20:13 ` John Levine 2025-03-09 20:35 ` Luther Johnson 2025-03-10 1:31 ` Bakul Shah via TUHS 3 siblings, 1 reply; 68+ messages in thread From: John Levine @ 2025-03-09 20:13 UTC (permalink / raw) To: tuhs It appears that Dan Cross <crossd@gmail.com> said: >My short list included PL/1, Algol/W, Fortran, and Pascal. Fortran was >already mentioned. I don't think PL/1 (or PL/I) could have fit on >those machines. ... There were a lot of PL/I subsets or variants used for system programming. Intel had PL/M, used to write CP/M. IBM had PL/S, used to write some parts of OS/360, and reimplemented at RAND in the early 1970s. XPL was writeen at Stanford in the late 1960s, intended for writing compilers with a small one-pass compiler written in itself. PL/360 was sort of PL/I-ish although it was really an IBM 360 assembler with Algol like syntax, used to write Algol W. One of these could have been a reasonable basis for a system language, but I don't think the result would have been any better than C. R's, John ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-09 20:13 ` John Levine @ 2025-03-09 20:35 ` Luther Johnson 2025-03-09 20:58 ` Clem Cole 2025-03-10 1:51 ` John Levine 0 siblings, 2 replies; 68+ messages in thread From: Luther Johnson @ 2025-03-09 20:35 UTC (permalink / raw) To: tuhs I believe CP/M was written entirely in 8080 assembly language. PL/M was a PL/1 subset, I think Gary Kildall was the main programmer behind that, and I'm sure there was a version for CP/M, but I doubt CP/M was written in it, just due to what I've seen of it. I have a port of CP/M for a machine I've made and sold, where another programmer and I did the porting work, and from what I've seen of early DOS and how it was in many ways modeled after CP/M, it doesn't seem like CP/M was written in anything other than 8080 assembly. However I've only seen the BIOS (not IBM PC BIOS, but the original coining of the term for CP/M, standing for "basic input/output system"), so on the other side, inside of CP/M, I guess it might be anything, but it seems like it is most likely 8080 assembly language too. On 03/09/2025 01:13 PM, John Levine wrote: > It appears that Dan Cross <crossd@gmail.com> said: >> My short list included PL/1, Algol/W, Fortran, and Pascal. Fortran was >> already mentioned. I don't think PL/1 (or PL/I) could have fit on >> those machines. ... > There were a lot of PL/I subsets or variants used for system > programming. Intel had PL/M, used to write CP/M. IBM had PL/S, used to > write some parts of OS/360, and reimplemented at RAND in the early > 1970s. XPL was writeen at Stanford in the late 1960s, intended for > writing compilers with a small one-pass compiler written in itself. > > PL/360 was sort of PL/I-ish although it was really an IBM 360 assembler with > Algol like syntax, used to write Algol W. > > One of these could have been a reasonable basis for a system language, but I > don't think the result would have been any better than C. > > R's, > John > ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-09 20:35 ` Luther Johnson @ 2025-03-09 20:58 ` Clem Cole 2025-03-09 21:12 ` Luther Johnson 2025-03-09 22:57 ` Warner Losh 2025-03-10 1:51 ` John Levine 1 sibling, 2 replies; 68+ messages in thread From: Clem Cole @ 2025-03-09 20:58 UTC (permalink / raw) To: Luther Johnson; +Cc: tuhs [-- Attachment #1: Type: text/plain, Size: 1856 bytes --] On Sun, Mar 9, 2025 at 4:35 PM Luther Johnson <luther.johnson@makerlisp.com> wrote: > I believe CP/M was written entirely in 8080 assembly language. Not initially -- see below. > PL/M wasa PL/1 subset, I think Gary Kildall was the main programmer behind > that, > Gary was a language person not an OS person. PL/M was developed by him under contract with Intel for the original Intel 8080 development system. > and I'm sure there was a version for CP/M, but I doubt CP/M was written > in it, just due to what I've seen of it. From the readme: https://github.com/brouhaha/cpm22 Introduced in 1974, CP/M by Digital Research was one of the first microcomputer operating systems that was not tied to a single computer vendor. It could be adapted to run on almost any 8080 or Z80 microcomputer that had at least 16KB of RAM starting at address 0000h. Originally much of CP/M was written in the PL/M programming language. With the introduction of CP/M 2.0, the command processor (CCP) and kernel (BDOS) were rewritten in 8080 assembly language. > I have a port of CP/M for a > machine I've made and sold, where another programmer and I did the > porting work, and from what I've seen of early DOS and how it was in > many ways modeled after CP/M, it doesn't seem like CP/M was written in > anything other than 8080 assembly. However I've only seen the BIOS (not > IBM PC BIOS, but the original coining of the term for CP/M, standing for > "basic input/output system"), Again, the term came from the Intel 8008 development system. > so on the other side, inside of CP/M, I > guess it might be anything, but it seems like it is most likely 8080 > assembly language too. > As a compiler guy, Kidall was once quoted as the reason who originally wrote CP/M to sell more copies of his compiler. ᐧ [-- Attachment #2: Type: text/html, Size: 4355 bytes --] ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-09 20:58 ` Clem Cole @ 2025-03-09 21:12 ` Luther Johnson 2025-03-09 22:57 ` Warner Losh 1 sibling, 0 replies; 68+ messages in thread From: Luther Johnson @ 2025-03-09 21:12 UTC (permalink / raw) To: Clem Cole; +Cc: tuhs [-- Attachment #1: Type: text/plain, Size: 2339 bytes --] I see, thank you for the history and clarification. The CP/M I have worked with is CP/M 2.2. But as I said, the OS inside could have been written in anything, and now I know in earlier versions, it was something else, thank you. On 03/09/2025 01:58 PM, Clem Cole wrote: > > > On Sun, Mar 9, 2025 at 4:35 PM Luther Johnson > <luther.johnson@makerlisp.com <mailto:luther.johnson@makerlisp.com>> > wrote: > > I believe CP/M was written entirely in 8080 assembly language. > > Not initially -- see below. > > PL/M wasa PL/1 subset, I think Gary Kildall was the main > programmer behind that, > > Gary was a language person not an OS person. PL/M was developed by > him under contract with Intel for the original Intel 8080 development > system. > > and I'm sure there was a version for CP/M, but I doubt CP/M was > written > in it, just due to what I've seen of it. > > From the readme: https://github.com/brouhaha/cpm22 > > Introduced in 1974, CP/M by Digital Research was one of the first > microcomputer operating systems that was not tied to a single > computer vendor. It could be adapted to run on almost any 8080 or > Z80 microcomputer that had at least 16KB of RAM starting at > address 0000h. > > > Originally much of CP/M was written in the PL/M programming > language. With the introduction of CP/M 2.0, the command processor > (CCP) and kernel (BDOS) were rewritten in 8080 assembly language. > > I have a port of CP/M for a > machine I've made and sold, where another programmer and I did the > porting work, and from what I've seen of early DOS and how it was in > many ways modeled after CP/M, it doesn't seem like CP/M was written in > anything other than 8080 assembly. However I've only seen the BIOS > (not > IBM PC BIOS, but the original coining of the term for CP/M, > standing for > "basic input/output system"), > > Again, the term came from the Intel 8008 development system. > > so on the other side, inside of CP/M, I > guess it might be anything, but it seems like it is most likely 8080 > assembly language too. > > > As a compiler guy, Kidall was once quoted as the reason who originally > wrote CP/M to sell more copies of his compiler. > ᐧ [-- Attachment #2: Type: text/html, Size: 6570 bytes --] ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-09 20:58 ` Clem Cole 2025-03-09 21:12 ` Luther Johnson @ 2025-03-09 22:57 ` Warner Losh 1 sibling, 0 replies; 68+ messages in thread From: Warner Losh @ 2025-03-09 22:57 UTC (permalink / raw) To: Clem Cole; +Cc: Luther Johnson, tuhs [-- Attachment #1: Type: text/plain, Size: 2060 bytes --] On Sun, Mar 9, 2025 at 2:59 PM Clem Cole <clemc@ccc.com> wrote: > > > On Sun, Mar 9, 2025 at 4:35 PM Luther Johnson < > luther.johnson@makerlisp.com> wrote: > >> I believe CP/M was written entirely in 8080 assembly language. > > Not initially -- see below. > >> PL/M wasa PL/1 subset, I think Gary Kildall was the main programmer >> behind that, >> > Gary was a language person not an OS person. PL/M was developed by him > under contract with Intel for the original Intel 8080 development system. > >> and I'm sure there was a version for CP/M, but I doubt CP/M was written >> in it, just due to what I've seen of it. > > From the readme: https://github.com/brouhaha/cpm22 > > Introduced in 1974, CP/M by Digital Research was one of the first > microcomputer operating systems that was not tied to a single computer > vendor. It could be adapted to run on almost any 8080 or Z80 microcomputer > that had at least 16KB of RAM starting at address 0000h. > > > Originally much of CP/M was written in the PL/M programming language. With > the introduction of CP/M 2.0, the command processor (CCP) and kernel (BDOS) > were rewritten in 8080 assembly language. > > > >> I have a port of CP/M for a >> machine I've made and sold, where another programmer and I did the >> porting work, and from what I've seen of early DOS and how it was in >> many ways modeled after CP/M, it doesn't seem like CP/M was written in >> anything other than 8080 assembly. However I've only seen the BIOS (not >> IBM PC BIOS, but the original coining of the term for CP/M, standing for >> "basic input/output system"), > > Again, the term came from the Intel 8008 development system. > > > >> so on the other side, inside of CP/M, I >> guess it might be anything, but it seems like it is most likely 8080 >> assembly language too. >> > > As a compiler guy, Kidall was once quoted as the reason who originally > wrote CP/M to sell more copies of his compiler. > Isn't that what Unix did for C <duck/> Warner > ᐧ > [-- Attachment #2: Type: text/html, Size: 4848 bytes --] ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-09 20:35 ` Luther Johnson 2025-03-09 20:58 ` Clem Cole @ 2025-03-10 1:51 ` John Levine 2025-03-10 2:54 ` Luther Johnson 1 sibling, 1 reply; 68+ messages in thread From: John Levine @ 2025-03-10 1:51 UTC (permalink / raw) To: tuhs; +Cc: luther.johnson It appears that Luther Johnson <luther.johnson@makerlisp.com> said: >I believe CP/M was written entirely in 8080 assembly language. PL/M was >a PL/1 subset, I think Gary Kildall was the main programmer behind that, >and I'm sure there was a version for CP/M, but I doubt CP/M was written >in it, ... See this Wikipedia article on PL/M, which summarizes the history that Kildall wrote up in a 1993 manuscript now online at the CHM. If he says he wrote it in PL/M I am inclined to believe him. https://en.wikipedia.org/wiki/PL/M#CITEREFKildall1993 R's, John ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-10 1:51 ` John Levine @ 2025-03-10 2:54 ` Luther Johnson 0 siblings, 0 replies; 68+ messages in thread From: Luther Johnson @ 2025-03-10 2:54 UTC (permalink / raw) To: tuhs Got it. My misunderstanding, acknowledged. On 03/09/2025 06:51 PM, John Levine wrote: > It appears that Luther Johnson <luther.johnson@makerlisp.com> said: >> I believe CP/M was written entirely in 8080 assembly language. PL/M was >> a PL/1 subset, I think Gary Kildall was the main programmer behind that, >> and I'm sure there was a version for CP/M, but I doubt CP/M was written >> in it, ... > See this Wikipedia article on PL/M, which summarizes the history that > Kildall wrote up in a 1993 manuscript now online at the CHM. If he > says he wrote it in PL/M I am inclined to believe him. > > https://en.wikipedia.org/wiki/PL/M#CITEREFKildall1993 > > R's, > John > ^ permalink raw reply [flat|nested] 68+ messages in thread
* [TUHS] Re: What would early alternatives to C have been? 2025-03-09 3:46 [TUHS] " Dan Cross ` (2 preceding siblings ...) 2025-03-09 20:13 ` John Levine @ 2025-03-10 1:31 ` Bakul Shah via TUHS 3 siblings, 0 replies; 68+ messages in thread From: Bakul Shah via TUHS @ 2025-03-10 1:31 UTC (permalink / raw) To: Dan Cross; +Cc: TUHS Criticisms of C should not be viewed as "casting aspersions". We can't change the past but we can certainly assess the effect of past decisions. [Not sure that would change anything though, but we are just chitchatting!] IMHO with C what we have is a tragedy of scale. A pleasant to use language that worked/works well for a small group of highly competent people with skills beyond programming doesn't work so well for much larger groups of people with varying level of competency & skill. Just as the informality and few implicit rules of a village doesn't scale to large cities. I believe Apollo's Domain/OS was implemented in Pascal. Tunis that Greg Woods alluded to was implemented in Concurrent Euclid. KeyKOS (a capability based system) was implemented in PL/I. Per Brinch Hansen implemented a couple of OSes in Concurrent Pascal. And so on. I think the original Mac OS was in Pascal? Of course, most of these efforts came later or were on much larger systems. The beauty of Unix is in its relatively few but well defined components & their composability. I wouldn't know if the design of C had something to do with that or if it was just the pure genius of Thompson, Ritchie and their cohorts at Bell Labs. > On Mar 8, 2025, at 7:46 PM, Dan Cross <crossd@gmail.com> wrote: > > As I mentioned in the discussion about C, it's easy to look back with > a modern perspective and cast aspersions on C. But this got me > thinking, what would possible alternatives have been? In the context > of the very late 1960s heading into the early 70s, and given the > constraints of the PDP-7 and early PDP-11s, what languages would one > consider for implementing a system like early Unix? Dennis's history > paper mentioned a very short-lived effort at Fortran, and I asked > about that a few years ago, but no one really remembered much about > it; I gather this was an experiment that lasted a few days or weeks > and was quickly abandoned. But what else? > > My short list included PL/1, Algol/W, Fortran, and Pascal. Fortran was > already mentioned. I don't think PL/1 (or PL/I) could have fit on > those machines. Pascal was really targeted towards teaching and would > have required pretty extensive work to be usable. The big question > mark in my mind is Algol/W; how well known was it at the time? Was any > consideration for it made? > > Obviously, the decision to go with BCPL (as the basis for B, which > beget C) was made and the rest is history. But I'm really curious > about how, in the research culture at the time, information about new > programming languages made its way through the community. > > - Dan C. ^ permalink raw reply [flat|nested] 68+ messages in thread
end of thread, other threads:[~2025-03-12 16:35 UTC | newest] Thread overview: 68+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2025-03-10 2:03 [TUHS] Re: What would early alternatives to C have been? Douglas McIlroy 2025-03-10 2:28 ` Charles H. Sauer 2025-03-11 2:26 ` [TUHS] Re: uphill both ways, was " John Levine 2025-03-10 4:10 ` [TUHS] " Rob Pike 2025-03-10 15:19 ` John Cowan 2025-03-10 19:56 ` Dave Horsfall 2025-03-10 20:49 ` Bakul Shah via TUHS 2025-03-10 23:12 ` Marc Rochkind 2025-03-10 23:49 ` Clem Cole 2025-03-10 23:58 ` Marc Rochkind 2025-03-11 0:06 ` Ken Thompson 2025-03-11 1:35 ` Larry McVoy 2025-03-11 5:07 ` Ken Thompson [not found] ` <CAKH6PiW8J8=uFbadUTSaC9VcLGUJMFZaSFWOFDyCM3MpMTSayw@mail.gmail.com <CAMP=X_mchJuVgdpc4-AYHASwEVzUcJXMmqSDv_UvX6y0o0+LBQ@mail.gmail.com> 2025-03-12 1:36 ` [TUHS] Re: parsing tools, was What would early alternatives John Levine 2025-03-12 2:22 ` Rich Salz 2025-03-12 3:35 ` Larry McVoy 2025-03-12 16:35 ` John R Levine 2025-03-12 5:11 ` Greg A. Woods 2025-03-11 5:15 ` [TUHS] Re: What would early alternatives to C have been? John Cowan 2025-03-10 15:12 ` Clem Cole 2025-03-10 15:24 ` Dan Cross [not found] <174154718981.615624.15831772136951719489@minnie.tuhs.org> 2025-03-09 21:01 ` Paul McJones 2025-03-10 0:38 ` Ken Thompson -- strict thread matches above, loose matches on Subject: below -- 2025-03-09 3:46 [TUHS] " Dan Cross 2025-03-09 6:14 ` [TUHS] " George Michaelson 2025-03-09 12:29 ` Clem Cole 2025-03-09 13:18 ` G. Branden Robinson 2025-03-09 17:29 ` Clem Cole 2025-03-09 19:06 ` Ken Thompson 2025-03-09 19:41 ` G. Branden Robinson 2025-03-09 19:57 ` Bakul Shah via TUHS 2025-03-09 22:47 ` Dave Horsfall 2025-03-09 22:58 ` Clem Cole 2025-03-09 23:12 ` Larry McVoy 2025-03-09 23:18 ` Steve Nickolas 2025-03-09 23:39 ` Lawrence Stewart 2025-03-10 0:55 ` Stuff Received 2025-03-10 1:19 ` Rob Pike 2025-03-10 3:06 ` Larry McVoy 2025-03-10 9:12 ` arnold 2025-03-10 14:41 ` Larry McVoy 2025-03-10 14:52 ` Clem Cole 2025-03-10 15:06 ` Larry McVoy 2025-03-10 15:27 ` Dan Cross 2025-03-10 15:46 ` Larry McVoy 2025-03-10 15:47 ` Warner Losh 2025-03-10 14:57 ` Dan Cross 2025-03-10 15:09 ` Larry McVoy 2025-03-10 16:30 ` arnold 2025-03-10 18:18 ` segaloco via TUHS 2025-03-10 18:39 ` Stuff Received 2025-03-10 18:56 ` Bakul Shah via TUHS 2025-03-10 23:25 ` Greg A. Woods 2025-03-10 23:35 ` segaloco via TUHS 2025-03-11 1:14 ` Dan Cross 2025-03-11 0:01 ` Clem Cole 2025-03-11 2:18 ` John Levine 2025-03-11 4:00 ` G. Branden Robinson 2025-03-11 4:14 ` George Michaelson 2025-03-11 15:18 ` Ron Natalie 2025-03-11 21:52 ` Rob Pike 2025-03-09 20:13 ` John Levine 2025-03-09 20:35 ` Luther Johnson 2025-03-09 20:58 ` Clem Cole 2025-03-09 21:12 ` Luther Johnson 2025-03-09 22:57 ` Warner Losh 2025-03-10 1:51 ` John Levine 2025-03-10 2:54 ` Luther Johnson 2025-03-10 1:31 ` Bakul Shah via TUHS
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).