Re: The 1980 ACM Turing Award Lecture The Emperor's Old Clothes

Re: The 1980 ACM Turing Award Lecture The Emperor's Old Clothes

[Gautier direct_replies_not_read]

Lyle McKennot:

>How about the  1980 ACM Turing Award lecture "The Emperor's Old
>Clothes" ?

Thank you, _that's_ a nice troll for today!

(however, it's amusing to read it with today's eyes,
especially what happened to the minimalist creations
coming from ivory towers)

________________________________________________________
Gautier  --  http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, address on the Web site!

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.

Re: The 1980 ACM Turing Award Lecture The Emperor's Old Clothes

[Lyle McKennot]

"Gautier direct_replies_not_read" <gautier_niouzes@hotmail.com> wrote:
 
>>How about the  1980 ACM Turing Award lecture "The Emperor's Old
>>Clothes" ?
 
>(however, it's amusing to read it with today's eyes,
>especially what happened to the minimalist creations
>coming from ivory towers)

Hoare's own CSP did become very influential though.

It is the third most cited computer science reference listed by
ResearchIndex. 

See:http://citeseer.nj.nec.com/articles.html

Re: The 1980 ACM Turing Award Lecture The Emperor's Old Clothes

[Gautier]

> >(however, it's amusing to read it with today's eyes,
> >especially what happened to the minimalist creations
> >coming from ivory towers)

Lyle McKennot:

> Hoare's own CSP did become very influential though.
> 
> It is the third most cited computer science reference listed by
> ResearchIndex. 

Hopefully, good ideas come from ivory towers!
The issue is the concretisation.

Back to the lecture: what is better for whom (language creators
or programmers) ?

 (1) a large language that one can subset if needed
 (2) a small language that one can extend if needed

For using (1) the design has to be excellent.
Making (1) is completely out of reach of the "ivory tower".
The obvious weakness of (2) is the incompatibility
between extensions and standard libraries.

________________________________________________________
Gautier  --  http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, address on the Web site!

Re: The 1980 ACM Turing Award Lecture The Emperor's Old Clothes

[Peter Amey]

Gautier direct_replies_not_read wrote:
> 
> Lyle McKennot:
> 
> >How about the  1980 ACM Turing Award lecture "The Emperor's Old
> >Clothes" ?
> 
> Thank you, _that's_ a nice troll for today!
> 
> (however, it's amusing to read it with today's eyes,
> especially what happened to the minimalist creations
> coming from ivory towers)
> 

The paper was an influence on the decision to create SPARK.  As the good
Professor Hoare observed there really is a nice, simple, secure language
hiding inside Ada.  It is also a tribute to Ada's designers that the
creation of SPARK was possible; there is no comparable language lurking
within C++ for example.

Peter

ada paper critic

[Immanuel Scholz]

Hi,

I am searching for a book or a paper which tend to explain the negative 
aspects on ada.

I am writing on a report of the usability of several programming languages 
and up to now, I came out with the fact, that ada seems to get all the good 
honey, letting only rubbish to other languages ;-)

So are there any papers about the "great disadvantages" of ada? (There have 
to be disadvantages, right?)


Immanuel Scholz

Re: ada paper critic

[Immanuel Scholz]

> I am searching for a book or a paper which tend to explain the negative
> aspects on ada.

Uh, maybe I should add, that my criteria are: stability of the resulting 
code, rapid coding and speed of the resulting code (in that order). 

The code should be used in large, distributed applications.

Any comments speaking against ada? (and, as example in favor of java or 
c++?)

Immanuel Scholz

Re: ada paper critic

[John R. Strohm]

You are doomed to disappointment.

Ada code is extremely stable, far more so than just about any other
language, because of the comparatively more rigorous semantic model under
the language.

Speed of the code is comparable to, or better than, just about everything
else except perhaps a highly optimizing FORTRAN compiler that can play fast
and loose with the intent of the source code.  An Ada compiler can assume
that certain kinds of aliasing (for instance) don't happen, because the
language forbids those constructs.  C compilers can make no such
assumptions.

Rapid coding is a red herring, and everyone knows it.  Code in haste, repent
at leisure.

"Immanuel Scholz" <news@kutzsche.net> wrote in message
news:aebgq8$5goi4$1@ID-100557.news.dfncis.de...
> > I am searching for a book or a paper which tend to explain the negative
> > aspects on ada.
>
> Uh, maybe I should add, that my criteria are: stability of the resulting
> code, rapid coding and speed of the resulting code (in that order).
>
> The code should be used in large, distributed applications.
>
> Any comments speaking against ada? (and, as example in favor of java or
> c++?)
>
> Immanuel Scholz
>

The 1980 ACM Turing Award Lecture The Emperor's Old Clothes

[Lyle McKennot]

"John R. Strohm" <strohm@airmail.net> wrote:

>You are doomed to disappointment.

How about the  1980 ACM Turing Award lecture "The Emperor's Old
Clothes" ?

After all, it was that scathing attack by Hoare that made a lot of
people in the academic community abandon Ada.

It is still available at :

http://lambda.cs.yale.edu/cs422/doc/hoare.pdf

Re: The 1980 ACM Turing Award Lecture The Emperor's Old Clothes

[Ted Dennison]

Lyle McKennot wrote:
> "John R. Strohm" <strohm@airmail.net> wrote:
> 
> 
>>You are doomed to disappointment.
> 
> 
> How about the  1980 ACM Turing Award lecture "The Emperor's Old
> Clothes" ?

The main problem with that is that Ada was not finalized until 1985. 
Hoare's comments were made about a very preliminary version of the 
language. Not only did Ada get 5 more years of development after that, 
but it then got a major revision in 1995. So that lecture isn't at all 
about the language we today know as Ada.

Re: The 1980 ACM Turing Award Lecture The Emperor's Old Clothes

[Ed Falis]

Ted Dennison wrote:
> Lyle McKennot wrote:

>> How about the  1980 ACM Turing Award lecture "The Emperor's Old
>> Clothes" ?
> 
> 
> The main problem with that is that Ada was not finalized until 1985. 
> Hoare's comments were made about a very preliminary version of the 
> language. Not only did Ada get 5 more years of development after that, 
> but it then got a major revision in 1995. So that lecture isn't at all 
> about the language we today know as Ada.
> 

Further, Hoare praised Ada a few years later in the Foreword he wrote to 
an Ada textbook - anyone remember the specific book (Wegner)?

- Ed

Re: The 1980 ACM Turing Award Lecture The Emperor's Old Clothes

[Pat Rogers]

"Ed Falis" <efalis@attbi.com> wrote in message news:3D0B4750.90509@attbi.com...
> Ted Dennison wrote:
> > Lyle McKennot wrote:
>
> >> How about the  1980 ACM Turing Award lecture "The Emperor's Old
> >> Clothes" ?
> >
> >
> > The main problem with that is that Ada was not finalized until 1985.
> > Hoare's comments were made about a very preliminary version of the
> > language. Not only did Ada get 5 more years of development after that,
> > but it then got a major revision in 1995. So that lecture isn't at all
> > about the language we today know as Ada.
> >
>
> Further, Hoare praised Ada a few years later in the Foreword he wrote to
> an Ada textbook - anyone remember the specific book (Wegner)?


> > Lyle McKennot wrote:
>
> >> How about the  1980 ACM Turing Award lecture "The Emperor's Old
> >> Clothes" ?
<snip>
>
> Further, Hoare praised Ada a few years later in the Foreword he wrote to
> an Ada textbook - anyone remember the specific book (Wegner)?

From the foreword by C.A.R. Hoare to a book titled "Ada Language and
 Methodology" by David Watt, Brian Wichman and William Findlay, published by
Prentice-Hall International, 1987:

'I enjoyed reading the Algol 60 report; it taught me a lot about programming.'
This is the comment of a data processing manager of a major motor manufacturing
company, who had no conceivable prospect of ever using the language to program a
computer.  It is a most perceptive comment, because it describes an important
goal in the design of a new programming language: that it should be an aid in
specification, description, and design of programs, as well as in the
construction of reliable code.

This is one of the main aims in the design of the language which was later given
the name Ada.  As a result, the language incorporates many excellent structural
features which have proved their value in many precursor languages such as
Pascal and Pascal Plus.

The combination of many complex features into a single language has led to an
unfortunate delay in availability of production-quality implementations.  But
the long wait is coming to an end, and one can now look forward to a rapid and
widespread improvement in programming practice, both from those who use the
language and from those who study its concepts and structures.

I hope that this book will contribute directly to these ideals, which have
inspired many of the other books in the same series.  It continues the tradition
of the series in that it describes how the language can be used as the target of
a sound programming methodology, embracing the full life cycle of a programming
project.  It explains not just the features and details of the language, but
also their purpose and method of effective use.

The complexities and difficulties are not glossed over; they are explained
within the appropriate context, with hints on how to avoid any consequent
problems.  I hope the book will be useful, both to those who have the privilege
or obligation to use the language, and to those who have the interest and
curiosity to understand and appreciate its rationale.

---
Patrick Rogers                       Consulting and Training in:
http://www.classwide.com          Real-Time/OO Languages
progers@classwide.com               Hard Deadline Schedulability Analysis
(281)648-3165                                 Software Fault Tolerance

Re: The 1980 ACM Turing Award Lecture The Emperor's Old Clothes

[Jeffrey Carter]

Ted Dennison wrote:
> 
> Lyle McKennot wrote:
> >
> > How about the  1980 ACM Turing Award lecture "The Emperor's Old
> > Clothes" ?
> 
> The main problem with that is that Ada was not finalized until 1985.
> Hoare's comments were made about a very preliminary version of the
> language. Not only did Ada get 5 more years of development after that,
> but it then got a major revision in 1995. So that lecture isn't at all
> about the language we today know as Ada.

I would like to dispel some misinformation here. Hoare's comments were
about a draft version of Ada 80, which was essentially unused even after
the final version (MIL-STD-1815) was produced in 1980 Dec. Recognizing
many problems with the language definition, including some addressed by
Hoare and many obtained from a public comment effort, the design team
revised the language, resulting in Ada 83 (ANSI/MIL-STD-1815A) in 1983
Feb. Ada 83 was and is widely used. This standard was accepted unchanged
as an ISO standard in 1987. The standard was again revised in 1995,
giving the current Ada, Ada 95.

So, Hoare's comments have nothing to do with the language we today call
Ada. Ada wasn't finalized in 1985, 1983, or even 1995, since an effort
is currently underway to revise the standard again.

-- 
Jeff Carter
"Go and boil your bottoms."
Monty Python & the Holy Grail

Re: The 1980 ACM Turing Award Lecture The Emperor's Old Clothes

[Wes Groleau]

> but it then got a major revision in 1995. So that lecture isn't at all
> about the language we today know as Ada.

It was about a language that did not exist at the time,
never existed in exactly that form, and which once
developed and used, eventually gathered empirical
evidence counter to Hoare's suppositions.

Besides, isn't "scathing attack" a bit of an exaggeration?

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: The 1980 ACM Turing Award Lecture The Emperor's Old Clothes

[Robert I. Eachus]

Lyle McKennot wrote:


> How about the  1980 ACM Turing Award lecture "The Emperor's Old
> Clothes" ?
> 
> After all, it was that scathing attack by Hoare that made a lot of
> people in the academic community abandon Ada.
> 
> It is still available at :
> 
> http://lambda.cs.yale.edu/cs422/doc/hoare.pdf


Have you even read (or heard) this speech, and if you have, have you 
tried to relate it to the current version of Ada?  If you had, you would 
realize that Tony's criticisms of Ada 80 were valid, most did not apply 
to Ada 83, and no one in their right mind would consider his remarks 
about Ada 80 to apply to Ada 95.  In fact you can probably recognize 
that Tony's arguments in certain areas prevailed.  Some features of Ada 
83 that were not important to all classes of users were moved to 
optional annexes, other annexes were added to deal with programming 
domains not considered in the design of Ada 80 or Ada 83.

In one sense Tony lost on exceptions.  But as the long discussion on 
exception arguments here have shown, Ada provides the necessary 
functionality to everyone, and provides some extensions to those who 
want to do more with them.  But in general, almost every Ada programmer 
agrees that exceptions are to be avoided.  Not as a language feature, 
but as evidence of a bad program.

Any program that raises Program_Error is badly broken, other than, of 
course, a compiler test that validates that Program_Error is raised and 
handled appropriately.  With modern computers, the only time anyone ever 
sees Storage_Error is when a newbie writes:  "Foo: String;"  Pretty soon 
even that won't be guaranteed to raise an exception, but I hope 
compilers will still provide warning messages. ;-)

Ada 80 had some serious problems.  For one thing it had too many 
predefined exceptions.  Most of these were gone from the Ada 83 
standard, but we still missed one (Numeric_Error).  That problem was 
actually fixed before the design of Ada 95 was started.  Another major 
problem was the order of elaboration rules.  I wrote a cute program 
which was a legal Ada 80 program if, and only if, Fermat's Last Theorem 
was true.  Ada 95 (and Ada 83) compilers are allowed to generate code 
that would raise Program_Error if FLT was false, and otherwise spent a 
very long time initializing. (Or you could turn off Elaboration_Check.) 
  Of course, if someone wants to, they can build a special check into 
their Ada 95 compiler which optimizes away the dependence on FLT.

The last is not humor, it is serious.  The change in the definition of 
what it means to execute an Ada program between Ada 83 and Ada 95 is 
very subtle, but important.  And Ada 95 compiler is allowed greater 
freedom in optimizing away truly useless code, and slightly less freedom 
to optimize away checks that have a real effect on the result of the 
program.

Is getting exceptions right very tough?  Yes.  But the right way to deal 
with that is in the langauge definition so that ordinary programmers can 
produce code that works without having to think about exceptions all the 
time.  (But you have to think about them during requirements analysis 
and the design process.  The Arianne 4 team did this right, the Arianne 
5 project did not redo the requirements analysis...)

Re: The 1980 ACM Turing Award Lecture The Emperor's Old Clothes

[Hyman Rosen]

Robert I. Eachus wrote:
 > But in general, almost every Ada programmer agrees that exceptions are to
> be avoided.  Not as a language feature, but as evidence of a bad program.

Really? I find this utterly astonishing. So almost every Ada program is
littered with error handling code interpenetrating the normal working logic?
Or do Ada programs ignore eror codes just like old C programs did?

Re: The 1980 ACM Turing Award Lecture The Emperor's Old Clothes

[Robert I. Eachus]

Hyman Rosen wrote:

 
> Really? I find this utterly astonishing. So almost every Ada program is
> littered with error handling code interpenetrating the normal working 
> logic?
> Or do Ada programs ignore eror codes just like old C programs did?


No.  Input output routines may need to do error checking, but that is 
not an exceptional occurrence, and is usually not treated as one.  The 
'Valid attribute in Ada 95 is a great enhancement to the language.  It 
makes validity checking for input much easier to do, and to do in the 
right way.

Most other cases where return values should be checked in C and are not, 
in Ada the checking is done by constraints on parameters well before the 
call.  If your code can cause one of those constraint checks to fail, it 
may be that you need to rethink what you are doing.

This propagation of validity in Ada means that putting constraints on 
values (and running with constraint checks turned on) can be faster in 
Ada than eliminating constraint checks.

As a sort of trivial example:

function Square_Root(X: in Natural) return Natural;

..does not need to do any internal checks, and will never raise an 
exception.  (With the possible exception of Storage_Error...) 
Similarly, a procedure declared:

procedure Foo(S: in out String);  -- will never cause a buffer overrun.

Of course, sometimes you need to use Ada.Strings.Bounded or 
Ada.Strings.Unbounded to get the correct semantic behavior.  But that is 
just an instance of a general Ada rule.  Using strong typing right 
eliminates a lot of errors, whether they are coding errors, compiler 
error messages, or potential exceptions.

I hope this is all preaching to the choir, but I fell this thread 
contains too much self-flagellation as it is, and some balance is needed.

 

Re: The 1980 ACM Turing Award Lecture The Emperor's Old Clothes

[Hyman Rosen]

Robert I. Eachus wrote:
> No.  Input output routines may need to do error checking, but that is 
> not an exceptional occurrence, and is usually not treated as one.

Oh, good lord! Do you program in the real world?
In the real world, remote CORBA servers go down.
In the real world, remote databse servers go down.
Most of the time they don't, so when they do, you
throw an exception when you lose connectivity so
you don't blithely ignore the problem, but you also
don't litter every step of the way with checks.

Re: The 1980 ACM Turing Award Lecture The Emperor's Old Clothes

[Stephen Leake]

Hyman Rosen <hyrosen@mail.com> writes:

> Oh, good lord! Do you program in the real world?

Yes.

> In the real world, remote CORBA servers go down. 

I've never used a CORBA server.

> In the real world, remote databse servers go down. 

I've never used a remote database server

> Most of the time they don't, so when they do, you throw an exception
> when you lose connectivity so you don't blithely ignore the problem,
> but you also don't litter every step of the way with checks.

Sounds like a good partial plan. How do you handle the exceptions at
the top level?

In the part of the real world that I work in (hard real time embedded
systems), we need to show that _every_ exceptional situation has been
anticipated and appropriately handled. Sometimes that means allowing
for switching to redundant hardware. That will typically be a huge
"mode change". It is not something that is triggered by some
exception, but rather by a certain pattern of failures, possibly with
confirmation by an external supervisory system (ground control, in the
case of satellites).

In this world, exceptions are used during the debug and test phases,
and sometimes the compiler checks are turned off for the final build,
because we've proven that they will never fail.

-- 
-- Stephe

Re: The 1980 ACM Turing Award Lecture The Emperor's Old Clothes

[Hyman Rosen]

Stephen Leake wrote:
> Sounds like a good partial plan. How do you handle the exceptions at
> the top level?

Log the error, attempt to reconnect to the service, start
a fallback server if that fails, etc.

> In this world, exceptions are used during the debug and test phases,
> and sometimes the compiler checks are turned off for the final build,
> because we've proven that they will never fail.

Well, it's nice for you that you can stay in your little
box, but not all software is so self-contained. There are
*a lot* of situations where things work the vast majority
of the time, but sometimes don't. Those are the cases where
exception-based error handling shines.

Re: The 1980 ACM Turing Award Lecture The Emperor's Old Clothes

[Lyle McKennot]

"Robert I. Eachus" <rieachus@attbi.com> wrote:

 
>Have you even read (or heard) this speech

Of course.
It has been reprinted widely.

Re: The 1980 ACM Turing Award Lecture The Emperor's Old Clothes

[Pat Rogers]

"Lyle McKennot" <spam@spam.menot.com> wrote in message
news:tk0oguk1nls4cmbjtkapoiv10n0updks9j@4ax.com...
> "Robert I. Eachus" <rieachus@attbi.com> wrote:
>
>
> >Have you even read (or heard) this speech
>
> Of course.
> It has been reprinted widely.

Then you need to read what he said about the language once it was finalized.

From the foreword by C.A.R. Hoare to a book titled "Ada Language and
 Methodology" by David Watt, Brian Wichman and William Findlay, published by
Prentice-Hall International, 1987:

'I enjoyed reading the Algol 60 report; it taught me a lot about programming.'
This is the comment of a data processing manager of a major motor manufacturing
company, who had no conceivable prospect of ever using the language to program a
computer.  It is a most perceptive comment, because it describes an important
goal in the design of a new programming language: that it should be an aid in
specification, description, and design of programs, as well as in the
construction of reliable code.

This is one of the main aims in the design of the language which was later given
the name Ada.  As a result, the language incorporates many excellent structural
features which have proved their value in many precursor languages such as
Pascal and Pascal Plus.

The combination of many complex features into a single language has led to an
unfortunate delay in availability of production-quality implementations.  But
the long wait is coming to an end, and one can now look forward to a rapid and
widespread improvement in programming practice, both from those who use the
language and from those who study its concepts and structures.

I hope that this book will contribute directly to these ideals, which have
inspired many of the other books in the same series.  It continues the tradition
of the series in that it describes how the language can be used as the target of
a sound programming methodology, embracing the full life cycle of a programming
project.  It explains not just the features and details of the language, but
also their purpose and method of effective use.

The complexities and difficulties are not glossed over; they are explained
within the appropriate context, with hints on how to avoid any consequent
problems.  I hope the book will be useful, both to those who have the privilege
or obligation to use the language, and to those who have the interest and
curiosity to understand and appreciate its rationale.

----
Patrick Rogers                       Consulting and Training in:
http://www.classwide.com          Real-Time/OO Languages
progers@classwide.com               Hard Deadline Schedulability Analysis
(281)648-3165                                 Software Fault Tolerance