[TUHS] Algol68 vs. C at Bell Labs

[Clem Cole]

Steve - good stuff.   comments below.

On Wed, Jun 29, 2016 at 11:17 AM, <scj at yaccman.com> wrote:

> But the documentation was a huge barrier

​Amen​ - I remember trying to read the report and getting utterly befuddled.



> --all the
> ​ ​
> familiar ideas were given completely new (and unintuitive) names, making
> ​ ​
> it very difficult to get into.
>
​And as importantly, it was not clear to many of us what we were getting
for all that stuff.   Was it sugar or really going to help?​    C, BLISS,
PL/360, BCPL et al, took a much more minimalist view.   Algol68 seems like
it was the "one ring to rule them all" but how could you be sure?



>
> I may be biased in my view, but I think one fatal mistake that A68 made
> was that it had no scheme for porting the language to the plethora of
> computers and systems around at that time.

​I would put this this a little differently.   To me it was not so much
that there was or was not a scheme to move the language, but it was not
economical to try.​   Between your and Dennis's compilers, which were both
"reachable" by many of us, when we needed a language and compiler for these
new microprocessors that were becoming prevalent at the same time, we had
the sources for your compilers and it was "just a matter of a new back
end."



> (The Bliss language from CMU
> ​ ​
> had a similar problem, requiring a bigger computer to compile for the
> ​ ​
> PDP-11).

​While true, I'm not so sure that was the real problem with BLISS.  I
really think it was that CMU sold the language to DEC and compiler sources
were not available to people.   I've always said if DEC had given away the
BLISS compiler and made the sources available in the same manner as C (or
Pascal for that matter), folks like me would have been tempted to use it
write a backend for the 68K (Z8000, 8086 much less the 8-bit micros).​

I also think the size issue could have been (and would have been) fixed if
it was worth it.   But it was not.  The requirement of needing a PDP-10 (or
later Vax) to run was due to the small address space of the PDP-11 and the
amazing things that the BLISS optimizer did.   But you are correct - that
was never done, so it certainly added why BLISS never went very far.

My own experience was simple. At Tektronix, in the late 1970's I was given
a chip that would become the 68K (it was yet to be numbered by Motorola at
that point) and I wanted a HLL for the system we started to make with it
(what would later be called Magnolia).  As a V6 (and later V7) licensee, I
had the sources to the Ritchie compiler.  I knew both BLISS and C (as well
as Algol/Pascal/FTN/PL-1 et,), and I admit in those days still had a
fondness for the former as a CMU grad and Bill Wulf student.   But I did
not have any of the CMU tools (PQCC et al) much less the DEC ones (and you
are correct, I ould get access to the PDP-10, but I had a couple of UNIX
boxes available).  So, I had your tools and they worked well.   Thus,
I wrote a back end for my project for that chip.  It was that simple.   It
was pure economics.




> Pascal had P-code, and gave C a real run, especially as a
> teaching language.

​Right, Pascal had a number of generally available compilers, with P-Code
being the most used.​  It was as economical as C to work.   And a lot of
people used it.  While I liked it as a teaching language, it was useless as
a production language unless you hacked on it and extended it.  And as
importantly for me, it could not be used as a "systems" language as it.  In
fact, at that time Tektronix has at least 6 different but incompatible
flavors of "Tek Pascal." It was language of choice in the product teams
(BTW, our friends and rivals had over 20 flavors of HP BASIC in those days
too).

I picked C because I could and I knew my PDP-11 code would pretty much just
work on this new device.   Admittedly "proof by lack of imagination" reined
here, but I really could not image trying to use Pascal to write an OS.
 I knew I could with BLISS or C.




> Nowadays, newer languages like Python just piggyback on C or C++...

​Hmm... I would say piggyback on the C ecosystem - i.e. GCC (or now LLVM).​

​Clem​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160630/f8c8ad8f/attachment.html>