Re: Ada Versus PL/I - The debate continues

Re: Ada Versus PL/I - The debate continues

[Richard Riehle]

robin wrote:

> Why do you assume that no-one else knows anything about Ada?
> My statements are not "blatantly" "incorrect".
>
> I stand by my statement that PL/I is better than Ada
> in input-output, built-in functions, error-recovery,
> decimal fixed-point arithmetic.
>
> Furthermore, it is easier to use in those areas.

I am cc'ing comp.lang.ada.

And your observations indicate that you have very little
knowledge of the current version of Ada.   As to built-in
functions,  Ada has a powerful collection of these. However,
some of the functions built-in to PL/I are, as part of the Ada language
standard, implemented in standard libraries.  There is no
performance penalty and there is a significant portability
benefit.

Ada's support for decimal arithmetic is as good as, and perhaps
a little better than PL/I.    This is an important addition to the
current version of Ada which was, admittedly, a drawback in
the first version of Ada.  That drawback has been corrected and
in correcting it, the designers learned a lot about what not to do
from other languages (maybe even PL/I).

Error recovery in Ada works quite well, thank you.

As to ease-of-use, this is always in the eye-of-the beholder.  In my
experience, Ada is a very easy language to use.  It is more readable
than PL/I or C++, and the consequence of that is that it is also easier
to maintain.

Now.  There are so many things Ada does include such as generics,
concurrency, and programming by extension, that PL/I cannot do that
your attempt at comparing the two indicates that your knowledge of
Ada is, at best, superficial.

Richard Riehle

Re: Ada Versus PL/I - The debate continues

[John W. Kennedy]

Richard Riehle wrote:
> And your observations indicate that you have very little
> knowledge of the current version of Ada.   As to built-in
> functions,  Ada has a powerful collection of these. However,
> some of the functions built-in to PL/I are, as part of the Ada language
> standard, implemented in standard libraries.  There is no
> performance penalty and there is a significant portability
> benefit.

Unfortunately, Robin seems to think that, while PL/I BUILTIN functions 
are somehow "part of the language", and therefore susceptible to all 
known forms of inlining and optimization, the Ada library is "only 
library routines" and therefore subject to all the overhead of 
pre-compiled, linked, external subroutines.

> Ada's support for decimal arithmetic is as good as, and perhaps
> a little better than PL/I.    This is an important addition to the
> current version of Ada which was, admittedly, a drawback in
> the first version of Ada.  That drawback has been corrected and
> in correcting it, the designers learned a lot about what not to do
> from other languages (maybe even PL/I).

Even before Ada 95, Ada had learned the crucial lesson from PL/I that 
there is no such thing as a good universal default precision for the 
result of fixed-point multiplication and division.  (PL/I was still an 
improvement on COBOL, which ignored the question altogether.)

> Error recovery in Ada works quite well, thank you.

Robin believes that it is a _good_ thing that PL/I allows the run-time 
ON statement to alter the currently-assigned error recovery, and that 
PL/I allows return to point of error, and will not be convinced that 
both of these were excluded from Ada (and every other language I know of 
with error handling) precisely because experience with PL/I was unfortunate.

-- 
John W. Kennedy
"Only an idiot fights a war on two fronts.  Only
the heir to the throne of the kingdom of idiots
would fight a war on twelve fronts"
   -- "Babylon 5"

Re: Ada Versus PL/I - The debate continues

[Peter Flass]

"John W. Kennedy" wrote:
> 
> > Error recovery in Ada works quite well, thank you.
> 
> Robin believes that it is a _good_ thing that PL/I allows the run-time
> ON statement to alter the currently-assigned error recovery, and that
> PL/I allows return to point of error, and will not be convinced that
> both of these were excluded from Ada (and every other language I know of
> with error handling) precisely because experience with PL/I was unfortunate.
> 
I disagree vehemently.  They were excluded because they were difficult
to implement.  Java
(I believe) with its "try/catch" has effectively tried to re-introduce
this.  Any other type of error handling is deficient.

Re: Ada Versus PL/I - The debate continues

[Hyman Rosen]

Peter Flass wrote:
> They were excluded because they were difficult to implement.

Sounds like a fantasy to me.

> Java with its "try/catch" has tried to re-introduce this.

Java and C++ exception handling, like Ada's, is purely static.

> Any other type of error handling is deficient.

Exception handling is the best way to handle errors.
If you need resume semantics, place an exception handler
closely around the statement you wish to resume, and loop.

Re: Ada Versus PL/I - The debate continues

[John W. Kennedy]

Peter Flass wrote:
> "John W. Kennedy" wrote:
>>>Error recovery in Ada works quite well, thank you.

>>Robin believes that it is a _good_ thing that PL/I allows the run-time
>>ON statement to alter the currently-assigned error recovery, and that
>>PL/I allows return to point of error, and will not be convinced that
>>both of these were excluded from Ada (and every other language I know of
>>with error handling) precisely because experience with PL/I was unfortunate.

> I disagree vehemently.  They were excluded because they were difficult
> to implement.

If you want to accuse the authors of the "Ada '83 Rationale" of lying, 
do it to their faces and leave me out of it.

> Java
> (I believe) with its "try/catch" has effectively tried to re-introduce
> this.  Any other type of error handling is deficient.

Java's try/catch is (as far as this goes) no different from C++'s 
try/catch.  Exception handlers are based on the call stack, with no 
ability to arbitrarily switch from one handler to another at run time, 
and at least one block (the "try" block) must be terminated.  Java's 
only significant addition is the optional "finally" block (a block that 
is executed -- normally resource-release code -- after either successful 
or unsuccessful execution).

-- 
John W. Kennedy
"Only an idiot fights a war on two fronts.  Only
the heir to the throne of the kingdom of idiots
would fight a war on twelve fronts."
   -- "Babylon 5"

Re: Ada Versus PL/I - The debate continues

[Robert I. Eachus]

John W. Kennedy wrote:

> Robin believes that it is a _good_ thing that PL/I allows the run-time
> ON statement to alter the currently-assigned error recovery, and that
> PL/I allows return to point of error, and will not be convinced that
> both of these were excluded from Ada (and every other language I know of
> with error handling) precisely because experience with PL/I was 
> unfortunate.

Let me add a data point here.  When I was working at Stratus, to support 
Ada style error handling, some changes had to be made in VOS, Stratus 
OS, which was written in PL/I so VOS could support both Ada exception 
handling and PL/I condition handling, mix and match, in the (user and 
OS) stack.

At the code review for the OS changes, there was a lot of discussion 
about what the timing effects on the OS would be.  In cases where an ON 
<condition> was ended by leaving the scope, performance would be 
improved, but if a violation of "strict" nesting of condition handlers 
occured, there would be a serious performance impact.  (The nested 
handlers that were not turned off would have to be added back to the 
stack.)  So we took a few benchmark suites and ran them on a modified 
version of VOS, the average was a 2% reduction in time spent in the OS.) 
  This was very surprising--we hadn't realized that the OS spent that 
much time setting and removing condition lists, and walking the stack. 
So we wrote a quick lisp tool to check the OS source for condition 
handlers.  Over 99% of the condition handlers were terminated by exiting 
the block.  (The remaining cases mostly mapped to the Ada idiom of using 
a declare block to attach an exception handler to a single statement.)

What about the wonderful RESUME feature?  We didn't find a single 
instance in VOS.  (I also fixed a known bug in which repeatedly hitting 
the break key could get you to the default_error_handler, even when you 
were not supposed to be able to get there.  Testing that was fun.  The 
test program, of course, could not be exited, except by rebooting the 
computer.  Even then we had to put in an OS feature to allow some 
programs not to be restarted after a power failure.)