17 Oct
2011
17 Oct
'11
1:04 p.m.
At the time (late-60s/70s), there was an interest in
having a language
"just above assembler" for things like OS-development - something that
would provide for symbols, expressions, and standard control flow (i.e.
be readable),
There were a few of those around already. IBM had PL/S (or PL/AS, I can't
remember which was first) and Wirth had PL360. PL/S was virtually a high
level assembler with no runtime. PL360 was higher level still.
be independant of machine instructions (even if not an
abstraction
completely independant of the hardware), but still be directly
translateable to machine code and leave the programmer with a sense of
what would happen on the hardware.
I believe PL/S and PL360 met all of those requirements except for being
independent of machine instructions, since PL/S and its follow-ons were all
proprietary. I guess Wirth could have ported PL360 to other machines and
now that I'm reading your email I wonder why he didn't.
For those not fond of C, one might say things went
awry when C was picked
up and became commonplace for 'higher-level' general-purpose programming
in the 80s.
I don't like C but what I don't like about it is subjective and I readily
concede my dislike is purely personal and on an objective level there is
really nothing wrong with C, indeed it's just about perfect for what it is
for. I think you hit the nail on the head. Using C for general purpose
programming seems overly tedious to me, especially compared to my framework
which is assembler or HLL and nothing really in between.
But what were the choices at the time?: assembler
(tedious, not
portable), BASIC (gross), Algol (that might be a candidate), PL/I (big,
limited availability), Pascal (limited, IMO), Ada (I remember looking
forward to Ada in the time it was being developed, but it too was big and
took on committee problems, and was perhaps too late to become a major
presence). In a time of limited memory and speed, C was flexible and
targetable to the microprocs of the 80's.
A good assembler is perfectly situated for writing an OS and not at all
tedious. But a lot depends on the architecture as well as the assembler.
Digital Research and other companies (Intel) did have PL/I subset or PL/I
derivative (PL/M) compilers, so I don't think you can argue it was too big
for microprocessors. I think it was as Chuck suggested, sort of being at
the right place at the right time, and having what would become the most
pervasive OS written using it that led to C becoming indispensable.
Ada 83 is a (very) small language compared to C++, tiny if you factor in
the standard libraries and templates of C++. I remember the hype at the time
but I believe it was unwarranted and wrong in many ways. In fact, looking
at Ada 95 I see some really nice design went into it and Ada 83. I don't
see any bloat in either Ada 83 or 95. You could argue they got a little off
course with 2005 and beyond, but so has almost every other language. That's
part of what has made it hard for me to find a language I like on UNIX.
Everything is so big and complicated now nobody can know a whole language.
I'm not used to that, all the languages I learned were on a whole different
scale and you could eventually know all there was to know. Today that is
almost impossible.
I also wonder how much of the popularity of C and
associated languages is
just "{}" vs. "begin/end". I personally can't stand begin-end
languages
just because all those begin-ends present so much visual clutter in the
program text (although I do have a fondness for Algol).
I don't think that was a factor but I do agree it's an issue. Aesthetics
are important, especially if you write code for a living. You have to like
what you do and it has to feel right. I'm a bracket hater, they seem ugly
to me. Like you, I liked ALGOL (particularly ALGOL68) but I disliked
Pascal. I found PL/I's syntax very simple and easy to live with. Finding a
language that hits the sweet spot is a rare pleasure.