ada paper critic

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

[Dale Stanbrough]

Immanuel Scholz wrote:

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



have a look through this newsgroup on "implicit instantiation" and 
downward closures for coding (not speed) issues.


Look for "asynchronous abort" for speed of resulting code.


Not quite sure what you mean about "stability of the resulting code".


Dale

Re: ada paper critic

[David Marceau]

> have a look through this newsgroup on "implicit instantiation" and
> downward closures for coding (not speed) issues.
There is implicit instantiation in all languages.  
As you with in/import/include a package/class, you implicitly want to
instantiate the characterics necessary for a supporting package/class.
By ensuring a very limited scope to every instantiation of a
package/class, we can mitigate this issue.
If you don't want implicit instantiation make smaller packages with a
smaller number(0 even) of package public scope instantiated types.
IMHO when doing anything with more than one ada "task" however we do
want implicit instantiation but not too much.(Zen balance).
At the other extreme however if you make big packages with a lot of type
instantiations in it,
and then "with" that one big package later, IMHO your design is probably
not well conceived.
A well-conceived service will complete a service by having many classes
collaborate.
Only atomic services(set/get) can(but not necessarily) end up being
standalone(not collaborating with other classes)
and as a general rule if a service doesn't fit on one page it's probably
bad design 
because it has a higher complexity level(only rocket scientists and
cryptographers 
will be able to understand your code) and making it harder to document
and maintain in the long-term.

IMHO all languages need implicit instantiation, and in all languages,
developers should take care where they place it.
As a result, I don't see how implicit instantiation makes Ada any weaker
than any other language.

What do you mean about downward closures for coding issues?  Please
clarify this.



> 
> Look for "asynchronous abort" for speed of resulting code.
All languages have problems like this.
Please clarify how you think ada is inferior in this regard.
As it stands without a solid description and a solid example supporting
your argument, I can't agree with you.


> 
> Not quite sure what you mean about "stability of the resulting code".
Stability of the resulting code coming from Ada IMHO is higher because
that was the language designers intent.
In C/C++, efficiency & legacy code compilation compatibility were the
design intent.(the binary/assembler maps practically 1-to-1 with the C
language itself).
In C/C++ stability was more of an afterthought and more support added
later i.e. exceptions, smart pointers... :)
In Java, the JVM design had security in mind along with
platform-independence.  
Java sacrificed performance in the short-term to reach those design
goals.
Java's JVM performance has increased with Just-In-Time compilers 
however by doing so it compromised the JVM's "stability in the resulting
code".
In fact the JVM is screwing around with the "resulting code" whenever it
has idle time.  
What's that saying about "idle hands"..."devil's work"? :)
Going back to JIT performance it still doesn't and will never match
C/C++.  
Let's define total application execution lifetime as being app boot-up
time + app running time + app shutdown time.
Now let's say we wrote the same one-shot service app(console or gui
doesn't matter) in each of the following languages: asm, c, ada, c++ and
java.
Here how they line up starting with the fastest:
1)asm 
2)C 
3)ada
3)C++
4)java
Concerning Ada95 performance it may match C, however usually it is a bit
slower in order to make it more reliable than C and c++ and java.

It's true one may code badly in any language.  IMHO my bad coding for a
server app in Ada has a better probability of having a longer uptime
than C/C++ or java.
Longer uptime describes well what I mean by "definition of stability in
the resulting code" which I believe could be interpreted as part of the 
ada language designers' intent.

I hope this helps :)

Sant� bonheur,
David Marceau

Re: ada paper critic

[Dale Stanbrough]

David Marceau <davidmarceau@sympatico.ca> wrote:

> > have a look through this newsgroup on "implicit instantiation" and
> > downward closures for coding (not speed) issues.

> There is implicit instantiation in all languages.  



> IMHO all languages need implicit instantiation, and in all languages,
> developers should take care where they place it.
> As a result, I don't see how implicit instantiation makes Ada any weaker
> than any other language.

I don't really think you know what I'm talking about. I was talking
about implicit instantiation of generics, something that happens
in C++ templates.

I'm sorry but I don't understand anything else you said on this issue.


> What do you mean about downward closures for coding issues?  Please
> clarify this.

Step 1.

   Read my directions (read the newsgroup). You can do this
   via google.

Step 2.
   Follow the links to find out what was said about downward
   closures



Dale

Re: ada paper critic

[Hyman Rosen]

David Marceau wrote:
> There is implicit instantiation in all languages.  
> As you with in/import/include a package/class, you implicitly want to
> instantiate the characterics necessary for a supporting package/class.
> By ensuring a very limited scope to every instantiation of a
> package/class, we can mitigate this issue.

Um, I think you're barking up the wrong tree here.
I think the "implicit instantiation" referred to here is the
automatic instantiation of generic subprograms using analysis
of the types of the parameters in a call to the generic itself.

This is the C++ way. Ada requires explicit instantiation of
generic instances. This gets in the way of doing nice things
with units, for example. The differences between Ada and C++
in this regard affect whole-program behavior, so it's not easy
to retrofit automatic instantiation into Ada, nor to compile
and link instantiations in C++.

Re: ada paper critic

[Baugereau]

> 1)asm
> 2)C
> 3)ada
> 3)C++
> 4)java

What allow you to say that C++ is slower than Ada?
Mhh. What Ada compiler produces faster code than the best C++ compiler on
x86 for instance?

Re: ada paper critic

[David Marceau]

Baugereau wrote:
> 
> > 1)asm
> > 2)C
> > 3)ada
> > 3)C++
Same rank number 3 :)

> > 4)java
> 
> What allow you to say that C++ is slower than Ada?
I apologize for the lack of clarity.

Actually I meant Ada95 is usually a bit slower than c and c++.
That certainly doesn't make ada inferior to c/c++.
Ada places more importance on reliability, platform-independance,
long-term maintainability and long-term reuse.

As coders we are faced with decisions on what kind of software
engineering lifestyle we want to live.
I have decided to go with Ada and Linux lifestyles for the long haul and
it has much to do with 
reliability, platform-independance, long-term maintainability and
long-term reuse.

> Mhh. What Ada compiler produces faster code than the best C++ compiler on
> x86 for instance?
I don't know.  It has never been my preoccupation.

Sant� bonheur,
David Marceau

Re: ada paper critic

[Baugereau]

> Same rank number 3 :)

Ok :)))

> Actually I meant Ada95 is usually a bit slower than c and c++.
> That certainly doesn't make ada inferior to c/c++.
> Ada places more importance on reliability, platform-independance,
> long-term maintainability and long-term reuse.

I just wanted to make the point that the compiler is the issue, not the
language itself.

>
> As coders we are faced with decisions on what kind of software
> engineering lifestyle we want to live.
> I have decided to go with Ada and Linux lifestyles for the long haul and
> it has much to do with
> reliability, platform-independance, long-term maintainability and
> long-term reuse.

Agreed. But for raw performance, on many platforms, much more effort has
been invested in optimising C or C++ compilers than Ada compilers.

>
> > Mhh. What Ada compiler produces faster code than the best C++ compiler
on
> > x86 for instance?
> I don't know.  It has never been my preoccupation.

It was mine :)

Re: ada paper critic

[Wes Groleau]

> Agreed. But for raw performance, on many platforms, much more effort has
> been invested in optimising C or C++ compilers than Ada compilers.

1. If the optimization technique is based on the generated code,
   then it can be used with any language.

2. If the optimization is based on information provided
   in the source code, more is possible with Ada.

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

Re: ada paper critic

[Baugereau]

> 1. If the optimization technique is based on the generated code,
>    then it can be used with any language.

"can be"

>
> 2. If the optimization is based on information provided
>    in the source code, more is possible with Ada.

"is possible"

The FACT is that Intel C++ beats gnat (and gcc), because much more effort
has been invested.
Real people who care about speed of generated code (they exist) don't have
the choice on many platforms.

Re: ada paper critic

[Vinzent Hoefler]

"Baugereau" <baugereau@ifrance.kom> wrote:

>The FACT is that Intel C++ beats gnat (and gcc), because much more effort
>has been invested.

Well. But Intel does not build Ada compilers, AFAIK. So do you compare
languages or compilers?

MSVC used to generate faster code than GCC in many circumstances. Does
that mean, I am stuck to Windows?


Vinzent.

Re: ada paper critic

[Pascal Obry]

Vinzent Hoefler <JeLlyFish.software@gmx.net> writes:

> MSVC used to generate faster code than GCC in many circumstances. Does
> that mean, I am stuck to Windows?

BTW, it would be nice to have updated values here as GCC 3.1 does have a
quite better optimizer. Anyone have checked speed of MSVC compiler vs GCC 3.1 ?

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: ada paper critic

[Dan Andreatta]

Pascal Obry <p.obry@wanadoo.fr> wrote in message news:<uy9dg27o0.fsf@wanadoo.fr>...
> BTW, it would be nice to have updated values here as GCC 3.1 does have a
> quite better optimizer. Anyone have checked speed of MSVC compiler vs GCC 3.1 ?
> 

In this site there is a comparison between Intel/C++ and GCC/C++ 3.1.

http://www.coyotegulch.com/reviews/intel_comp/intel_gcc_bench2.html

Dan

Re: ada paper critic

[Pascal Obry]

andreatta@mail.chem.sc.edu (Dan Andreatta) writes:

> In this site there is a comparison between Intel/C++ and GCC/C++ 3.1.
> 
> http://www.coyotegulch.com/reviews/intel_comp/intel_gcc_bench2.html

Thanks, GCC 3.1 has very good results, close from Intel C++ 6.0.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: ada paper critic

[Michael Bode]

Pascal Obry <p.obry@wanadoo.fr> writes:

> BTW, it would be nice to have updated values here as GCC 3.1 does
> have a quite better optimizer. Anyone have checked speed of MSVC
> compiler vs GCC 3.1 ?

The German computer magazine c't compared GCC 2.95.2 on Powermac G4,
GCC 2.95.3 on PIII and MSVC 6 SP5 on PIII. In short: forget MSVC. If
speed matters use GCC or Intel. For GCC 3.0 they say the numbers are
at least 10% better than for 2.95.3.

http://www.heise.de/ct/02/05/182/default.shtml

Look at the pictures.

-- 
begin  Outlook_is_crap.txt.vbs

Legen Sie die Diskette beschriftet mit Windows XP Professional-CD-ROM
in Laufwerk A: ein.

Re: ada paper critic

[Pascal Obry]

Michael Bode <m.g.bode@web.de> writes:

> http://www.heise.de/ct/02/05/182/default.shtml
> 
> Look at the pictures.

Thanks.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: ada paper critic

[Ted Dennison]

Vinzent Hoefler wrote:
>>The FACT is that Intel C++ beats gnat (and gcc), because much more effort
>>has been invested.
> 
> 
> Well. But Intel does not build Ada compilers, AFAIK. So do you compare
> languages or compilers?

Actually, they do build C highly-optimizing C compilers for their 
processors. I suspect they mostly do it so that they can show good 
numbers on benchmarks.

Re: ada paper critic

[Immanuel Scholz]

Dale Stanbrough wrote:

> Not quite sure what you mean about "stability of the resulting code".

Doning Things wrong can result either in disaster (as in C) or in defined 
exceptions (as in java). So I classify java to be produce more stabile code.

The best solution is to give a compile error for all things than can be 
decided compile time and only throw an defined exception runtime if the 
decission is simple not possible.

Also statements as "assert" in Java1.4 counts towards the "stability of 
produced code" - argument (because it is shipped in the release code!) - 
Macros like assert in C does not count really much.

Lbnl, some languages are tend to let you produce more fragile code than 
other (again, C get the rubbish ;-). It should be easy to produce right 
code, but very hard to compile buggy code.

Immanuel Scholz

Re: ada paper critic

[Ted Dennison]

Immanuel Scholz wrote:
>>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++?)

There was a cross language study done that addresses some of those 
issues. However, it may not work for you since it showed Ada equal or 
superior to every other language in every category except Java, and it 
was equal or superior to Java in most categories (all but "portability" 
and "distributed system support", and it was close behind in those). :-)

There is a copy of it online at 
http://archive.adaic.com/docs/reports/lawlis/content.htm

The paper didn't address "speed", but I can. Speed depends almost 
entirely on your compiler. For *theoretical* speed, Ada should be faster 
than both C (assuming checks are suppressed) and C++. Ada provides the 
compiler with way more information about code and objects with which to 
optimize. Ada will only not be faster than Java if your Java is compiled 
to native code before loading. I'd guess even then Ada will still tend 
to run faster, as its harder to aviod expensive dynamic allocations and 
deallocations in Java.

But if you want real numbers that mean something, get the compilers you 
would use if you were to pick that language, and compare their output 
for the types of code you will be generating. Speed has way more to do 
with the effort your compiler writers put into optimization than with 
the language.

Re: ada paper critic

[Dale Stanbrough]

Ted Dennison wrote:

> But if you want real numbers that mean something, get the compilers you 
> would use if you were to pick that language, and compare their output 
> for the types of code you will be generating. Speed has way more to do 
> with the effort your compiler writers put into optimization than with 
> the language.

async abort is one counter example of this. The definition is such 
that programs take a hit in efficiency (or so i have read in this 
newsgroup).

Just thinking about it, don't Ada's "non constructor" construcor 
functions require you to build  items on the heap, then copy them 
into the variable, rather than bulding them inplace?

...and doesn't the fact that the only way to attach information
to an exception is via a string, requiring conversions  to/from
the appropriate format just to find out what -really- went wrong?

...and doesn't the representation of holey enumerated types cause
a lot of run time processing?

I could go on, but i can't think of any others (at the moment!) :-)

Dale

Re: ada paper critic

[David Marceau]

Dale Stanbrough wrote:
> 
> Ted Dennison wrote:
> 
> > But if you want real numbers that mean something, get the compilers you
> > would use if you were to pick that language, and compare their output
> > for the types of code you will be generating. Speed has way more to do
> > with the effort your compiler writers put into optimization than with
> > the language.
> 
> async abort is one counter example of this. The definition is such
> that programs take a hit in efficiency (or so i have read in this
> newsgroup).
> 
> Just thinking about it, don't Ada's "non constructor" construcor
> functions require you to build  items on the heap, then copy them
> into the variable, rather than bulding them inplace?
> 
> ...and doesn't the fact that the only way to attach information
> to an exception is via a string, requiring conversions  to/from
> the appropriate format just to find out what -really- went wrong?
> 
> ...and doesn't the representation of holey enumerated types cause
> a lot of run time processing?
I don't remember seeing anything in the ada95 rationale or the reference
manual mentioning 
"minimize run-time processing" as part of the ada language design
intent.
IMHO I believe this is a feature since the ada run-time 
deliberately sacrifices optimum execution speed 
in order to achieve higher-levels of reliability 
via many invisible implicit checks on stuff 
every time you call a different service.
I grant java does some similar checks here but with the JIT tweaking
code, certainty in execution behaviour is reduced.
I grant the java exception handling similar to ada 
however the java threading/runnable and concurrency infrastructure are
an after-thought 
because they are not part of the java language itself.
In other words one of the best kept secrets on the planet is that ada
run-time and exception handling 
is much richer than java in terms of depth and breadth when dealing with
tasking and concurrency.
As an example read in the ada rationale documentation what it has to say
about tasks and you will see what I mean.  Lots of stuff here.  It shows
much depth and breadth in terms of expertise went into the
documentation.  Warns the user of issues that may need to be dealt with
in certain specified situations.
Then read the java thread/runnable docs and you will find it much
simpler and a joy to read.  Just follow the recipe and everything will
be fine :)
Which one describes the more realistic scenario when concurrency is
involved?  IMHO ada.

> 
> I could go on, but i can't think of any others (at the moment!) :-)
> 
> Dale
That's interesting IMHO these all ADA FEATURES and not ada bugs :)

Re: ada paper critic

[Dale Stanbrough]

David Marceau wrote:

> > 
> > ...and doesn't the representation of holey enumerated types cause
> > a lot of run time processing?
> I don't remember seeing anything in the ada95 rationale or the reference
> manual mentioning 
> "minimize run-time processing" as part of the ada language design
> intent.

Interesting, but that's not what the original question was.
The person was wondering what features of Ada caused it to 
run slow (i'm not sure what the exact wording was). I'm answering
his question.


> That's interesting IMHO these all ADA FEATURES and not ada bugs :)

ok.

Dale

Re: ada paper critic

[Darren New]

David Marceau wrote:
> however the java threading/runnable and concurrency infrastructure are
> an after-thought
> because they are not part of the java language itself.

Of course they are. Or are you forgetting "synchronized"? That "Thread" is a
class in Java doesn't mean it's not built in. Or would you consider
controlled types not a part of the language in Ada?

> In other words one of the best kept secrets on the planet is that ada
> run-time and exception handling
> is much richer than java in terms of depth and breadth when dealing with
> tasking and concurrency.

But this is true. It's clear that Ada put a lot more effort into building
tasking that's useful and powerful for real applications, rather than
tasking to try to make synchronous I/O into asynchronous I/O.

Note to language and OS designers: Synchonous I/O is a special case of
asynchronous I/O, not vice versa!

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: ada paper critic

[Robert A Duff]

Darren New <dnew@san.rr.com> writes:

> Note to language and OS designers: Synchonous I/O is a special case of
> asynchronous I/O, not vice versa!

Yes!  Why does nobody seem to understand this?

- Bob

Re: ada paper critic

[Wes Groleau]

> > ...and doesn't the representation of holey enumerated types cause
> > a lot of run time processing?

IF you declare such a type, then SOME operations
on that type MAY be a little slower.  No other
operations will be affected.

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

Re: ada paper critic

[Dale Stanbrough]

Wes Groleau wrote:

> 
> IF you declare such a type, then SOME operations
> on that type MAY be a little slower.  No other
> operations will be affected.

Yes, i wasn't saying that the (unused) presence of that feature in 
the language causes a program to run more slowly.

I should have spelt it out more clearly, but I was simply throwing
out some quick pointers to someone who (IMHO) was doing an 
assignment/had some other barrow to push.

Dale

Re: ada paper critic

[Dale Stanbrough]

David Marceau wrote:

> I don't remember seeing anything in the ada95 rationale or the reference
> manual mentioning 
> "minimize run-time processing" as part of the ada language design
> intent.

You haven't looked hard enough. It's in the introduction to design of
Ada83 (and prob. still in the intro to Ada95) that run time efficiency
was an important factor in the design.

They got it wrong in a couple of cases - notably rendezvous (as the 
only sync mechanism), and holey representation clauses for enumeration
types (...when you iterate over them with a for loop, or use them
as an index into an array).

Dale

Re: ada paper critic

[Dmitry A. Kazakov]

On Fri, 14 Jun 2002 14:35:27 +1000, Dale Stanbrough
<dale@cs.rmit.edu.au> wrote:

>Just thinking about it, don't Ada's "non constructor" construcor 
>functions require you to build  items on the heap, then copy them 
>into the variable, rather than bulding them inplace?

I believe, in worst case, they will be copied from the stack.

There are IMO more serious problems with OO in Ada, but most of them
can be addressed to other languages as well. Others, like non-OO task
and protected object types, can be excused by the fact that other
languages have no such types at all.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: ada paper critic

[Immanuel Scholz]

Dmitry A. Kazakov wrote:

> On Fri, 14 Jun 2002 14:35:27 +1000, Dale Stanbrough
> <dale@cs.rmit.edu.au> wrote:
> 
>>Just thinking about it, don't Ada's "non constructor" construcor
>>functions require you to build  items on the heap, then copy them
>>into the variable, rather than bulding them inplace?
> 
> I believe, in worst case, they will be copied from the stack.

Is there any difference (left alone cache missis) in copying from heap or 
copying from stack?


> There are IMO more serious problems with OO in Ada, but most of them
> can be addressed to other languages as well. Others, like non-OO task
> and protected object types, can be excused by the fact that other
> languages have no such types at all.

no "protected" state is IMHO an advantage. I think protected members are 
evil doing more harm than good, but this is antoher story.;-)



Immanuel Scholz

Re: ada paper critic

[Dmitry A. Kazakov]

On Fri, 14 Jun 2002 14:19:14 +0200, Immanuel Scholz
<news@kutzsche.net> wrote:

>Dmitry A. Kazakov wrote:
>
>> On Fri, 14 Jun 2002 14:35:27 +1000, Dale Stanbrough
>> <dale@cs.rmit.edu.au> wrote:
>> 
>>>Just thinking about it, don't Ada's "non constructor" construcor
>>>functions require you to build  items on the heap, then copy them
>>>into the variable, rather than bulding them inplace?
>> 
>> I believe, in worst case, they will be copied from the stack.
>
>Is there any difference (left alone cache missis) in copying from heap or 
>copying from stack?

Surely. Heap allocation/deallocation is very expensive as compared
with stack ones. Things getting even worse in a multiprocessor system
where heap is shared, so a spin lock must be taken. Then heap
management might have an unbouded time [=inacceptable for real-time
systems].

>> There are IMO more serious problems with OO in Ada, but most of them
>> can be addressed to other languages as well. Others, like non-OO task
>> and protected object types, can be excused by the fact that other
>> languages have no such types at all.
>
>no "protected" state is IMHO an advantage. I think protected members are 
>evil doing more harm than good, but this is antoher story.;-)

Actually I meant Ada's protected objects and not the visibility rules.
There is a great need to have protected objects extensible (tagged).
At the same time it is not very clear (at least to me), how to do it.
As for protected members in C++ sense, I believe that Ada's "private"
is closer to C++ "protected", than to "private", when child packages
or derived types are considered.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: ada paper critic

[Darren New]

"Dmitry A. Kazakov" wrote:
> Actually I meant Ada's protected objects and not the visibility rules.
> There is a great need to have protected objects extensible (tagged).
> At the same time it is not very clear (at least to me), how to do it.

What's wrong with Java's approach to OO threading and protected objects?

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: ada paper critic

[Dmitry A.Kazakov]

Darren New wrote:

> "Dmitry A. Kazakov" wrote:
>> Actually I meant Ada's protected objects and not the visibility rules.
>> There is a great need to have protected objects extensible (tagged).
>> At the same time it is not very clear (at least to me), how to do it.
> 
> What's wrong with Java's approach to OO threading and protected objects?

I do not know Java good enough to judge. But the problems as I see them are 
mostly with MD and MI. Java has no MD. Ada has neigher. But if it had, how 
to call on an entry point that belongs to two protected objects, or else 
tasks? Consider imaginary:

task type A;
task type B;
entry Do_It (First : in out A; Second : in out B); -- Of both A and B

task type C is new A with ...;
entry Do_It (First : in out C; Second : in out B); -- Overrides in A

   X : A'Class := ...; Y : B'Class := ...;
begin
   select
      Do_It (X, Y); -- Dispatching entry call
   ...

What about freezing rules with MD? May I override barriers? How to override 
the body an entry point of a task? How to inherit an entry point? How to 
add a new entry point? From a caller view point, there is no difference 
between entry points of tasks and protected objects, should then exist a 
common parent type for them? Should caller know any difference between an 
entry point and a subroutine? Isn't that an implementation detail? If so, 
how to [efficiently] implement entry points with a return parameter? Or 
should we introduce generic formal entry points, protected type, task type 
parameters?

I suspect lots of pitfalls here. However, ask more knowledgeable people 
than me ...

-- 
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: ada paper critic

[Jim Rogers]

> Darren New wrote:
> 
> 
>>"Dmitry A. Kazakov" wrote:
>>
>>>Actually I meant Ada's protected objects and not the visibility rules.
>>>There is a great need to have protected objects extensible (tagged).
>>>At the same time it is not very clear (at least to me), how to do it.
>>>
>>What's wrong with Java's approach to OO threading and protected objects?
>>


There are actually a number of problems with Java's approach to OO
threading and protected objects.

The first problem is that Java does not have protected objects in the
Ada sense of the term. Java only provides synchronization blocks, which
are not even close to being protected objects.

Java's threading model works very well as long as your threads do not
communicate with each other, and they never need to be terminated.
Of course, many useful concurrent designs do need to have
communication between tasks, and those tasks need to be terminated
as some point in the program.

The only safe communication feature for Java threads is synchronized
blocks. The code in the synchronized block belongs to the shared
object. That object might be one of the threads, or a shared object.

Let's look at a classical concurrent design, the producer/consumer
model. Any decent threading implementation should be able to
properly support a producer/consumer model. Let's assume that our
application needs reliable communication between the producer thread
and the consumer thread. We will use a bounded queue between the
producer and the consumer. The producer must not write to the bounded
queue when it is full, and the consumer must not read from the
bounded queue when it is empty. In Ada this would be handled simply
using a protected object with two entries; one to add elements to
the bounded queue, and one to extract elements from the bounded queue.

In Java you will create your bounded queue class. You will provide two
methods, one to add elements to the queue and one to extract elements
from the queue. Each of these methods must be declared synchronized.

Under Java rules you must call the synchronized block, and obtain the
synchronization lock before you can check for conditions such as
queue full or queue empty. If the producer is calling the add element
method and the queue is full the wait() method must be called to
suspend the producer. Note that the producer class has no control
over this code. It merely calls the method defined in the bounded
queue class. There is no Java equivalent to the Ada timed select
statement allowing an Ada task to limit its suspension time on an
entry call. In Java the producer will be suspended until another
thread, in this case the consumer, calls the notify() or the
notifyAll() method. The notify() method randomly unsuspends one
suspended thread, no matter which synchronization block it is waiting
for. The notifyAll() method unsuspends all suspended threads, forcing
each to check whether or not it should proceed. If not, it must be
immediately re-suspended using a wait() call.

Note that all this re-checking and waiting is still occuring in the
code for the synchronized object, not at all under control of the
producer thread. How do we design this so that the producer can
have an effective timeout on its suspension? We could design the
bounded queue code so that it provides a fixed timeout period for
all threads that may be suspended. The problem here is that this
forces all threads calling this synchronized block to have
the same timing requirements. You could allow the calling thread
to pass a timeout value to the synchronized block. This forces you
to reveal internal state of your thread to another object, violating
encapsulation principles.

Given the behavior of the notify() and the notifyAll() methods there
is no guarantee that a given thread will ever progress past a set
of wait/notify calls to execute the bulk of the synchronized block.
Java provides nothing like an Ada entry queue. Thus, the order in
which threads are unsuspended is not deterministic.

Let's turn now to the issue of terminating a thread. Java provides a
stop() method to terminate a thread. Java has also deprecated the
use of this method because it has been found to be unsafe. The
problem is that the stop() method does not release any synchronization
locks currently held by the thread being stopped. This easily
results in starvation because no other thread will be allowed to
acquire the synchronization lock. The current Java solution is to
require the programmer to invent his own termination method which
some other method will call. Of course, that termination condition
will not be serviced until the "terminated" thread has returned from
all synchronized blocks, which as I have shown above, may never
happen.

Jim Rogers

Re: ada paper critic

[Darren New]

Jim Rogers wrote:
> The first problem is that Java does not have protected objects in the
> Ada sense of the term. Java only provides synchronization blocks, which
> are not even close to being protected objects.

If every routine of a class is declared synchronized, I think you get
something close to protected objects as long as you're not doing real-time,
not worried about priority inversion, and etc. All of which Ada gets right,
of course. Which you amply demonstrate in your post.
 
> Java's threading model works very well as long as your threads do not
> communicate with each other,

Basically, you have to build your own entry queues in Java's threads, just
like you had to build your own protected objects in Ada 83.

> and they never need to be terminated.

I'm pretty sure you can force a Java thread to throw an error, thereby
terminating.

Anyway, I was commenting not on the fact that Java is better or worse than
Ada in terms of tasking. Clearly Ada wins hands down over any other GP
language. All I was addressing was

> >> like non-OO task
> >> and protected object types, can be excused by the fact that other
> >> languages have no such types at all.

and wondering why the poster felt that Java didn't have tasks or protected
types. I didn't literally mean "what's wrong with Java's threads", but
rather "why do you feel they're so broken that you don't even call them
threads?"

> problem is that the stop() method does not release any synchronization
> locks currently held by the thread being stopped. This easily

Ah. I was unaware that it was unsafe.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: ada paper critic

[Jim Rogers]

Darren New wrote:

> Jim Rogers wrote:
> 
>>The first problem is that Java does not have protected objects in the
>>Ada sense of the term. Java only provides synchronization blocks, which
>>are not even close to being protected objects.
>>
> 
> If every routine of a class is declared synchronized, I think you get
> something close to protected objects as long as you're not doing real-time,
> not worried about priority inversion, and etc. All of which Ada gets right,
> of course. Which you amply demonstrate in your post.


I disagree. You get a lot of object locking, but a protected object
is much more than simple object locking. You do not get the ability
to do shared reads of the object as you get from Ada protected
functions. You get no equivalent to entry queues. You have no
equivalent to the Ada select command. You simply have built-in
syntax for manipulating an object-wide mutex.

Note that it is also extremely difficult in Java to simulate an
Ada rendezvous.


>  
> 
>>Java's threading model works very well as long as your threads do not
>>communicate with each other,
>>
> 
> Basically, you have to build your own entry queues in Java's threads, just
> like you had to build your own protected objects in Ada 83.


I tried to describe why you cannot simply build your own entry queues
in Java. The problem is the Java definition of the wait() and
notify() methods. They control thread suspension and activation due
to changes in shared object conditions. They provide completely
non-deterministic results when activating a suspended thread. You
have no access to the way they work, nor can you redefine their
operation without encountering rather nasty behaviors in the Java
memory model, which is generally NOT implemented as defined for the
Java Virtual Machine.


> 
> 
>>and they never need to be terminated.
>>
> 
> I'm pretty sure you can force a Java thread to throw an error, thereby
> terminating.


Yes, you can force a thread to throw an exception, but that means that
all your threads must declare that they throw whichever exception
you want to used. This is clearly an uncommon design choice in Java.


> 
> Anyway, I was commenting not on the fact that Java is better or worse than
> Ada in terms of tasking. Clearly Ada wins hands down over any other GP
> language. All I was addressing was
> 
> 
>>>>like non-OO task
>>>>and protected object types, can be excused by the fact that other
>>>>languages have no such types at all.
>>>>
> 
> and wondering why the poster felt that Java didn't have tasks or protected
> types. I didn't literally mean "what's wrong with Java's threads", but
> rather "why do you feel they're so broken that you don't even call them
> threads?"


Java does have threads. It clearly does not have protected types.
Instead it has an overly simple and primitive view of object locking
using a classic mutex.


Jim Rogers

Re: ada paper critic

[David Marceau]

> 
> I tried to describe why you cannot simply build your own entry queues
> in Java. 
Concerning building something like entry queues, the following 
book: High Performance Java Platform Computing
http://www.toolsofcomputing.com/JavaThreads/

describes an entire infrastructure of java classes which attempts to
compensate 
for the lack of concurrency capability in the java language.

For example it describes an infrastructure for building a threadpool and
then using a 
runnablequeue to feed them as each thread completes a runnable's task.

The book even mentions the MEMO and MPI infrastructures at the end
however it was very brief 
and left the reader to figure out what they meant in their code.

As it stands it is the best java thread book out there.

> The problem is the Java definition of the wait() and
> notify() methods. They control thread suspension and activation due
> to changes in shared object conditions. 
> They provide completely
> non-deterministic results when activating a suspended thread.

I hear you. Like the java language itself, all the java threading books
I read did not help 
to save time when debugging run-time 
erratic behaviour(like what you said non-deterministic 
results i.e. memory leaks) in the application
caused by a mix of a concurrency class infrastructure mixed with human
coders.
I guess that makes me a bad debugger guy eh?

> You
> have no access to the way they work, nor can you redefine their
> operation without encountering rather nasty behaviors in the Java
> memory model, which is generally NOT implemented as defined for the
> Java Virtual Machine.
I hear you concerning the memory model :)  
Java claims Garbage-Collection.  Java doesn't garbage collect Thread
Classes.  
This makes for a lot of coding work-arounds.
At least c/c++ never claimed to have garbage collection before
displaying memory leaks behaviour.
At least c/c++ coders deep down inside know their code isn't bullet
proof 
until they add the defensive programming(a reasonable amount of checks
and exception handling stuff) and test it on the target (anywhere)
platform.
At least c/c++/ada have a debugger that can go anywhere and attach to
any process even a java process.

Sant� bonheur,
David Marceau

Re: ada paper critic

[Darren New]

Jim Rogers wrote:
> Java does have threads. It clearly does not have protected types.
> Instead it has an overly simple and primitive view of object locking
> using a classic mutex.

OK, I'll agree with that. :-)  I'd more say it uses academic-style locking
primitives, more appropriate for proving equivalence of mathematical
descriptions of multiprocessing than getting real work done. The
wait()/notify() stuff is almost as classic as P() and V(). :-)

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: ada paper critic

[Darren New]

"Dmitry A.Kazakov" wrote:
> I do not know Java good enough to judge. But the problems as I see them are
> mostly with MD and MI. Java has no MD. Ada has neigher. But if it had, how
> to call on an entry point that belongs to two protected objects, or else
> tasks?

If I understand what you're saying, this isn't a problem in Java because
Java uses distinguished-receiver notation.

A.do_it(b) or B.do_it(a).


> What about freezing rules with MD? May I override barriers? How to override
> the body an entry point of a task? How to inherit an entry point? How to
> add a new entry point?

None of these are problems, because Java doesn't work it the same way that
Ada does.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: ada paper critic

[Dmitry A.Kazakov]

Darren New wrote:

> "Dmitry A.Kazakov" wrote:
>> I do not know Java good enough to judge. But the problems as I see them
>> are mostly with MD and MI. Java has no MD. Ada has neigher. But if it
>> had, how to call on an entry point that belongs to two protected objects,
>> or else tasks?
> 
> If I understand what you're saying, this isn't a problem in Java because
> Java uses distinguished-receiver notation.
> 
> A.do_it(b) or B.do_it(a).

There cannot be a distinguished receiver with MD. If both arguments are 
dispatching which one is distinguished? Then if an entry belongs to TWO 
tasks, it means that rendezvous happens with BOTH of them. As I said I do 
not know Java, but I am pretty sure that it does not have such a thing.

>> What about freezing rules with MD? May I override barriers? How to
>> override the body an entry point of a task? How to inherit an entry
>> point? How to add a new entry point?
> 
> None of these are problems, because Java doesn't work it the same way that
> Ada does.

That is what I meant. Other languages simply did not attemted to integrate 
tasks and protected objects as deep and consistently as Ada does. So they 
have no problems like that. Which only means that it is a poor programmer, 
who shall solve them.

-- 
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: ada paper critic

[Larry Kilgallen]

In article <dale-7114C2.14352714062002@its-aw-news.its.rmit.edu.au>, Dale Stanbrough <dale@cs.rmit.edu.au> writes:
> Ted Dennison wrote:
> 
>> But if you want real numbers that mean something, get the compilers you 
>> would use if you were to pick that language, and compare their output 
>> for the types of code you will be generating. Speed has way more to do 
>> with the effort your compiler writers put into optimization than with 
>> the language.
> 
> async abort is one counter example of this. The definition is such 
> that programs take a hit in efficiency (or so i have read in this 
> newsgroup).

> ...and doesn't the fact that the only way to attach information
> to an exception is via a string, requiring conversions  to/from
> the appropriate format just to find out what -really- went wrong?

The spirit of exception processing is that it is supposed to be done
on an infrequent basis.  Performing giant sort in Cobol is more costly
than a simple multiplication in the same language.

Re: ada paper critic

[Dale Stanbrough]

(Larry Kilgallen wrote:

> > ...and doesn't the fact that the only way to attach information
> > to an exception is via a string, requiring conversions  to/from
> > the appropriate format just to find out what -really- went wrong?
> 
> The spirit of exception processing is that it is supposed to be done
> on an infrequent basis.  Performing giant sort in Cobol is more costly
> than a simple multiplication in the same language.

?Maybe, but when you do need to use it, you may want to attach
information to the exception so that you can determine what
went wrong more precisely. 

Java allows you to throw objects descended from the Exception class;
this seems like it could be quite handy at times.

I've not used it though, so i'm not sure -how- useful it is.

Dale

Re: ada paper critic

[Larry Kilgallen]

In article <dstanbro-3384C9.08152215062002@news-server.bigpond.net.au>, Dale Stanbrough <dstanbro@bigpond.net.au> writes:
> (Larry Kilgallen wrote:
> 
>> > ...and doesn't the fact that the only way to attach information
>> > to an exception is via a string, requiring conversions  to/from
>> > the appropriate format just to find out what -really- went wrong?
>> 
>> The spirit of exception processing is that it is supposed to be done
>> on an infrequent basis.  Performing giant sort in Cobol is more costly
>> than a simple multiplication in the same language.
> 
> ?Maybe, but when you do need to use it, you may want to attach
> information to the exception so that you can determine what
> went wrong more precisely. 

Ah, so the issue is programming effort.  I thought it was performance.

Re: ada paper critic

[Dale Stanbrough]

Larry Kilgallen wrote:


> Ah, so the issue is programming effort.  I thought it was performance.

The original poster was asking about both.

I would imagine that transforming objects into strings 
could result in some performance penatly as well as requiring
more programming effort. 

To convert arbitrary information to a string is fairly
straight forward (even allowing for flattening),
but going the other way isn't necessarily, 
esp. as you have to determine exactly what type of object
the string represents.

You could utilise the streams feature to convert it to/from
in a standardised way, but to me that seems a lot of work 
compared to the Java equivalent.

Dale

Re: ada paper critic

[Immanuel Scholz]

Dale Stanbrough wrote:

> You could utilise the streams feature to convert it to/from
> in a standardised way, but to me that seems a lot of work
> compared to the Java equivalent.

Yes, and also this would drop your coding style to a level of "unsage 
typecasts".

(Theoretically you can cover _all_ variable types by just use a unique 
string-representation and parse them at need ;-)


I think the idea of exceptions in Ada are more restrictive than in other 
languages as Java. In Java it is a more or fewer "normal" exit state of any 
function to raise an exception on error conditions (e.g. File not found, 
Disk full, invalid xml-document etc.)

In Ada, I guess, exceptions have only to be thrown in real critical 
situations, where something unpredictable have been done, as violating the 
contract with a function. In this case, exception is more an assert than an 
java.lang.Exception.

Am I right?

What is the real practise use of exceptions in Ada?

Immanuel Scholz

Re: ada paper critic

[Robert A Duff]

Kilgallen@SpamCop.net (Larry Kilgallen) writes:

> Ah, so the issue is programming effort.  I thought it was performance.

I think the issue is type safety.

If you're going to attach information to exceptions, you want to declare
the *type* of that information at the point of the exception
declaration, to ensure that the raiser and the handler agree on that
contract.  Many languages, including Java, support that capability.  In
Ada, you can't do it, because you have to convert any such data to
String.

- Bob

Re: ada paper critic

[Ted Dennison]

Dale Stanbrough <dale@cs.rmit.edu.au> wrote in message news:<dale-7114C2.14352714062002@its-aw-news.its.rmit.edu.au>...
> Ted Dennison wrote:
> 
> > But if you want real numbers that mean something, get the compilers you 
> > would use if you were to pick that language, and compare their output 
> > for the types of code you will be generating. Speed has way more to do 
> > with the effort your compiler writers put into optimization than with 
> > the language.
> 
> async abort is one counter example of this. The definition is such 
> that programs take a hit in efficiency (or so i have read in this 
> newsgroup).

You are missing the entire point. We could sit here all day and come
up with weird constructions for each language in question that go slow
on some compilers. What matters when you talk about speed is how
quickly the code generated by your compiler runs your kinds of
applications. If there's an unbelieveably slow feature in there, and
that feature isn't used in this particular person's code in a tight
loop somewhere, its not going to have any impact whatsoever on their
percieved performance.


-- 
T.E.D. 
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  (temporarily down)

Re: ada paper critic

[Dale Stanbrough]

Ted Dennison wrote:

> > async abort is one counter example of this. The definition is such 
> > that programs take a hit in efficiency (or so i have read in this 
> > newsgroup).
> 
> You are missing the entire point. We could sit here all day and come
> up with weird constructions for each language in question that go slow
> on some compilers. What matters when you talk about speed is how
> quickly the code generated by your compiler runs your kinds of
> applications. If there's an unbelieveably slow feature in there, and
> that feature isn't used in this particular person's code in a tight
> loop somewhere, its not going to have any impact whatsoever on their
> percieved performance.


No, async abort requires the compiler to include all sorts of 
extra mutexes (or polling points) throughout the code, to ensure
that abort deferred actions are, well, abort deferred!

The original questions were (partly) about features in Ada that make
it go slow, and async abort is one of them. Don't use it and your
code goes fast. Even the presence of it in an if statement...

   if <some condition that is rarely true> then
      abort <some task>;
   end if;

causes the program to go slower. It doesn't really matter what
compiler you use.

Dale

Re: ada paper critic

[Wes Groleau]

> The original questions were (partly) about features in Ada that make
> it go slow, and async abort is one of them. Don't use it and your
> code goes fast. Even the presence of it in an if statement...

Even if you don't use it, support for it in the run-time
MIGHT slow you down.  But if the compiler (or compiler vendor)
is smart enough....

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

Re: ada paper critic

[Ted Dennison]

Dale Stanbrough wrote:
>>You are missing the entire point. We could sit here all day and come
>>up with weird constructions for each language in question that go slow
>>on some compilers. What matters when you talk about speed is how
>>quickly the code generated by your compiler runs your kinds of
>>applications. If there's an unbelieveably slow feature in there, and
>>that feature isn't used in this particular person's code in a tight
>>loop somewhere, its not going to have any impact whatsoever on their
>>percieved performance.
> 
> No, async abort requires the compiler to include all sorts of 
..
> it go slow, and async abort is one of them. Don't use it and your
> code goes fast. Even the presence of it in an if statement...


(sigh)

So you yourself admit this doesn't slow anything down unless its used. I 
know for a fact I've never used async abort, and I suspect if we took a 
poll, we'd find exceedingly few Ada programs in general use it. There 
are plenty of things in *any* language that you should avoid if you care 
about speed, so this is hardly unique to Ada. If its an obscure feature 
that's almost never used, why bring it up as something that "makes Ada 
go slow", particularly when C++ is chock full of such features?

Re: ada paper critic

[Ted Dennison]

Dale Stanbrough <dale@cs.rmit.edu.au> wrote in message news:<dale-7114C2.14352714062002@its-aw-news.its.rmit.edu.au>...
> Ted Dennison wrote:
> 
> > But if you want real numbers that mean something, get the compilers you 
> > would use if you were to pick that language, and compare their output 
> > for the types of code you will be generating. Speed has way more to do 
> > with the effort your compiler writers put into optimization than with 
> > the language.
> 
> async abort is one counter example of this. The definition is such 
> that programs take a hit in efficiency (or so i have read in this 
> newsgroup).

You are missing the entire point. We could sit here all day and come
up with weird constructions for each language in question that go slow
on some compilers. What matters when you talk about speed is how
quickly the code generated by your compiler runs your kinds of
applications. If there's an unbelieveably slow feature in there, and
that feature isn't used in this particular person's code in a tight
loop somewhere, its not going to have any impact whatsoever on their
percieved performance.


-- 
T.E.D. 
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  (temporarily down)

Re: ada paper critic

[Wes Groleau]

> You are missing the entire point. We could sit here all day and come
> up with weird constructions for each language in question that go slow
> on some compilers. What matters when you talk about speed is how
> quickly the code generated by your compiler runs your kinds of
> applications. If there's an unbelieveably slow feature in there, .../
> [snip]

... then the solution is not automatically "use a different language."
It might be "use a different compiler."

I know that's what people have been saying;
I just thought I'd make sure it was clear.  :-)

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

Re: ada paper critic

[Jeffrey Carter]

Dale Stanbrough wrote:
> 
> Ted Dennison wrote:
> 
> > But if you want real numbers that mean something, get the compilers you
> > would use if you were to pick that language, and compare their output
> > for the types of code you will be generating. Speed has way more to do
> > with the effort your compiler writers put into optimization than with
> > the language.
> 
> async abort is one counter example of this. The definition is such
> that programs take a hit in efficiency (or so i have read in this
> newsgroup).

A counter example of what? Of the languages under consideration, which
ones have async abort (in addition to Ada)? Of those, which ones have it
defined in such a way as to guarantee that implementations in those
languages must always be faster than implementations in Ada?

> 
> Just thinking about it, don't Ada's "non constructor" construcor
> functions require you to build  items on the heap, then copy them
> into the variable, rather than bulding them inplace?

No. The language allows initialization in place. It does not require it.
If it's important to you, then your compiler selection process should
take this into account.

> 
> ...and doesn't the fact that the only way to attach information
> to an exception is via a string, requiring conversions  to/from
> the appropriate format just to find out what -really- went wrong?

This seems to be an incomplete sentence. If I interpret it correctly,
the Ada intent is that the information be carried primarily by the
exception name. You should not be using a single exception and
differentiating between logical exceptions by the information attached
to that exception.

Also, exceptions should only be used for exceptional situations, so this
does not impact normal processing at all.

> 
> ...and doesn't the representation of holey enumerated types cause
> a lot of run time processing?

I think you misspelled "holy" :)

Only if they're misused.

-- 
Jeff Carter
"I wave my private parts at your aunties."
Monty Python & the Holy Grail

Re: ada paper critic

[Robert A Duff]

Jeffrey Carter <jrcarter@acm.org> writes:

> This seems to be an incomplete sentence. If I interpret it correctly,
> the Ada intent is that the information be carried primarily by the
> exception name. You should not be using a single exception and
> differentiating between logical exceptions by the information attached
> to that exception.

The problem with this view is that it forces the designer of an
abstraction to decide on the granularity of exception handling, when
this decision rightly belongs in the hands of the person designing the
*handler*.  In fact, different handlers have different requirements:
e.g., one handler might want to handle all I/O errors, whereas another
one might want to handle disk_full_error specially.  If the designer of
the abstraction decided to lump all I/O errors under one exception name,
then the fine-grained handler is impossible to write.  On the other
hand, if the designer of the abstraction defined many exceptions for
different kinds of I/O errors, then the coarse-grained handler has to
mention them all, which is overly verbose, and unmaintainable, because
there might be a new kind of I/O error invented tomorrow.

So the designer of the abstraction is forced into a poor design for
*some* possible clients.  This is not good for reusability.

In many other languages, this problem does not occur, because exceptions
are defined hierarchically.

> Also, exceptions should only be used for exceptional situations, so this
> does not impact normal processing at all.

I don't see how that's relevant.  A bug in exception handling is a bug,
even though exceptions occur only rarely.  (In fact, *all* bugs are rare
-- if the thing crashes within seconds most of the time you run it, the
programmer will notice it and fix it.)

- Bob

Re: ada paper critic

[Jeffrey Carter]

Robert A Duff wrote:
> 
> Jeffrey Carter <jrcarter@acm.org> writes:
> 
> > This seems to be an incomplete sentence. If I interpret it correctly,
> > the Ada intent is that the information be carried primarily by the
> > exception name. You should not be using a single exception and
> > differentiating between logical exceptions by the information attached
> > to that exception.
> 
> The problem with this view is that it forces the designer of an
> abstraction to decide on the granularity of exception handling, when
> this decision rightly belongs in the hands of the person designing the
> *handler*.  In fact, different handlers have different requirements:
> e.g., one handler might want to handle all I/O errors, whereas another
> one might want to handle disk_full_error specially.  If the designer of
> the abstraction decided to lump all I/O errors under one exception name,
> then the fine-grained handler is impossible to write.  On the other
> hand, if the designer of the abstraction defined many exceptions for
> different kinds of I/O errors, then the coarse-grained handler has to
> mention them all, which is overly verbose, and unmaintainable, because
> there might be a new kind of I/O error invented tomorrow.

I disagree. The designer of the abstraction has no choice; he must use
fine-grained exceptions so that a client with fine-grained handling
needs is not excluded. This is true regardless of whether the language
has hierarchical exceptions.

However, this is irrelevant to the original post to which I was
replying. It claimed that the use of String to attach information to an
exception made exceptions in Ada inherently slow.

> > Also, exceptions should only be used for exceptional situations, so this
> > does not impact normal processing at all.
> 
> I don't see how that's relevant.  A bug in exception handling is a bug,
> even though exceptions occur only rarely.

Again, this was in the context of exceptions impacting execution speed,
not of errors.

-- 
Jeff Carter
"You cheesy lot of second-hand electric donkey-bottom biters."
Monty Python & the Holy Grail

Re: ada paper critic

[Dale Stanbrough]

Jeffrey Carter wrote:

> 
> However, this is irrelevant to the original post to which I was
> replying. It claimed that the use of String to attach information to an
> exception made exceptions in Ada inherently slow.

I didn't say it made the language inherently slow. I said that it made
it more difficult to program some things in Ada.

It could also make it slower, however.


> Again, this was in the context of exceptions impacting execution speed,
> not of errors.

Your reply was...

> This seems to be an incomplete sentence. If I interpret it correctly,
> the Ada intent is that the information be carried primarily by the
> exception name. You should not be using a single exception and
> differentiating between logical exceptions by the information attached
> to that exception.

> Also, exceptions should only be used for exceptional situations, so this
> does not impact normal processing at all.

I didn't notice anything in your reply that mentioned execution speed.

My (malformed) comment was...

...and doesn't the fact that the only way to attach information
to an exception is via a string, requiring conversions  to/from
the appropriate format just to find out what -really- went wrong?


which doesn't mention anything about speed. The real problem is
in determining what type the object is. If you want to retain type
information in a string, you'll have some problems. An alternative
is to have a hierachy of types (type Exceptions is tagged...), and
simply encode a pointer to the appropriate object as a string.
This is redoing what Java does (and my guess is that that's how
JGnat does it too).

Dale

Re: ada paper critic

[Wes Groleau]

> the Ada intent is that the information be carried primarily by the
> exception name. You should not be using a single exception and
> differentiating between logical exceptions by the information attached
> to that exception.

Indeed you shouldn't.  You should use a single exception
and differentiate by information dropped into a global
ErrNo.

:-)

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

Re: ada paper critic

[Larry Kilgallen]

In article <3D0D0F4A.FCB346CD@despammed.com>, Wes Groleau <wesgroleau@despammed.com> writes:
> 
> 
>> the Ada intent is that the information be carried primarily by the
>> exception name. You should not be using a single exception and
>> differentiating between logical exceptions by the information attached
>> to that exception.
> 
> Indeed you shouldn't.  You should use a single exception
> and differentiate by information dropped into a global
> ErrNo.
> 
> :-)

You can save the overhead of exception processing by just programming
the application to poll ErrNo at appropriate times.

also :-)

Re: ada paper critic

[Jeffrey Carter]

Wes Groleau wrote:
> 
> > the Ada intent is that the information be carried primarily by the
> > exception name. You should not be using a single exception and
> > differentiating between logical exceptions by the information attached
> > to that exception.
> 
> Indeed you shouldn't.  You should use a single exception
> and differentiate by information dropped into a global
> ErrNo.

What a wonderful idea! I wonder why no one ever thought of it before.

> 
> :-)

-- 
Jeff Carter
"Sons of a silly person."
Monty Python & the Holy Grail

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
>

Re: ada paper critic

[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: ada paper critic

[Marin David Condic]

Ummmmm.... Just a guess, but wasn't "1980" over twenty years ago? :-)
Considering that the latest Ada standard is dated 1995 - whatever Hoare
(correctly or incorrectly) criticized Ada for back then doesn't seem to be
terribly important to the language as it stands today.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Lyle McKennot" <spam@spam.menot.com> wrote in message
news:r2flgu8j6nh9sac02e6d7fqjarb4ues8gt@4ax.com...
>
> 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

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

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