[comp.arch] Algol 60 vs Algol 68

andrew@frip.gwd.tek.com (Andrew Klossner) (06/12/88)

[]

	"And the version of Algol that they are running is Algol 60
	{not even Algol 68, but Algol 60! ... Algol 68 does support
	Data structures.  And most smart companies have upgraded their
	systems to Algol 68 or beyond.  Why Unisys hasn't, I don't
	know."

These comments seem to reflect only a passing familiarity with
Algol 68.  Algol 68 resembles Algol 60 no more closely than PL/I
resembles Fortran 66.  A pure Algol 60 program will get nowhere if
pushed through an Algol 68 compiler.

There really isn't any "beyond" to Algol 68 since the 1975 Revised
Report.  It's a dead language.  And that's too bad; while its model of
computation is distant from that of real machines (making it an
inappropriate language for most low level systems programming), it does
an admirable job in its stated domain of algorithmic description, and
is great for applications programming.

  -=- Andrew Klossner   (decvax!tektronix!tekecs!andrew)       [UUCP]
                        (andrew%tekecs.tek.com@relay.cs.net)   [ARPA]

bvs@light.uucp (Bakul Shah) (06/12/88)

In article <10064@tekecs.TEK.COM> Andrew Klossner writes:
> ...
>There really isn't any "beyond" to Algol 68 since the 1975 Revised
>Report.  It's a dead language.  And that's too bad; while its model of
>computation is distant from that of real machines (making it an
>inappropriate language for most low level systems programming), it does
>an admirable job in its stated domain of algorithmic description, and
>is great for applications programming.

Actually Algol 68's model quite closely matches real machines and
the language can be compiled to generate code as efficient as
compiled C; though I doubt there are any modern, optimizing
compilers for it.  The language is verbose and the its syntax
rather od (!) but it can be used quite effectively for systems
programming.  I recall the CAP operating system (for the Cambridge
CAP computer) was written in Algol 68.

I wonder how much of C design was influenced by Algol 68 as most
of K&R C seems to map almost directly to Algol 68 and where C
differs is usually where the compiler's job is simplified.  Come
to think of it, a major subset of Algol 68 with a new and concise
syntax (sort of like C's) can make a very elegant, type safe and
well rounded language.

-- Bakul Shah <..!{sun,pyramid,ucbvax}!amdcad!light!bvs>

dorourke@polyslo.UUCP (David O'Rourke) (06/12/88)

In article <10064@tekecs.TEK.COM> andrew@frip.gwd.tek.com (Andrew Klossner) writes:
>There really isn't any "beyond" to Algol 68 since the 1975 Revised
                         ^^^^^^

  I should've made myself clearer, by Beyond in the original statment I
meant the languages that have been developed since Algol.  Unisys is
committed to this dead language, I'm not saying I agree with this committment,
but if they had to make a change Algol 68 might be easier than another
langauge, although I don't know.
  Silly me I assumed that name of a language indicated it's compatible, you're
right I only have a passing aquaintance with Algol 68, and I improperly
assumed it would be compatible.

  However the original postings wasn't to debate Algol vs. Algol it was to
point out that Uniys, for better or worse {probably worse}, is committed
to a language that's over 20 years old, which isn't good for the company.

-- 
David M. O'Rourke

Disclaimer: I don't represent the school.  All opinions are mine!

jgd@csd1.milw.wisc.edu (John G Dobnick,EMS E380,4142295727,) (06/14/88)

From article <3198@polyslo.UUCP>, by dorourke@polyslo.UUCP (David O'Rourke):
> 
>   However the original postings wasn't to debate Algol vs. Algol it was to
> point out that Uniys, for better or worse {probably worse}, is committed
> to a language that's over 20 years old, which isn't good for the company.

Which is all well and good for the "Burroughs" side of the house.  On the
"Univac" side of the house [What! You say they call themselves "Sperry" now?]
things are slightly different.

In a massive mind-set (and code) migration from assembler to a high-level
language on the 1100 (now 2200) series machines, Univac created PLUS
(Programming Language for Univac Systems) as something suitable for systems-
programming type work.  It has advanced since its early days, but had
its origins in ALGOL 60.  In fact, the first PLUS compiler was a modified
JOVIAL compiler (from what I hear, and I believe *this* source).

Hmmm... sort of looks like *both* sides of the Unisys house now use ALGOL 60.
(Is a :-) needed here?)
-- 
John G Dobnick
Computing Services Division @ University of Wisconsin - Milwaukee
UUCP: <backbone>!uwvax!uwmcsd1!jgd
INTERNET: jgd@csd4.milw.wisc.edu

"Knowing how things work is the basis for appreciation,
and is thus a source of civilized delight."  -- William Safire

jack@cs.glasgow.ac.uk (Mr Jack Campin) (06/17/88)

andrew@frip.gwd.tek.com (Andrew Klossner) writes:

>There really isn't any "beyond" to Algol 68 since the 1975 Revised
>Report.  It's a dead language.  And that's too bad; while its model of
>computation is distant from that of real machines (making it an
>inappropriate language for most low level systems programming), it does
>an admirable job in its stated domain of algorithmic description, and
>is great for applications programming.

ICL uses S3, a subset of Algol 68, as its standard systems programming
language (its main mainframe OS, VME, is written in it). They stripped it down
to make it a pure stack language, but retained the type system - including the
gruesome coercions, which almost make C casts look elegant. On their 2900
series architecture it goes pretty fast - there have been ICL and third-party
compilers for languages with better reputations for efficiency, like Pascal,
Fortran and C, but none of them come near S3 for speed.
-- 
ARPA: jack%cs.glasgow.ac.uk@nss.cs.ucl.ac.uk       USENET: jack@cs.glasgow.uucp
JANET:jack@uk.ac.glasgow.cs      useBANGnet: ...mcvax!ukc!cs.glasgow.ac.uk!jack
Mail: Jack Campin, Computing Science Dept., Glasgow Univ., 17 Lilybank Gardens,
      Glasgow G12 8QQ, SCOTLAND     work 041 339 8855 x 6045; home 041 556 1878