does anyone know what lang Dijkstra had in mind in the following quote?
“Another lesson we should have learned from the recent past is that
the development of 'richer' or 'more powerful' programming languages
was a mistake in the sense that these baroque monstrosities, these
conglomerations of idiosyncrasies, are really unmanageable, both
mechanically and mentally. I see a great future for very systematic and
very modest programming languages” — E W Dijkstra (1972)
Xah
···@xahlee.org
∑ http://xahlee.org/
Xah Lee <···@xahlee.org> wrote:
+---------------
| does anyone know what lang Dijkstra had in mind in the following quote?
|
| "Another lesson we should have learned from the recent past is that
| the development of 'richer' or 'more powerful' programming languages
| was a mistake in the sense that these baroque monstrosities, these
| conglomerations of idiosyncrasies, are really unmanageable, both
| mechanically and mentally. I see a great future for very systematic and
| very modest programming languages." -- E W Dijkstra (1972)
+---------------
Probably PL/I. In his classic little rant "How Do We Tell Truths
that Might Hurt" [EWD498, 1975] he calls PL/I "the fatal disease".
(FORTRAN, by comparison, gets off light, called only "the infantile
disorder".)
-Rob
p.s. In the same essay he also slams BASIC, COBOL, APL, and
perhaps, obliquely, Ada [though it is not clear that by June 1975
the HOLWG had made enough progress yet for much useful criticism]...
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
····@rpw3.org (Rob Warnock) writes:
> Probably PL/I. In his classic little rant "How Do We Tell Truths
> that Might Hurt" [EWD498, 1975] he calls PL/I "the fatal disease".
> (FORTRAN, by comparison, gets off light, called only "the infantile
> disorder".)
Is there any language (or parts of a language) that he liked?
--
David Magda <dmagda at ee.ryerson.ca>
Because the innovator has for enemies all those who have done well under
the old conditions, and lukewarm defenders in those who may do well
under the new. -- Niccolo Machiavelli, _The Prince_, Chapter VI
David Magda wrote:
> Is there any language (or parts of a language) that he [Dijkstra]
liked?
i'm wondering about the same thing...
what's is his general view of language design?
what langs today he would like or hate?
Xah
···@xahlee.org
∑ http://xahlee.org/
In his papers and books, Dijkstra often used "program notations" of his
own, usually varieties of the "Guarded Command Language". I'll try to
describe it, but I apologize to anyone truly educated in the Eindhoven
School if I misrepresent something.
In GCL, there are two basic constructs: do/od and if/fi. An if/fi block
contained a number of commands (statements), with for each command a
guard (predicate). A command can be seen as a function World -> World,
whereas a predicate is a function World -> Boolean.
An if/fi block non-deterministically executes one of the commands whose
guards hold. A do/od block is similar, except it repeats until none of
the guards hold.
Here is an example of a program in GCL:
{ x = X /\ y = Y }
do
x > y --> x := x - y
x < y --> y := y - x
od
{ x = GCD(X,Y) }
Note that GCL is a very stateful language. This has to do with the fact
that Dijkstra advocated a programming methodology that involved
detailed correctness proofs based on preconditions and postconditions
on the state of the world (usally written as predicates in curly
braces).
interesting...
though Dijkstra only died around 2000 or so, he must have expressed
opnions about languages that are in the mainstream today?
Xah
···@xahlee.org
∑ http://xahlee.org/
········@gmail.com wrote:
> In his papers and books, Dijkstra often used "program notations" of
his
> own, usually varieties of the "Guarded Command Language". I'll try to
> describe it, but I apologize to anyone truly educated in the
Eindhoven
> School if I misrepresent something.
>
> In GCL, there are two basic constructs: do/od and if/fi. An if/fi
block
> contained a number of commands (statements), with for each command a
> guard (predicate). A command can be seen as a function World ->
World,
> whereas a predicate is a function World -> Boolean.
>
> An if/fi block non-deterministically executes one of the commands
whose
> guards hold. A do/od block is similar, except it repeats until none
of
> the guards hold.
>
> Here is an example of a program in GCL:
>
> { x = X /\ y = Y }
> do
> x > y --> x := x - y
> x < y --> y := y - x
> od
> { x = GCD(X,Y) }
>
> Note that GCL is a very stateful language. This has to do with the
fact
> that Dijkstra advocated a programming methodology that involved
> detailed correctness proofs based on preconditions and postconditions
> on the state of the world (usally written as predicates in curly
> braces).
David Magda <··················@ee.ryerson.ca> writes:
> ····@rpw3.org (Rob Warnock) writes:
>
>> Probably PL/I. In his classic little rant "How Do We Tell Truths
>> that Might Hurt" [EWD498, 1975] he calls PL/I "the fatal disease".
>> (FORTRAN, by comparison, gets off light, called only "the infantile
>> disorder".)
>
> Is there any language (or parts of a language) that he liked?
From his 1972 Turing Award lecture, "The Humble Programmer":
The third project I would not like to leave unmentioned is LISP, a
fascinating enterprise of a completely different nature. With a few
very basic principles at its foundation, it has shown a remarkable
stability. Besides that, LISP has been the carrier for a
considerable number of in a sense our most sophisticated computer
applications. LISP has jokingly been described as "the most
intelligent way to misuse a computer". I think that description a
great compliment because it transmits the full flavour of
liberation: it has assisted a number of our most gifted fellow
humans in thinking previously impossible thoughts.
-Peter
--
Peter Seibel ·····@gigamonkeys.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
From: Joachim Durchholz
Subject: Re: a Dijkstra quote (what lang?)
Date:
Message-ID: <d6c5bo$mfg$1@online.de>
Peter Seibel wrote:
> David Magda <··················@ee.ryerson.ca> writes:
>
>> ····@rpw3.org (Rob Warnock) writes:
>>
>>> Probably PL/I. In his classic little rant "How Do We Tell Truths
>>> that Might Hurt" [EWD498, 1975] he calls PL/I "the fatal
>>> disease". (FORTRAN, by comparison, gets off light, called only
>>> "the infantile disorder".)
>>
>> Is there any language (or parts of a language) that he liked?
>
> From his 1972 Turing Award lecture, "The Humble Programmer":
>
> The third project I would not like to leave unmentioned is LISP, a
> fascinating enterprise of a completely different nature. With a few
> very basic principles at its foundation, it has shown a remarkable
> stability. Besides that, LISP has been the carrier for a considerable
> number of in a sense our most sophisticated computer applications.
> LISP has jokingly been described as "the most intelligent way to
> misuse a computer". I think that description a great compliment
> because it transmits the full flavour of liberation: it has assisted
> a number of our most gifted fellow humans in thinking previously
> impossible thoughts.
Note how carefully he picks those virtues of Lisp that are worth
praising. There are lots of dark and murky corners in Lisp that he'd
have less favorable words for, I think...
Regards,
Jo
Rob Warnock:
> Xah Lee <···@xahlee.org> wrote:
> | does anyone know what lang Dijkstra had in mind in the following quote?
> |
> | "Another lesson we should have learned from the recent past is that
> | the development of 'richer' or 'more powerful' programming languages
> | was a mistake in the sense that these baroque monstrosities, these
> | conglomerations of idiosyncrasies, are really unmanageable, both
> | mechanically and mentally. I see a great future for very systematic and
> | very modest programming languages." -- E W Dijkstra (1972)
>
> Probably PL/I. In his classic little rant "How Do We Tell Truths
> that Might Hurt" [EWD498, 1975] he calls PL/I "the fatal disease".
> (FORTRAN, by comparison, gets off light, called only "the infantile
> disorder".)
Algol68, if I remember well, was called "the capital punishment".
Well, anyway. Where are those modest and systematic languages with
great future?...
Jerzy Karczmarczuk
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
From: Joachim Durchholz
Subject: Re: a Dijkstra quote (what lang?)
Date:
Message-ID: <d6c50i$lpd$2@online.de>
Jerzy Karczmarczuk wrote:
> Well, anyway. Where are those modest and systematic languages with
> great future?...
Haskell?
... well, maybe lacking "great future", but it's certainly influential :-)
Regards,
Jo
"Jerzy Karczmarczuk" <·······@info.unicaen.fr> writes:
> > Xah Lee <···@xahlee.org> wrote:
>
> > | does anyone know what lang Dijkstra had in mind in the following quote?
> > |
> > | "Another lesson we should have learned from the recent past is that
> > | the development of 'richer' or 'more powerful' programming languages
> > | was a mistake in the sense that these baroque monstrosities, these
> > | conglomerations of idiosyncrasies, are really unmanageable, both
> > | mechanically and mentally. I see a great future for very systematic and
> > | very modest programming languages." -- E W Dijkstra (1972)
> Well, anyway. Where are those modest and systematic languages with
> great future?...
Scheme or Standard ML would fit the "very systematic and very modest
programming language" description, and both have been moderately
successful (though mainly in academia). Haskell (that someone else
mentioned) is certainly systematic, but hardly modest, unless you
compare to monsters like C++, Common LISP or PL/I.
I fear that once a language becomes mainstream, it quickly ceases to
be systematic or modest, as all sorts of external pressure from users
give rise to ad-hoc additions. At best, the language can remain
systematic, but modesty quickly fall by the wayside.
Torben
> does anyone know what lang Dijkstra had in mind in the following quote?
> [...] 'richer' or 'more powerful' programming languages [...]
Algol 68.
(Not to be confused with ALGOL-60.)
Juliusz Chroboczek wrote:
>
> (Not to be confused with ALGOL-60.)
I read his 1968 paper on semaphores and it contains numerous examples
in ALGOL-60 (with some slight modifications) and ALGOL-60-ish
pseudocode, so yeah... what was so different about Algol 68 then, that
he turned against it?
--
Charles Hoffman
Computer Science Student
Garage Musician sans garage
Harmless Eccentric
=^..^= =^..^= =^..^= =^..^=
From: Joachim Durchholz
Subject: Re: a Dijkstra quote (what lang?)
Date:
Message-ID: <d7keio$pmu$1@online.de>
Charles Hoffman wrote:
> Juliusz Chroboczek wrote:
>
>> (Not to be confused with ALGOL-60.)
>
> I read his 1968 paper on semaphores and it contains numerous examples
> in ALGOL-60 (with some slight modifications) and ALGOL-60-ish
> pseudocode, so yeah... what was so different about Algol 68 then, that
> he turned against it?
Algol 68 was vastly more powerful and complicated than Algol 60. It had
mandatory garbage collection, pointers, memory models, concurrency, and
a lot of other things that were considered advanced language concept at
that time.
There's some simlarity to the relationship between C and C++ here: the
new language was supposed to be the successor, but it was so laden with
new features that it was both a challenge for compiler writers to
implement and for programmers to learn.
I don't know why Dijkstra didn't like Algol 68, but I can imagine a
number of reasons. My personal criticism of the language would have been
premature inclusion of not yet well-understood language mechanisms...
but then Algol 68 was designed in a time when people tried to improve
languages by adding features to make them more expressive, so that kind
of fault is understandable. (Pascal was the better successor: it was
quite more powerful than Algol 60, but kept creeping featuritis under
control. The result was still a bit too restricted, but it was more
successful than Algol 68 anyway, and - IMHO - deservedly so.)
Regards,
Jo
Joachim Durchholz wrote:
>
> I don't know why Dijkstra didn't like Algol 68
He and others disliked it because it was much more complex than other
languages of the time, and because they thought that Van Wijngaarden &
Co's attempt to rigidly specify it was way over the top and
incomprehensible.
In retrospect I must say that I have much respect for the formal rigor
that Wijngaarden and his team achieved. Much of the Report looks like
modern inference rules translated into stylised prose. Considering that
the only formal tool for specifying PLs at the time was BNF for syntax
(invented for Algol 60) that is quite amazing.
Also, many original ideas developed for Algol 68 re-surfaced much later
in other languages. E.g. like today's FPLs it got rid of statements as a
concept separate from expressions. It had true closures with lexical
scoping (unlike early Lisp). Its idea of properly separating reference
types is pretty similar to what was later put into ML (although Algol's
automatic dereferencing conversion was a step to far). It was the first
language with a proper algebraic type structure etc etc.
IMHO, although there were objective mistakes, Algol 68 was primarily
doomed by appearing too much ahead of its time - computer and
compilation technology wasn't yet ready to handle it. Neither were
people. Pascal suited the needs better, although it was a rather boring
language with only minor improvements over Algol 60 and no proper
specification whatsoever (Wirth's languages were always defined by
implementation).
- Andreas
--
Andreas Rossberg, ········@ps.uni-sb.de
Let's get rid of those possible thingies! -- TB
Andreas Rossberg <········@ps.uni-sb.de> writes:
[Re: Algol-68]
> It had true closures with lexical scoping (unlike early Lisp).
Hmmm. I thought Scheme introduced true closures. My impression (all
from secondary sources) is that Algol-68 had "downwards funargs" but
not "upwards". That is, you couldn't return a closure out of the scope
in which the closed over binding was created. Am I wrong about that?
-Peter
--
Peter Seibel ·····@gigamonkeys.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel wrote:
>
> Hmmm. I thought Scheme introduced true closures. My impression (all
> from secondary sources) is that Algol-68 had "downwards funargs" but
> not "upwards". That is, you couldn't return a closure out of the scope
> in which the closed over binding was created. Am I wrong about that?
No, I think you are right, my mistake. Full closures were considered
during the design process, but the final language indeed contained some
scope restrictions for environments of 1st-class procedures, because the
committee wanted to keep Algol a "stack-based" language. I recall from
Lindsey's HOPL article that committee members strongly argued against
that restriction, though. So at least the idea was there.
Of course, "downward funargs" already were quite an achievement at the
time. There are well-known major languages that don't even have them
today...
--
Andreas Rossberg, ········@ps.uni-sb.de
Let's get rid of those possible thingies! -- TB
Andreas Rossberg wrote:
> Peter Seibel wrote:
>
>>
>> Hmmm. I thought Scheme introduced true closures. My impression (all
>> from secondary sources) is that Algol-68 had "downwards funargs" but
>> not "upwards". That is, you couldn't return a closure out of the scope
>> in which the closed over binding was created. Am I wrong about that?
>
>
> No, I think you are right, my mistake. Full closures were considered
> during the design process, but the final language indeed contained some
> scope restrictions for environments of 1st-class procedures, because the
> committee wanted to keep Algol a "stack-based" language. I recall from
> Lindsey's HOPL article that committee members strongly argued against
> that restriction, though. So at least the idea was there.
Regarding the idea already being there: Algol-60 already had lexical
block structure, but no support for function-returning functions.
The idea of such functions and the semantics of languages which included
them was described by Peter Landin in some papers circa 1963-1965, such
as "Correspondence between ALGOL 60 and Church's Lambda-notation"[1],
and "The next 700 programming languages"[2]. The latter described
ISWIM, a functional language based on lambda calculus. The associated
virtual machine which Landin described, the SECD machine[3], supported
full closures in its instruction set.
Around 1968, Landin was a member of the committee which oversaw the
authors of the Revised Report on the Algorithmic Language Algol 68, so
any discussion of full closures would presumably have been informed by
his work.
Anton
[1] http://portal.acm.org/citation.cfm?id=363749
[2] http://portal.acm.org/citation.cfm?doid=365230.365257
[3] http://en.wikipedia.org/wiki/SECD_machine
In article <··············@hades.rz.uni-saarland.de>, Andreas Rossberg wrote:
>
> He and others disliked it because it was much more complex than
> other languages of the time, and because they thought that Van
> Wijngaarden & Co's attempt to rigidly specify it was way over the
> top and incomprehensible.
I know that John Reynolds (in "The Essence of ALGOL") preferred Algol
60 to its successors because it had a stronger equational theory,
arising from the fact that it was call-by-name and its successors
(such as ALGOL 68 and Pascal) were call-by-value.
Idealized Algol has a really wickedly strong phase separation
property; there's no mixing of the imperative and functional
sublanguages' operational semantics -- you can evaluate an IA of type
command by first, beta-reducing away all of the redexes, and then in a
subsequent phase evaluating using the rules of the simple
procedure-free imperative language (a la Hoare logic). Matthias
Felleisen and Stephen Weeks formalized this idea in their paper
"Orthogonality of Procedures and Assignments in ALGOL".
--
Neel Krishnaswami
·····@cs.cmu.edu
Andreas Rossberg <········@ps.uni-sb.de> writes:
> Pascal suited the needs better, although it was a rather
> boring language with only minor improvements over Algol 60 and no
> proper specification whatsoever (Wirth's languages were always defined
> by implementation).
I wish all implementation-defined languages were as little specified
as Wirth's languages... If you stopped to think two seconds, you
could notice that there always^W have been several^W a lot of
implementations/ers of Wirth languages.
The Programming Language Pascal (Revised Report)
1972 -- Niklaus Wirth
http://www.fh-jena.de/~kleine/history/languages/Wirth-PascalRevisedReport.pdf
The Programming Language Modula-2
Niklaus Wirth
Report on the Programming Language Modula-2
Fourth Edition
1988 Springer Verlag
http://www.unet.univie.ac.at/~a9406973/modula2/report4/modula-2.html
http://www.fh-jena.de/~kleine/history/languages/Wirth-Modula2.pdf
The Programming Language Oberon-2
H. M�ssenb�ck, N. Wirth
Institut f�r Computersysteme, ETH Z�rich
October 1993
http://statlab.uni-heidelberg.de/projects/oberon/kurs/www/Oberon2.Report.html
Object Pascal Report
Larry Tesler
in Structured Language World 9(3) 1985
--
__Pascal Bourguignon__ http://www.informatimago.com/
In a World without Walls and Fences,
who needs Windows and Gates?
Pascal Bourguignon wrote:
>
>>Pascal suited the needs better, although it was a rather
>>boring language with only minor improvements over Algol 60 and no
>>proper specification whatsoever (Wirth's languages were always defined
>>by implementation).
>
> I wish all implementation-defined languages were as little specified
> as Wirth's languages... If you stopped to think two seconds, you
> could notice that there always^W have been several^W a lot of
> implementations/ers of Wirth languages.
OK, maybe I should clarify what I mean by "proper": a rigid
specification of semantics. Wirth's reports don't make anything precise
beyond syntax, and hence leave many holes and guesswork to do with
respect to semantics. I remember reading that Wirth, when asked what
this or that program snippet should do, himself proposed to look at the
implementation (sorry, no reference). In that respect, I clearly
consider Algol 68 superior.
I agree, though, that the situation is still better than with most other
`implementation-defined' languages...
--
Andreas Rossberg, ········@ps.uni-sb.de
Let's get rid of those possible thingies! -- TB