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,
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'd like to talk to some of that cohort about Ada.
Sure, move it, COFF.
That shocks me, but okay ... What am I missing?
...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.
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