Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.compilers > #2032

Re: language design after Algol 60, was Add nested-function support

From Martin Ward <martin@gkc.org.uk>
Newsgroups comp.compilers
Subject Re: language design after Algol 60, was Add nested-function support
Date 2018-04-06 16:09 +0100
Organization Compilers Central
Message-ID <18-04-002@comp.compilers> (permalink)
References (2 earlier) <18-03-042@comp.compilers> <18-03-047@comp.compilers> <18-03-075@comp.compilers> <18-03-079@comp.compilers> <18-03-101@comp.compilers>

Show all headers | View raw


On 30/03/18 15:20, Anton Ertl wrote:
>> The theory is that "the attitude of the Algol 60 designers towards
>> language design is what led to these innovations appearing".
>> Clearly, this "attitude" was present before, during and after
>> the development of Algol 60.
> Ok, so this theory cannot even be verified of falsified for the
> features that came before Algol 60.

John asked us to speculate what might have happened differently,
not produce empirically verifiable theories :-)

I came across this quote the other day, which suggests that the change
in attitude had already started by 1979:

"The call-by-name mechanism is so expensive that modern languages
have mostly dropped it in favour of the semantically different,
but operationally more efficient, call-by-reference"
--"Understanding and Writing Compilers", Richard Bornat, Macmillan 1979.

Note that the

>> It should be easy to falsify the theory: where are the new language
>> features that have been invented in the last, say, twenty years?
>
> I mentioned some things in the grandfather posting.  Do you want me to
> repeat them?

You mentioned generics and lambdas, both of which you acknowledge
have been around for a long time: lambdas have been around
since the original Lisp!

You also mentioned combining static type checking with explicit
memory management: again two features which have been around
for decades.  One might ask: why earth we still need explicit memory
management in this day and age? Because it is more efficient
to implement?  Doesn't that prove what I have been saying all along?

Re "empirical software engineering", I apologise that I mis-remembered
the term used and sent you on a wild goose chase. :-(
"Search based software engineering" might be a more accurate term.
Two examples are:

"Observation Based" or "Language Independent" program slicing
involves deleting random chunks of code and then compiling
and re-testing the result (if possible) to see if it is
a "valid" slice (where a "valid" slice is defined as
"one which passes the test suite"):

http://coinse.kaist.ac.kr/publications/pdfs/Binkley2014ud.pdf

"Automated Software Transplantation" involves copying random blocks
of code from one program to another and testing if the resulting
program still "works" (ie passes its test suite) and also
contains some functionality from the other program
(eg it can now handle a new file format).

http://crest.cs.ucl.ac.uk/autotransplantation/downloads/autotransplantation.pdf

https://motherboard.vice.com/en_us/article/bmj9g4/muscalpel-is-an-algorithmic-code-transplantation

> It may not be the direction
> you favour, but it would be something new, wouldn't it?

It is like introducing alchemy into the chemistry department:
let's forget all the theory and all the maths and just smush
random chemicals together and see what happens!
Yes, it's something new, and no, it's not a direction I favour.

>> Where are the powerful new languages which make Haskell
>> look like Dartmouth BASIC?
>
> You mean a language that is even harder to learn and even less
> practical than Haskell?-)

Modern popular languages are neither powerful nor easy to learn.
The latest C standard is over 700 pages (even the Haskell Language
Report is only 329 pages!). In the pursuit of efficiency over
everything, C leaves so many operations "undefined" (there are
around 199 examples of undefined behaviour) that simply
writing a piece of code to carry out twos-complement arithmetic
(in a fully standards-complient manner) is a challenge
to tax the most experienced programmers: and probably compiles
into very inefficient object code even on a processor which has
native twos complement arithmetic operations!

https://wiki.sei.cmu.edu/confluence/display/c/INT32-C.+Ensure+that+operations+on+signed+integers+do+not+result+in+overflow

For C++ there is the SafeInt class which tries to do this:
but examples of undefined behaviour were detected in that library,
which caused it to give incorrect results on some compilers:

http://www.cs.utah.edu/~regehr/papers/overflow12.pdf

One effect of the increases in memory size and CPU speed over
the decades is that it allows programmers to write much larger
programs and implement solutions to much more complex problems.
This makes mastering complexity far more important.
A language which is an order of magnitude more powerful
would mean that programmers need to write and comprehend
an order of magnitude less code: and each individual programmer
or small team could work on problems which are an order of
magnitude more complex. If this language takes an order of magnitude
longer to learn and fully understand, then it is still worth it!

Unfortunately, this flies in the face of modern business practice
where "programmers" are a cheap resource to be hired and put to work
generating lines of code.

--
			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

Back to comp.compilers | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

Re: Add nested-function support in a language the based on a stack-machine Martin Ward <martin@gkc.org.uk> - 2018-03-12 16:17 +0000
  Re: Add nested-function support in a language the based on a stack-machine Kaz Kylheku <157-073-9834@kylheku.com> - 2018-03-13 03:02 +0000
    Re: Add nested-function support in a language the based on a stack-machine Martin Ward <martin@gkc.org.uk> - 2018-03-19 11:04 +0000
      Re: Add nested-function support in a language the based on a stack-machine Gene Wirchenko <genew@telus.net> - 2018-03-19 12:50 -0700
        Re: Add nested-function support in a language the based on a stack-machine Kaz Kylheku <157-073-9834@kylheku.com> - 2018-03-20 16:16 +0000
        Re: Add nested-function support in a language the based on a stack-machine Martin Ward <martin@gkc.org.uk> - 2018-03-23 10:44 +0000
          Re: algorithm performance, was Add nested-function support in a language the based on a stack-machine Andy Walker <anw@cuboid.co.uk> - 2018-03-23 18:47 +0000
            Re: algorithm performance, was Add nested-function support in a language the based on a stack-machine anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2018-03-24 14:06 +0000
              Re: algorithm performance, was Add nested-function support in a language the based on a stack-machine rpw3@rpw3.org (Rob Warnock) - 2018-03-25 07:02 +0000
                Re: algorithm performance "Robin Vowels" <robin51@dodo.com.au> - 2018-03-27 01:22 +1100
          Re: sorting performance, Add nested-function support in a language the based on a stack-machine w.clodius@icloud.com (William Clodius) - 2018-03-24 23:25 -0600
      Re: Add nested-function support in a language the based on a stack-machine anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2018-03-20 09:06 +0000
        Re: Add nested-function support in a language the based on a stack-machine Bill Findlay <findlaybill@blueyonder.co.uk> - 2018-03-20 12:49 +0000
        Re: language design after Algol 60, was Add nested-function support Martin Ward <martin@gkc.org.uk> - 2018-03-27 14:46 +0100
          Re: language design after Algol 60, was Add nested-function support anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2018-03-30 14:20 +0000
          Re: language design after Algol 60, was Add nested-function support Martin Ward <martin@gkc.org.uk> - 2018-04-06 16:09 +0100
            Re: language design after Algol 60, was Add nested-function support "Derek M. Jones" <derek@_NOSPAM_knosof.co.uk> - 2018-04-08 14:21 +0100
              Re: language design after Algol 60, was Add nested-function support George Neuner <gneuner2@comcast.net> - 2018-04-09 16:51 -0400
                Re: language design after Algol 60, was Add nested-function support anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2018-04-10 05:48 +0000
                Re: language design after Algol 60, was Add nested-function support George Neuner <gneuner2@comcast.net> - 2018-04-10 14:32 -0400
                Re: language design after Algol 60, was Add nested-function support Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2018-04-12 01:09 +0200
                Re: language design after Algol 60, was Add nested-function support bartc <bc@freeuk.com> - 2018-04-12 11:51 +0100
                Re: language design after Algol 60, was Add nested-function support bartc <bc@freeuk.com> - 2018-04-12 19:40 +0100
                Re: language design after Algol 60, was Add nested-function support Martin Ward <martin@gkc.org.uk> - 2018-04-13 14:10 +0100
                Re: language design after Algol 60 "Robin Vowels" <robin51@dodo.com.au> - 2018-04-14 14:11 +1000
                RE: language design after Algol 60 "Costello, Roger L." <costello@mitre.org> - 2018-04-16 12:56 +0000
                Re: language design after Algol 60 "Robin Vowels" <robin51@dodo.com.au> - 2018-04-17 19:08 +1000
                Re: Language design after Algol 60 "Robin Vowels" <robin51@dodo.com.au> - 2018-04-18 14:58 +1000
                Re: language design after Algol 60 Gene Wirchenko <genew@telus.net> - 2018-04-18 16:12 -0700
                Re: language design after Algol 60 Martin Ward <martin@gkc.org.uk> - 2018-05-01 10:42 +0100
                Re: language design after Algol 60 "Robin Vowels" <robin51@dodo.com.au> - 2018-04-14 14:19 +1000
                Re: language design after Algol 60 bartc <bc@freeuk.com> - 2018-04-14 20:43 +0100
                Re: language design after Algol 60 Andy Walker <anw@cuboid.co.uk> - 2018-04-15 00:04 +0100
                Re: language design after Algol 60, was Add nested-function support rpw3@rpw3.org (Rob Warnock) - 2018-04-12 14:05 +0000
                Re: language design after Algol 60, was Add nested-function support George Neuner <gneuner2@comcast.net> - 2018-04-12 20:51 -0400
                Re: OOP language design after Algol 60, was Add nested-function support Kaz Kylheku <157-073-9834@kylheku.com> - 2018-04-13 03:22 +0000
                Re: OOP language design after Algol 60, was Add nested-function support Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2018-04-13 10:22 +0200
                Re: OOP language design after Algol 60, was Add nested-function support George Neuner <gneuner2@comcast.net> - 2018-04-14 13:40 -0400
                Re: OOP language design after Algol 60, was Add nested-function support Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2018-04-15 00:12 +0200
                Re: OOP language design after Algol 60, was Add nested-function support Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2018-04-15 00:23 +0200
                Re: language design after Algol 60, was Add nested-function support "Derek M. Jones" <derek@_NOSPAM_knosof.co.uk> - 2018-04-10 13:15 +0100
                Re: language design after Algol 60, was Add nested-function support Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2018-04-11 13:27 +0200
                Re: language design after Algol 60, was Add nested-function support "Derek M. Jones" <derek@_NOSPAM_knosof.co.uk> - 2018-04-11 20:06 +0100
                Re: language design after Algol 60, was Add nested-function support Kaz Kylheku <157-073-9834@kylheku.com> - 2018-04-10 18:32 +0000
                Re: language design after Algol 60, was Add nested-function support George Neuner <gneuner2@comcast.net> - 2018-04-12 20:57 -0400
                Re: OOP language design after Algol 60, was Add nested-function support Kaz Kylheku <157-073-9834@kylheku.com> - 2018-04-13 03:28 +0000
            Re: language design after Algol 60, was Add nested-function support albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2018-05-05 13:50 +0200
      Re: Add nested-function support in a language the based on a stack-machine mac <acolvin@efunct.com> - 2018-03-20 15:27 +0000
  Re: Add nested-function support in a language the based on a stack-machine w.clodius@icloud.com (William Clodius) - 2018-03-12 21:09 -0600
    Re: Add nested-function support in a language the based on a stack-machine Kartik Agaram <ak@akkartik.com> - 2018-03-13 13:27 -0700
      Re: Add nested-function support in a language the based on a stack-machine Kaz Kylheku <157-073-9834@kylheku.com> - 2018-03-14 00:07 +0000
        Re: Add nested-function support in a language the based on a stack-machine Kartik Agaram <ak@akkartik.com> - 2018-03-13 22:31 -0700
          Re: Add nested-function support in a language the based on a stack-machine Kaz Kylheku <157-073-9834@kylheku.com> - 2018-03-14 14:49 +0000
    Re: Add nested-function support in a language the based on a stack-machine Kaz Kylheku <157-073-9834@kylheku.com> - 2018-03-13 20:51 +0000
    Re: Add nested-function support in a language the based on a stack-machine Andy Walker <anw@cuboid.co.uk> - 2018-03-14 00:27 +0000
      Re: Add nested-function support in a language the based on a stack-machine Andy Walker <anw@cuboid.co.uk> - 2018-03-14 16:37 +0000
  Re: Add nested-function support in a language the based on a stack-machine anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2018-03-14 15:16 +0000

csiph-web