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

Martin Ward <martin@gkc.org.uk> writes:
>On 20/03/18 09:06, Anton Ertl wrote:
>> Higher-order functions (I somehow mixed up "higher-order" with
>> "first-class" in the above) were already available in IPL, before
>> Algol 60, which falsifies this theory for this feature.
>
>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.


In any case, I think this attitude is still present.


>The second part of the theory is that since that time,
>the attitude has changed and "language designers have become
>very cautious and timid in specifying powerful new language features
>and compiler research has stagnated."


And I think that this is not the case. It's just that hardly any new
language features and languages achieve popularity (and those that do
take a long time). Admittedly that feeds back to discourage some from
going there, but language design is far too fascinating to let that
discourage everyone. E.g., Christian Heinlein is doing interesting
things with flexible syntax <http://flexipl.info/tutorial/>.


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


>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?-) Such languages are developed in significant
numbers: Take a look at
<https://en.wikipedia.org/wiki/Esoteric_programming_language>.


>A related, and more worrying, trend is the new and growing area
>of research under the heading "empirical software engineering"
>which aims to do away with program semantics altogether.
>A program is deemed "correct" if and only if it passes its test suite.


Sounds to me like test-driven development. Not really new, however.
I heard about it in a talk by Kent Beck 20 years ago.


>Various automated and semi-automated ways of modifying the program
>are being investigated: any modification which passes the test suite
>is deemed to be "correct". For example, "empirical slicing"
>may be defined as "delete random sections of code and call the result
>a valid slice if it passes the regression test". Program semantics
>and program analysis are considered to be "too difficult"
>by these researchers, and therefore are not attempted.


That's an interesting idea, if it exists (the things Google gave me
when I asked for "empirical slicing" or "empirical program slicing"
did not appear to fit your description). It may not be the direction
you favour, but it would be something new, wouldn't it?


Googling for "empirical software engineering" also does not give me
any hits that fit your description, either.


>Readers of comp.risks will no doubt already be wondering how
>such methods avoid introducing security holes: given that
>a security hole will not necessarily prevent the program
>from passing its test suite (unless the tests happen
>to include the carefully crafted data which triggers
>the security hole!) As far as I can tell, the answer is:
>they don't!


And neither did the waterfall model. I am not a security expert, but
AFAIK the old-fashioned way to get there are to be aware of security
issues during design and coding, and then doing a code audit.
However, there have been some successes in finding vulnerabilities
with fuzz testing, and with techniques based on automated theorem
provers.


- anton
--
M. Anton Ertl
anton@mips.complang.tuwien.ac.at
http://www.complang.tuwien.ac.at/anton/

Return to the comp.compilers page.
Search the comp.compilers archives again.