Related articles |
---|
Re: language design after Algol 60, was Add nested-function support martin@gkc.org.uk (Martin Ward) (2018-03-27) |
Re: language design after Algol 60, was Add nested-function support anton@mips.complang.tuwien.ac.at (2018-03-30) |
Re: language design after Algol 60, was Add nested-function support martin@gkc.org.uk (Martin Ward) (2018-04-06) |
Re: language design after Algol 60, was Add nested-function support derek@_NOSPAM_knosof.co.uk (Derek M. Jones) (2018-04-08) |
Re: language design after Algol 60, was Add nested-function support gneuner2@comcast.net (George Neuner) (2018-04-09) |
Re: language design after Algol 60, was Add nested-function support anton@mips.complang.tuwien.ac.at (2018-04-10) |
Re: language design after Algol 60, was Add nested-function support derek@_NOSPAM_knosof.co.uk (Derek M. Jones) (2018-04-10) |
[19 later articles] |
From: | Martin Ward <martin@gkc.org.uk> |
Newsgroups: | comp.compilers |
Date: | Mon, 19 Mar 2018 11:04:20 +0000 |
Organization: | Compilers Central |
References: | <6effed5e-6c90-f5f4-0c80-a03c61fd2127@gkc.org.uk> 18-03-042 18-03-047 |
Injection-Info: | gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="62261"; mail-complaints-to="abuse@iecc.com" |
Keywords: | algol60, history, design |
Posted-Date: | 19 Mar 2018 07:16:34 EDT |
On 13/03/18 03:02, Kaz Kylheku wrote:
> That's because machines have gotten faster and memories bigger!
>
> Perversely, when memories get bigger, all the interesting stuff
> gets a lot slower, because it has exponential complexity.
Faster machines and larger memories mean that it becomes more
important to use the best algorithms. The best algorithms
are often more complex than less efficient algorithms:
which means that it is *more* important to have powerful
languages in which it is easier to define complex algorithms.
So the need for more powerful languages has only increased over time.
On 14/03/18 15:16, Anton Ertl wrote:
>> The result was an explosion of productive research and development
>> in compilers and language implementation.
>
> Is it really productive to research and develop a feature that turns
> out to be a dead end? Even the closest thing to call-by-name these
> days, call-by-need in lazy functional languages, does not use the
> techniques developed by call-by-name.
Actually, the closest thing to call-by-name is first class functions
(technically: downward funargs). The desire for mathematical
simplicity over implementation simplicity drove the choice
of call by name over call by reference. Call by name allowed
Jenson's Device which is a method of passing a function as a parameter.
Call by name turned out to be implementable by, in effect,
passing a function as a parameter.
Of course, with hindsight we can see that defining function parameters
directly in the language would be an even better solution:
but language design was still in its early days at the time,
and Algol 60 was "not only an improvement on its predecessors,
but also on nearly all its successors" (C.A.R. Hoare).
How many modern languages can claim the same?
> Algol 60 did not have first-order functions and closures. It did have
> lexical scoping, though, which the Lisp family only acquired with
> Scheme in 1975.
>
> Algol 60 certainly did not have abstract data types. It did not even
> have records.
>
> So these are examples that actually contradict your theory.
My theory is that the attitude of the Algol 60 designers towards
language design is what led to these innovations appearing
over then next 20 years: this is the "explosion of productive
research and development in compilers and language implementation"
that I was referring to.
What similar innovations in compilers and language design
have appeared over the *last* 20 years? (Haskill is still considered
by some to be a scary new innovative language: it was initially
developed in the early 1990's, over 20 years ago).
--
Martin
Dr Martin Ward | Email: martin@gkc.org.uk | http://www.gkc.org.uk
G.K.Chesterton site: http://www.gkc.org.uk/gkc | Erdos number: 4
Return to the
comp.compilers page.
Search the
comp.compilers archives again.