RE: ada paper critic

RE: ada paper critic

[Beard, Frank [Contractor]]

> -----Original Message-----
> From: Immanuel Scholz [mailto:news@kutzsche.net]
> 
> 
> Are there benches to graphical libraries? (Are there 
> graphical libraries?)
> 
> 
A quick Google (using "Tartan Ada") came up with 2030 hits.
Here are a couple off the top.

Looks like maybe TI owns them now:

http://focus.ti.com/docs/tool/toolfolder.jhtml?PartNumber=C4X-ADA-XX

Except, on the DDC-I site:

http://www.ddci.com/products_tads_v523.shtml
http://www.ddci.com/products.shtml

Then another reference, but it's dated December 1994.

http://www.adahome.com/Ammo/Stories/Tartan-Realtime.html

Frank

Re: ada paper critic

[Jeffrey Carter]

"Beard, Frank [Contractor]" wrote:
> 
> A quick Google (using "Tartan Ada") came up with 2030 hits.
> Here are a couple off the top.
> 
> Looks like maybe TI owns them now:
> 
> http://focus.ti.com/docs/tool/toolfolder.jhtml?PartNumber=C4X-ADA-XX
> 
> Except, on the DDC-I site:
> 
> http://www.ddci.com/products_tads_v523.shtml
> http://www.ddci.com/products.shtml

IIRC, TI bought Tartan, then sold non-TI targeted compilers to DDC-I.

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

Re: ada paper critic

[Gautier direct_replies_not_read]

Baugereau:

["Real people who care about speed of generated code
(they exist) don't have the choice on many platforms"; C++.]

>Agreed, but if you want to make a complete application such as a
>videogame or a desktop application with only one language, you need
>a more versatile language than Fortran, in my opinion.

Sure, but nothing is simple:
- the performance of videogames depends much on the that of
   video coprocessors (the DOS games on bare (S)VGA were an exception)
- in which proportion are Asm, C, C++ or others used really
   for programming games ? For the same language, are popular
   compilers and tools, or rather specialized, expensive and rare
   tools used ? A video game ought to be crash-free...
- many desktop applications don't really need or use the optimization
   because badly dosed GUI refreshes ruin performance
- my impression (at least looking around in the "business" area)
   is that the really popular language for desktop applications
   is Visual Basic, C++ being seen as "guru language" for "techies"...
____________________________________________________________
Gautier  --  http://www.mysunrise.ch/users/gdm/index.htm#Ada

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


_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

Re: ada paper critic

[Ted Dennison]

Gautier direct_replies_not_read wrote:
> Sure, but nothing is simple:
> - many desktop applications don't really need or use the optimization
>   because badly dosed GUI refreshes ruin performance

If there's a human interface that it has to wait on in the loop, it 
doesn't matter all that much anyway. All computers wait at the same 
speed. :-)

RE: ada paper critic

[Beard, Frank [Contractor]]

> -----Original Message-----
> From: Immanuel Scholz [mailto:news@kutzsche.net]
>
> > Tartan ran on several platforms, which I think included X86's.  I
> > think the may be owned by DDC-I now.
> 
> Have you any uptotime Comparation? What about the speed of the common 
> libraries? ("It doesn't matter how fast the compiler is, when 
> the only avaiable sort algorithm takes sqare-time" ;-)
> 

The question I was replying to wasn't asking about library speeds,
but speed of the generated executables.

No, I don't have any up-to-date comparisons, that was four projects
ago.  We ended up using a different compiler because, at the time,
Tartan didn't have all the functionality that we needed.

We're using Aonix ObjectAda on Windows NT for our current
project because it fits our needs (similarity to MS Visual tools,
decent price, decent GUI Builder, decent performance, etc).

It would be better to contact Tartan (or DDC-I, if that's who
owns them now) to see if they have any current benchmark data.

> Are there benches to graphical libraries? (Are there 
> graphical libraries?)

We wrote our own.  It was a small application to simulate the
type of plotting we would be doing.  We let the vendors compile
it and run it on each of their platforms with their Ada compilers,
with and without suppressing range checking.

Frank

RE: ada paper critic

[Beard, Frank [Contractor]]

> -----Original Message-----
> From: Baugereau [mailto:baugereau@ifrance.kom]
> 
> Agreed. But for raw performance, on many platforms, much more 
> effort has been invested in optimising C or C++ compilers than
> Ada compilers.
> 

I don't know how true that is.

> >
> > > Mhh. What Ada compiler produces faster code than the best 
> C++ compiler on x86 for instance?
> 

It's been several years (maybe 8 now), but when we were looking
for a fast Ada compiler for a unix platform for doing some
high-speed graphics calculations, we wrote a benchmark test and
looked at various performances of various compilers.

At the time Tartan Ada executables outran the Tartan C executables.
What's so impressive about that?  Tartan C compilers also produced
the fastest C executables (which were faster than the C++ exe's).  

Tartan ran on several platforms, which I think included X86's.  I
think the may be owned by DDC-I now.

Frank

RE: ada paper critic

[Immanuel Scholz]

Beard, Frank [Contractor] wrote:

> It's been several years (maybe 8 now), but when we were looking
> for a fast Ada compiler for a unix platform for doing some
> high-speed graphics calculations, we wrote a benchmark test and
> looked at various performances of various compilers.
> 
> At the time Tartan Ada executables outran the Tartan C executables.
> What's so impressive about that?  Tartan C compilers also produced
> the fastest C executables (which were faster than the C++ exe's).
> 
> Tartan ran on several platforms, which I think included X86's.  I
> think the may be owned by DDC-I now.

Have you any uptotime Comparation? What about the speed of the common 
libraries? ("It doesn't matter how fast the compiler is, when the only 
avaiable sort algorithm takes sqare-time" ;-)

Are there benches to graphical libraries? (Are there graphical libraries?)


Immanuel Scholz

Re: ada paper critic

[Lyle McKennot]

Immanuel Scholz <news@kutzsche.net> wrote:

>Tartan Ada

http://www.ddci.com/products_pcnt.shtml

Re: ada paper critic

[Gautier no_direct_reply_please]

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

This is why their use Fortran compilers - why not, after all ?
________________________________________________________
Gautier  --  http://www.mysunrise.ch/users/gdm/gsoft.htm

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


_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

Re: ada paper critic

[Baugereau]

> >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.
>
> This is why their use Fortran compilers - why not, after all ?

Agreed, but if you want to make a complete application such as a videogame
or a desktop application with only one language, you need a more versatile
language than Fortran, in my opinion.
I like Ada, but one has to admit that C++ is popular so C++ tools are more
common and C++ compilers optimize well and popular APIs are in C or C++ and
so on...

Re: ada paper critic

[Ted Dennison]

Baugereau wrote:
> common and C++ compilers optimize well

Not true. Some are quite crappy. Many Ada compilers optimize quite well, 
and some are quite crappy too. You really have to check into this on a 
compiler-by-compiler basis.

> and popular APIs are in C or C++ and

Very few API's are actually in C++. There are some, but C++'s name 
mangling makes them a pain to deal with if you are using any compiler 
other than the one that compiled the API.

For C API's, I don't really care. I can call C API's nearly as easily as 
C code can using any Ada compiler, so why should I care?

Re: ada paper critic

[Gautier no_direct_reply_please]

>Alderson, Paul A. wrote:

>>    MY_BIG_BLOATED_PACKAGE_NAME.MY_BIG_BLOATED_VARIABLE_NAME :=
>>MY_OTHER_BIG_BLOATED_PACKAGE_NAME.MY_BIG_BLOATED_ARRAY_OR_FUNCTION(MY_BIG_BLOATED_GLOBAL_LIT_PACKAGE.AND_OF_COURSE_A_BIG_BLOATED_LITERAL);

Andrew Maizels:

>Yeah, this sucks.  And having to haul in a dozen different packages to do 
>anything useful sucks too.

Let's add that this not the typical style or a required syntax
of Ada, but bad habits of programmers who were accustomed
to punched cards, capital letters, PDP-8 machines and were
resticted to program in FORTRAN-66 or C in their youth.
________________________________________________________
Gautier  --  http://www.mysunrise.ch/users/gdm/gsoft.htm

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


_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

Re: ada paper critic

[Simon Wright]

"Gautier no_direct_reply_please" <gautier_niouzes@hotmail.com> writes:

> >Alderson, Paul A. wrote:
> 
> >>    MY_BIG_BLOATED_PACKAGE_NAME.MY_BIG_BLOATED_VARIABLE_NAME :=
> >>MY_OTHER_BIG_BLOATED_PACKAGE_NAME.MY_BIG_BLOATED_ARRAY_OR_FUNCTION(MY_BIG_BLOATED_GLOBAL_LIT_PACKAGE.AND_OF_COURSE_A_BIG_BLOATED_LITERAL);
> 
> Andrew Maizels:
> 
> > Yeah, this sucks.  And having to haul in a dozen different packages
> > to do anything useful sucks too.
> 
> Let's add that this not the typical style or a required syntax
> of Ada, but bad habits of programmers who were accustomed
> to punched cards, capital letters, PDP-8 machines and were
> resticted to program in FORTRAN-66 or C in their youth.

People who used PDP-8s with ASR33s as the sole I/O device didn't tend
to develop habits like this! It would have been just too much work and
time .. terseness was important.

I admit the ALL CAPS part, though. Until I saw the light in about 1982.

Re: ada paper critic

[Robert A Duff]

"Gautier no_direct_reply_please" <gautier_niouzes@hotmail.com> writes:

> Let's add that this not the typical style or a required syntax
> of Ada, but bad habits of programmers who were accustomed
> to punched cards, capital letters, PDP-8 machines and were
> resticted to program in FORTRAN-66 or C in their youth.

ALL_CAPS *was* the recommended style for Ada 83.
So it doesn't go back to punch cards and the like.

Fortunately, in Ada 95, the recommended style is Not_All_Caps.

- Bob

Re: ada paper critic

[AG]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wccadpwb1dw.fsf@shell01.TheWorld.com...
> "Gautier no_direct_reply_please" <gautier_niouzes@hotmail.com> writes:
>
> > Let's add that this not the typical style or a required syntax
> > of Ada, but bad habits of programmers who were accustomed
> > to punched cards, capital letters, PDP-8 machines and were
> > resticted to program in FORTRAN-66 or C in their youth.
>
> ALL_CAPS *was* the recommended style for Ada 83.
> So it doesn't go back to punch cards and the like.
>

Sorry, could you comment on this a bit more?
I know it was a stated requirement that any
program *can* be written in all capitals, but
recommended?

Re: ada paper critic

[Marin David Condic]

The Ada83 reference manual tended to use all caps for identifiers - not
exactly a "recommendation" but it was the fashionable thing to do (mimmic
the LRM). And its really important to remember that as Ada was emerging into
the light of day, there was still a lot of equipment out in the world that
didn't support lower case. (Line printers being a common example.) Hence it
was quite common at that time for programs in other languages (like Fortran
and Cobol) to be all upper case. Ada style back then was just a reflection
of what was commonly done elsewhere. (To this day, C fashion for things
created with #define is to use all caps.)

But just as women's clothing fashions change on a regular basis, so to do
coding styles. :-)

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


"AG" <a_n_g@x_t_r_a.c_o.n_z> wrote in message
news:M4RO8.4709$iR2.423709@news.xtra.co.nz...
>
> Sorry, could you comment on this a bit more?
> I know it was a stated requirement that any
> program *can* be written in all capitals, but
> recommended?
>
>

Re: ada paper critic

[Robert A Duff]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

> The Ada83 reference manual tended to use all caps for identifiers - not
> exactly a "recommendation"

Hey, you're right.  I must have been thinking of RM83-1.5(13), which
makes a specific recommendation about indentation style.  But I don't
see any recommended casing style (other than the fact that they use a
certain style).

>... but it was the fashionable thing to do (mimmic
> the LRM). And its really important to remember that as Ada was emerging into
> the light of day, there was still a lot of equipment out in the world that
> didn't support lower case. (Line printers being a common example.)

But that can't explain it, because they used lower-case boldface for
reserved words.

Some of those printers *could* support boldface, by backspacing and
overprinting. ;-)

By the way, is it true that Algol 60 and/or Algol 68 was font-sensitive
(i.e. "reserved words" are distinguished by being in boldface)?

- Bob

Re: ada paper critic

[Darren New]

Robert A Duff wrote:
> By the way, is it true that Algol 60 and/or Algol 68 was font-sensitive
> (i.e. "reserved words" are distinguished by being in boldface)?

If I remember correctly, Algol distinguished "the program you see in the
listing" from "the program the compiler compiles." Kind of like "real" algol
is XML, and you could apply different style sheets depending on whether you
were printing it or what. In theory, the reserved words could even be in a
different language.

I suspect what you're thinking is the recommendation that when printed,
reserved words should be printed in boldface. The compilers never required
different fonts. (That was for APL. ;-)

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

[Jeffrey Carter]

Robert A Duff wrote:
> 
> By the way, is it true that Algol 60 and/or Algol 68 was font-sensitive
> (i.e. "reserved words" are distinguished by being in boldface)?

I've never used A68, but I knew someone who used it in the early 1980s
who explained that keywords were somehow distinguishable from other
identifiers. In text this difference was boldface, so calling the
difference "font" seems as good as any. In practice, the compiler
required the keywords to be marked somehow to indicate that they were in
the keyword representation. I don't recall the actual details of how
they were marked. Sorry.

Other things I recall:

The programmer could declare new infix operators. This seemed like a lot
of work for the programmer, and no doubt for the compiler writer.

What Ada calls "type" A68 called "mode". I'm not sure what that was
supposed to mean. "Type" seems better, though still not great, since
usually declaring a type in Ada requires more than just the type
declaration.

These are remarks by an ignorant non-A68 user, so weigh them
appropriately.

-- 
Jeff Carter
"I unclog my nose towards you."
Monty Python & the Holy Grail

Re: ada paper critic

[Rod Haper]

Jeffrey Carter wrote:
> Robert A Duff wrote:
> 
>>By the way, is it true that Algol 60 and/or Algol 68 was font-sensitive
>>(i.e. "reserved words" are distinguished by being in boldface)?
> 
> 
> I've never used A68, but I knew someone who used it in the early 1980s
> who explained that keywords were somehow distinguishable from other
> identifiers. In text this difference was boldface, so calling the
> difference "font" seems as good as any. In practice, the compiler
> required the keywords to be marked somehow to indicate that they were in
> the keyword representation. I don't recall the actual details of how
> they were marked. Sorry.
> 
> Other things I recall:
> 
> The programmer could declare new infix operators. This seemed like a lot
> of work for the programmer, and no doubt for the compiler writer.
> 
> What Ada calls "type" A68 called "mode". I'm not sure what that was
> supposed to mean. "Type" seems better, though still not great, since
> usually declaring a type in Ada requires more than just the type
> declaration.
> 
> These are remarks by an ignorant non-A68 user, so weigh them
> appropriately.
> 


Ah, ALGOL 60, now that brings many very fond memories back to mind.  I 
was fortunate enough to have learned ALOGL 60 as my programming "mother 
tongue" back in the "dark ages" of 1966 on the Burrough's B5500 (a 
wonderfull machine and more very fond memories).  I still have my copy 
of "a guide to ALGOL programming" by Daniel McCracken, 1962.  It uses 
bold type to distinguish ALGOL reserved words from identifier words 
although the convention was to underline them which I recall doing in 
hand-written code.  McCracken notes that on some implementations you 
could use the same name for an identifier as an ALGOL reserved word if 
the ALGOL reserved word is set off by distinguishing marks such as 
quotes or dollar signs so that there is no confusion - ala, 'true' and 
true and $while$ and while.  I don't recall ever doing this on the B5500 
but the $ sign usage does ring a bell - aleit very faintly after all 
these years - we almost certainly would have avoided this practice.  As 
for declaring new infix operators, that must have been a part of ALGOL 
68 which, saddly, I never had an opportunity to use.

-- 
Rod

+----------------------------------+
|     There is a better way ...    |
|   LAP => Linux + Ada95 + Python  |
+----------------------------------+

Re: ada paper critic

[Ted Dennison]

Robert A Duff wrote:
> ALL_CAPS *was* the recommended style for Ada 83.
> So it doesn't go back to punch cards and the like.

By whom? We never used all caps on any of the 4 large Ada 83 projects I 
worked on. Since the first one was the first project anyone there had 
ever done in Ada, and mixed case was in the project standard, I have to 
think we got it from somewhere else.

Re: ada paper critic

[Robert A Duff]

Ted Dennison <dennison@telepath.com> writes:

> Robert A Duff wrote:
> > ALL_CAPS *was* the recommended style for Ada 83.
> > So it doesn't go back to punch cards and the like.
> 
> By whom?

The Ada 83 Reference Manual recommended all caps for identifiers,
and lower case for reserved words.  The fact that *something* was
supposed to be in lower case indicates that they weren't concerned about
devices incapable of doing lower case.

>... We never used all caps on any of the 4 large Ada 83 projects I 
> worked on.

Neither did I.  All caps is so ugly that a lot of people ignored the RM
advice.  However, I was a consultant at Alsys (Jean Ichbiah's company)
for a while, and they used ALL_CAPS identifiers as recommended by the
Standard, so of course I conformed to that style while there.

I believe I've read studies that show mixed case and lower case to be
more readable than all caps.  The reason, they speculated, is that the
shape of a word in all caps is a simple rectangle, whereas the shape of
a word in lower case has ascenders and descenders that help one
recognize the word by its shape.  I can't give a cite (sorry) -- this
was many years ago.

>... Since the first one was the first project anyone there had 
> ever done in Ada, and mixed case was in the project standard, I have to 
> think we got it from somewhere else.

- Bob

Re: ada paper critic

[Kevin Cline]

Robert A Duff <bobduff@shell01.TheWorld.com> wrote in message news:<wccn0turfmp.fsf@shell01.TheWorld.com>...
> Ted Dennison <dennison@telepath.com> writes:
> 
> > Robert A Duff wrote:
> > > ALL_CAPS *was* the recommended style for Ada 83.
> > > So it doesn't go back to punch cards and the like.
> > 
> > By whom?
> 
> The Ada 83 Reference Manual recommended all caps for identifiers,
> and lower case for reserved words.  The fact that *something* was
> supposed to be in lower case indicates that they weren't concerned about
> devices incapable of doing lower case.
> 
> >... We never used all caps on any of the 4 large Ada 83 projects I 
> > worked on.
> 
> Neither did I.  All caps is so ugly that a lot of people ignored the RM
> advice.  However, I was a consultant at Alsys (Jean Ichbiah's company)
> for a while, and they used ALL_CAPS identifiers as recommended by the
> Standard, so of course I conformed to that style while there.
> 
> I believe I've read studies that show mixed case and lower case to be
> more readable than all caps.  The reason, they speculated, is that the
> shape of a word in all caps is a simple rectangle, whereas the shape of
> a word in lower case has ascenders and descenders that help one
> recognize the word by its shape.  I can't give a cite (sorry) -- this
> was many years ago.

I don't need a study to tell me that.  ALL I NEED IS A SHORT TEXT SAMPLE
LIKE THIS ONE AND IT BECOMES QUITE OBVIOUS that mixed case is much easier
to read.

Re: ada paper critic

[Robert A Duff]

kcline17@hotmail.com (Kevin Cline) writes:

> I don't need a study to tell me that.  ALL I NEED IS A SHORT TEXT SAMPLE
> LIKE THIS ONE AND IT BECOMES QUITE OBVIOUS that mixed case is much easier
> to read.

Looks that way to me, too.  But that proves nothing except that you and
I are used to mixed case.

- Bob

Re: ada paper critic

[Larry Kilgallen]

In article <wcck7owxq8i.fsf@shell01.TheWorld.com>, Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> kcline17@hotmail.com (Kevin Cline) writes:
> 
>> I don't need a study to tell me that.  ALL I NEED IS A SHORT TEXT SAMPLE
>> LIKE THIS ONE AND IT BECOMES QUITE OBVIOUS that mixed case is much easier
>> to read.
> 
> Looks that way to me, too.  But that proves nothing except that you and
> I are used to mixed case.

When I have my way, I use uppercase identifiers lowercase keywords,
and mixed case comments.

My reasons are the same as yours.  The mixed case attracts the reader,
and I want the attraction to be to the comments, where the non-obvious
is stated.

RE: ada paper critic

[Alderson, Paul A.]

Immanuel,

If you look at just the language then I'd have to say Ada programs are less
readable than C or C++ programs.  I'm not talking about just style either,
but the actual syntax of the language.  For example:

Ada code:

   MY_BIG_BLOATED_PACKAGE_NAME.MY_BIG_BLOATED_VARIABLE_NAME :=
MY_OTHER_BIG_BLOATED_PACKAGE_NAME.MY_BIG_BLOATED_ARRAY_OR_FUNCTION(MY_BIG_BL
OATED_GLOBAL_LIT_PACKAGE.AND_OF_COURSE_A_BIG_BLOATED_LITERAL);

C code:

       (for an array)
   nDaysInMonth = nMonthTable[JAN];

       (for a function)
   nDaysInMonth = nMonthLookup(JAN);

The main point here is that the Ada code above requires one to go and lookup
what MY_BIG_BLOATED_ARRAY_OR_FUNCTION is.  Is it a function or an array?
Who knows?  The other not so subtle point is that Ada programs tend to use
very large variable names.  Probably because many projects insist that "use"
is a bad thing and require the package to be specified.  And since we want
the package name to be descriptive everything referenced inside it uses
allot of textual real-estate.  Therefore I personally think of Ada as a
write only language.


Another issue that is often overlooked is that the computer language can not
realistically be treated as a stand-alone unit.  Sure if you want to argue
about "what ifs" or are into fantasy writings....  Here is where Ada falls
by tripping over a steel girder onto its' face into a titanium floor.  The
big issues of why Ada is either dead or in severe decline are:

(And the top ten "Why Ada is dead" reasons are!:)

	1.) Ada is not taught anymore. (Never really ever were that many
classes for it.)
		(Why the DOD had to drop the requirement!)
	2.) Ada development environments lag 10 years behind MSVC for
example.
	3.) Ada has no nice string handling capabilities.  
         (Yeah yeah yeah library XYZ does...is it in the standard
distribution?)
	4.) Ada has no in-expensive development suits that are easy to use.
	5.) The Ada language is based upon hardware notions such as integers
being a certain size and etc.
		(Would not it have had been better to make numeric
declarations fit their use instead
             of forcing the programmer to think about the computer
hardware?)
		Example:
			If I want a number that represents the month in
terms of a whole value
			would not the following be a better way:

			month : 1..12;

			Do I care that a byte or int is allocated?  If I do
then I'll say so!
			One might argue that you CAN DO RANGES, but my
pre-emptive counter point is
                  that one does not have to use pointers in C either!
Meaning why does integer
			exist?

      6.) GENERICS GENERICS GENERICS
		If the programmer used generics heavily and you must certify
to level-A you either:
			A.) Test one instance and say the rest are the same
(hopefully)
			B.) Incur huge verification costs.
	7.) When all else fails - unchecked conversion - sometimes just
because!
	8.) Unhandled exception in the library?  Now what?
	9.) Write to comp.lang.ada you'll get an answer there! - NOT!
	10.) Getting my marshmellows out!

He he he....just being sarcastic in 7 through 10, but there are hints of
truth in there.
To be fair Ada does have its beneficial side, but it comes at a high price.
People will argue that its that much safer and better and you can't be safe
with C.  When you point out the use of LINT they then interject that its an
additional cost and not part of the language.  But it still is available and
essentially gets you Ada type checking and great analysis of your code (even
style!).  So pretty much in my eyes all current languages are severely
flawed in one aspect or another.  It all really boils down to good software
people - not the language.  Just remember things have gone boom using Ada
and things have gone boom using C.  So it seems that the language can't
prevent these things!  The overall point is that Ada is not the answer to
everything.

Paul Alderson



> -----Original Message-----
> From: Immanuel Scholz [mailto:news@kutzsche.net]
> Sent: Thursday, June 13, 2002 7:49 PM
> To: comp.lang.ada@ada.eu.org
> Subject: ada paper critic
> 
> 
> 
> 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

[Darren New]

"Alderson, Paul A." wrote:
>         3.) Ada has no nice string handling capabilities.
>          (Yeah yeah yeah library XYZ does...is it in the standard
> distribution?)

Uh, yes.

>         5.) The Ada language is based upon hardware notions such as integers
> being a certain size and etc.

Uh, no. You're getting confused with C.

>                         If I want a number that represents the month in
> terms of a whole value
>                         would not the following be a better way:
> 
>                         month : 1..12;
> 
>                         Do I care that a byte or int is allocated?  If I do
> then I'll say so!


>                         One might argue that you CAN DO RANGES, but my
> pre-emptive counter point is
>                   that one does not have to use pointers in C either!

This is untrue. Every time you have an array in C you're using a pointer.

> Meaning why does integer
>                         exist?

It's a name for what's called a "base type".
 
>       6.) GENERICS GENERICS GENERICS
>                 If the programmer used generics heavily and you must certify
> to level-A you either:
>                         A.) Test one instance and say the rest are the same
> (hopefully)
>                         B.) Incur huge verification costs.

As opposed to what?

>         7.) When all else fails - unchecked conversion - sometimes just
> because!

If you're doing unchecked conversions "just because", then you're
programming in C, not Ada.

>         8.) Unhandled exception in the library?  Now what?

You catch it and handle it, unlike Java where it won't even compile. :-)

>         9.) Write to comp.lang.ada you'll get an answer there! - NOT!
>         10.) Getting my marshmellows out!

Marshmallows.
 
> essentially gets you Ada type checking and great analysis of your code (even

Err, no. Lint is not going to tell you if you assign 14 to a month.

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

[Andrew Maizels]

Alderson, Paul A. wrote:

>    MY_BIG_BLOATED_PACKAGE_NAME.MY_BIG_BLOATED_VARIABLE_NAME :=
> MY_OTHER_BIG_BLOATED_PACKAGE_NAME.MY_BIG_BLOATED_ARRAY_OR_FUNCTION(MY_BIG_BL
> OATED_GLOBAL_LIT_PACKAGE.AND_OF_COURSE_A_BIG_BLOATED_LITERAL);

Yeah, this sucks.  And having to haul in a dozen different packages to 
do anything useful sucks too.

> The main point here is that the Ada code above requires one to go and lookup
> what MY_BIG_BLOATED_ARRAY_OR_FUNCTION is.  Is it a function or an array?

This is a deliberate design feature.  I'm not sure whether I agree 
entirely or not.  But if you use [] for arrays and () for functions, 
what do you use for hashes and other structures where the lookup is 
actually performed by a function?

> Who knows?  The other not so subtle point is that Ada programs tend to use
> very large variable names.  Probably because many projects insist that "use"
> is a bad thing and require the package to be specified.  And since we want
> the package name to be descriptive everything referenced inside it uses
> allot of textual real-estate.  Therefore I personally think of Ada as a
> write only language.

To which I reply:
   if (++*(int *)*pc<*(int *)*(pc+1)) pc=*(pc+2);
(just something from a project I'm working on).

> Another issue that is often overlooked is that the computer language can not
> realistically be treated as a stand-alone unit.  Sure if you want to argue
> about "what ifs" or are into fantasy writings....  Here is where Ada falls
> by tripping over a steel girder onto its' face into a titanium floor.  The
> big issues of why Ada is either dead or in severe decline are:
> 
> (And the top ten "Why Ada is dead" reasons are!:)
> 
> 	1.) Ada is not taught anymore. (Never really ever were that many
> classes for it.)

Maybe.

> 	2.) Ada development environments lag 10 years behind MSVC for
> example.

I don't care for MSVC, but many people are lost without that sort of 
environment.  I haven't seen the commercial Ada environments, though, so 
I'm not sure you're right here.

> 	3.) Ada has no nice string handling capabilities.  
>          (Yeah yeah yeah library XYZ does...is it in the standard
> distribution?)

Huh?  Ada's string handling is just peachy.  It's annoying that there 
are six different string types, but everything you could ask for is there.

C, on the other hand, has the worst string handling of any major 
language.  C strings are *EVIL*.

> 	4.) Ada has no in-expensive development suits that are easy to use.

Gnat is easy to use.  Not flashy, but easy enough.

> 	5.) The Ada language is based upon hardware notions such as integers
> being a certain size and etc.
> 		(Would not it have had been better to make numeric
> declarations fit their use instead
>              of forcing the programmer to think about the computer
> hardware?)
> 		Example:
> 			If I want a number that represents the month in
> terms of a whole value
> 			would not the following be a better way:
> 
> 			month : 1..12;
> 
> 			Do I care that a byte or int is allocated?  If I do
> then I'll say so!

Again, huh?  I can specify a subrange if I want.  I can specify a 
precise number of bits if I want, too.  And C gives me, what?  Short is 
no longer than int, and long is no shorter than int.  Wonderful.

> 			One might argue that you CAN DO RANGES, but my
> pre-emptive counter point is
>                   that one does not have to use pointers in C either!
> Meaning why does integer
> 			exist?

As far as I can tell, this is a complete non-sequitur.

>       6.) GENERICS GENERICS GENERICS
> 		If the programmer used generics heavily and you must certify
> to level-A you either:
> 			A.) Test one instance and say the rest are the same
> (hopefully)
> 			B.) Incur huge verification costs.

Compared to what?

[snip]

> To be fair Ada does have its beneficial side, but it comes at a high price.
> People will argue that its that much safer and better and you can't be safe
> with C.  When you point out the use of LINT they then interject that its an
> additional cost and not part of the language.  But it still is available and
> essentially gets you Ada type checking and great analysis of your code (even
> style!).  So pretty much in my eyes all current languages are severely
> flawed in one aspect or another.  It all really boils down to good software
> people - not the language.  Just remember things have gone boom using Ada
> and things have gone boom using C.  So it seems that the language can't
> prevent these things!  The overall point is that Ada is not the answer to
> everything.

There's still no silver bullet, it's true.  I find C better when I want 
to get close to the metal; I can look at a line of C and be pretty sure 
how the executable will come out.  But errors in my C code tend to make 
my program crash in strange and wonderful ways, while Ada catches the 
problem at compile time.  Lint doesn't come close to the kind of 
compile-time and run-time safety that Ada offers.

Andrew.
-- 
This sig no verb.

Re: ada paper critic

[chris.danx]

"Andrew Maizels" <pixymisa@ozemail.com.au> wrote in message
news:3D0A1293.5000005@ozemail.com.au...
> Alderson, Paul A. wrote:
>
> >    MY_BIG_BLOATED_PACKAGE_NAME.MY_BIG_BLOATED_VARIABLE_NAME :=
> >
MY_OTHER_BIG_BLOATED_PACKAGE_NAME.MY_BIG_BLOATED_ARRAY_OR_FUNCTION(MY_BIG_BL
> > OATED_GLOBAL_LIT_PACKAGE.AND_OF_COURSE_A_BIG_BLOATED_LITERAL);

It's considered good style to reserve capitals for constants.


> Yeah, this sucks.  And having to haul in a dozen different packages to
> do anything useful sucks too.


Have either of you tried improving readability with local use clauses
instead of global ones?

e.g.

procedure My_Big_Bloated_Procedure is
begin
   My_Package.My_Variable_Name :=
     My_Other_Package.My_Function (var_one, var_two);
end My_Big_Bloated_Procedure;

goes to

procedure My_Big_Bloated_Procedure is
use My_Package;
use My_Other_Package;

begin
   My_Variable_Name := My_Function (var_one, var_two);
end My_Big_Bloated_Procedure;


It's a compromise between the two extremes.

> > The main point here is that the Ada code above requires one to go and
lookup
> > what MY_BIG_BLOATED_ARRAY_OR_FUNCTION is.  Is it a function or an array?

[refers to earlier post]

Functions is similar to arrays (but not the otherway  A function is a
mapping from the domain to the codomain.  For programming we compute the
answer, but it'd be equally valid to define a function in terms of a set of
tuples (inputs, result).  Given an input, you can return the appropriate
result.  e.g.

function negate (x : in boolean) return boolean is
begin
   if x = true then
      return false;
   end if;
   return true;
end not;

Can be given in like this {(false, true), (true, false)}.  You can now drop
in the array as a replacement,

negate : constant array (boolean) of boolean := (true, false);


The syntax allows you to replace a function with an array, which you might
want to do if the domain is small and the function non-trivial.  That might
help improve the speed of a program dependant on the function a lot (In some
cases it might be possible for the compiler to do even better, eleminating
the address computation in the final program, i.e. if x never changes and a
never changes, then a(x) is always the same, but that'd only work in certain
circumstances).

This is done in graphics programming since the cost of computing the address
of the element corresponding to an angle is cheaper computing the cosine and
sine of that angle over and over.  In Ada you don't need to be conciously
aware of that by using a different syntax.


> > Another issue that is often overlooked is that the computer language can
not
> > realistically be treated as a stand-alone unit.  Sure if you want to
argue
> > about "what ifs" or are into fantasy writings....  Here is where Ada
falls
> > by tripping over a steel girder onto its' face into a titanium floor.
The
> > big issues of why Ada is either dead or in severe decline are:
> >
> > (And the top ten "Why Ada is dead" reasons are!:)
> >
> > 1.) Ada is not taught anymore. (Never really ever were that many
> > classes for it.)
>
> Maybe.

there is atleast one uni in Scotland (I remember seeing another one, but not
sure) teaching Ada and one down south.  It might not be taught much but it
is still taught.

Just found this, don't know how current it is though,
http://sw-eng.falls-church.va.us/ajpo_databases/colleges_universities_nonusa
.html



> > 3.) Ada has no nice string handling capabilities.
> >          (Yeah yeah yeah library XYZ does...is it in the standard
> > distribution?)
>
> Huh?  Ada's string handling is just peachy.  It's annoying that there
> are six different string types, but everything you could ask for is there.
>
> C, on the other hand, has the worst string handling of any major
> language.  C strings are *EVIL*.
>
> > 4.) Ada has no in-expensive development suits that are easy to use.
>
> Gnat is easy to use.  Not flashy, but easy enough.

Plus GNAT can be used with AdaGIDE, emacs, ConTEXT, jGrasp or any other good
editor just like every other command line orientated compiler.  GUI building
tools are slightly lacking, but that situation will get better with time.


Chris

Re: ada paper critic

[Jeffrey Carter]

"chris.danx" wrote:
> 
> "Andrew Maizels" <pixymisa@ozemail.com.au> wrote in message
> news:3D0A1293.5000005@ozemail.com.au...
> > Alderson, Paul A. wrote:
> >
> > >    MY_BIG_BLOATED_PACKAGE_NAME.MY_BIG_BLOATED_VARIABLE_NAME :=
> > >
> MY_OTHER_BIG_BLOATED_PACKAGE_NAME.MY_BIG_BLOATED_ARRAY_OR_FUNCTION(MY_BIG_BL
> > > OATED_GLOBAL_LIT_PACKAGE.AND_OF_COURSE_A_BIG_BLOATED_LITERAL);
> 
> It's considered good style to reserve capitals for constants.

No, all caps should only be used for acronyms. Standard Ada style is to
use lower case for reserved words and initial caps for all other
identifiers.

More importantly, no competent software engineer uses global variables.
Alderson's use of global variables indicates that he is not competent to
have an opinion on the subject.

Finally, this is clearly a troll. Let us all show the superiority of
those who use Ada by never responding to trolls.

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

Re: ada paper critic

[Immanuel Scholz]

Jeffrey Carter wrote:

> Finally, this is clearly a troll. Let us all show the superiority of
> those who use Ada by never responding to trolls.

Actually he is the only one trying to filter out some arguments AGAINST ada 
(sometimes more destructive than constructive).

I thank him for his posting for doing so ;-)

(Nevertheless, I think that giving the same syntax to Arrays and functions 
is good, not bad.)


Immanuel Scholz

Re: ada paper critic

[Ehud Lamm]

"Immanuel Scholz" <news@kutzsche.net> wrote in message
news:aedjfi$63on9$1@ID-100557.news.dfncis.de...
> Jeffrey Carter wrote:
>
> > Finally, this is clearly a troll. Let us all show the superiority of
> > those who use Ada by never responding to trolls.
>

Right!


> Actually he is the only one trying to filter out some arguments AGAINST
ada
> (sometimes more destructive than constructive).
>

No. Most of them are simply incorrect. So he is not really helping you (the
OP).

Ada is not perfect, but understanding the weak points in a language is not
easy. You have to undersand the language itself quite well.
You may check Ada-Issues and the ARG mailing list, for some problems people
are trying to fix with the language.
You may also use the language for awhile.
I agree that a nice discussion of problems with the language can be an
interesting read. Perhaps you can learn something from the issues raised
about Ada83 when Ada95 was designed.

I can't get into many details here, and each issue itself is controversial.
But I agree that sometimes automatic template instantiation can be nice. I
also think template specialization can be quite useful.
I would like larger (STL like) standard library (well, you all know that by
now...).

There are many other issues, I think the question itself is to broad. If you
want to gain insight choose some area a bit more specific to think/ask about
(e.g., generics, OOP, or whatever).


Ehud Lamm

Re: ada paper critic

[Immanuel Scholz]

Ehud Lamm wrote:
>> > Finally, this is clearly a troll. Let us all show the superiority of
>> > those who use Ada by never responding to trolls.
> 
> Right!

Wrong. Sometimes only provocative statements can change you from a local 
maximum of tapping yourself on the shoulder, if you get my mind.



> No. Most of them are simply incorrect. So he is not really helping you
> (the OP).
> 
> Ada is not perfect, but understanding the weak points in a language is not
> easy. You have to undersand the language itself quite well.
> You may check Ada-Issues and the ARG mailing list, for some problems
> people are trying to fix with the language.
> You may also use the language for awhile.
> I agree that a nice discussion of problems with the language can be an
> interesting read. Perhaps you can learn something from the issues raised
> about Ada83 when Ada95 was designed.

Maybe I was searching not for a too philosophic answer. I am actually 
interested more in a somewhat dirty reply - the paper I have to write is 
not as academic as it should be.

But you are right. I should learn (and I am willing to) more about Ada. It 
seems quite fascinating to me, especially because it is significant harder 
to write really nasty code in ada.


> I can't get into many details here, and each issue itself is
> controversial. But I agree that sometimes automatic template instantiation
> can be nice. I also think template specialization can be quite useful.
> I would like larger (STL like) standard library (well, you all know that
> by now...).

Maybe... but it is a powerful weapon that can be used against you. I prefer 
languages without too powerful weapons (my definition for too powerful ends 
somewhere about "operator-overloading" ;-).
(The extense use of pointer arithmetic is the wordst and most powerful 
weapon in C).


> There are many other issues, I think the question itself is to broad. If
> you want to gain insight choose some area a bit more specific to think/ask
> about (e.g., generics, OOP, or whatever).

What about the operator overloading possibilities in ada?


One disadvantage I recovered up to now is the lack of a GUI-Library to 
develop on the graphical sector. Are there any library out (beside GTK's)? 



Immanuel Scholz

Re: ada paper critic

[sk]

Hi,

> ... harder to write really nasty code in ada.

Are you sure ? 

I personally have had no problems whatsover in writing 
truly dreadfull code in Ada and enjoyed every minute 
of it.

> (The extense use of pointer arithmetic is the wordst 
> and most powerful weapon in C).

Are you under the (false) impression that you cannot 
totally hose the memory with Ada and address arithmetic ?

Again, tons of fun !

> What about the operator overloading possibilities in ada?

type My_Natural is new Natural;

function "+"(A, B : My_Natural) return My_Natural is
begin
    return 0;
end "+";

Yep this is fun too. If this definition is not in an
obvious location it can take a long time to debug
when this bites you.

> Sometimes only provocative statements ...

That is BS and you know it.

-- 
-------------------------------------
-- Merge vertically for real address
-------------------------------------
s n p @ t . o
 k i e k c c m
-------------------------------------

Re: ada paper critic

[Immanuel Scholz]

sk wrote:

> Hi,
> 
>> ... harder to write really nasty code in ada.
> 
> Are you sure ?
> 
> I personally have had no problems whatsover in writing
> truly dreadfull code in Ada and enjoyed every minute
> of it.

I do not neglate the possibility to do such things, but I would not employ 
you ;-)


>> (The extense use of pointer arithmetic is the wordst
>> and most powerful weapon in C).
> 
> Are you under the (false) impression that you cannot
> totally hose the memory with Ada and address arithmetic ?
> 
> Again, tons of fun !

Hopeful in Ada to juggle with pointers is not the common practise? At 
least I heard so.


>> What about the operator overloading possibilities in ada?
> 
> type My_Natural is new Natural;
> 
> function "+"(A, B : My_Natural) return My_Natural is
> begin
>     return 0;
> end "+";

Surely you can do harm with a weapon. If you do it willful, there is 
nothing to do against it. But overloading assignment creates usually not 
willful errors.


>> Sometimes only provocative statements ...
> 
> That is BS and you know it.

Of course. 

I want to give some self proven posting. (And it was late of the day after 
pillaging several pubs as I posted this ;-)

Immanuel Scholz

Re: ada paper critic

[sk]

Hi,

Immanuel Scholz <news@kutzsche.net>
> ... but I would not employ ... you ;-)

I am so sorry if I have offended you in any way. 
I should have realized that every point you make 
is totally valid and that I am but a speck of 
dust in your magnificance.

If you want me to polish your shoes aswell, that
will be an extra $50 an hour, spelling will add
another $10 :-)

> But overloading assignment creates usually not 
> willful errors.

See the other sub-thread and plan your next April
fools day :-)

-- 
-------------------------------------
-- Merge vertically for real address
-------------------------------------
s n p @ t . o
 k i e k c c m
-------------------------------------

Re: ada paper critic

[Ted Dennison]

sk wrote:
>>... harder to write really nasty code in ada.
> 
> 
> Are you sure ? 

I am. Its certianly not impossible, (or even very tough for the 
committed incompetent programmer) but its definitely harder.

>>(The extense use of pointer arithmetic is the wordst 
>>and most powerful weapon in C).
> 
> 
> Are you under the (false) impression that you cannot 
> totally hose the memory with Ada and address arithmetic ?

You can indeed. However, the language doesn't out and out encourage it 
like C does. Its not a common idiom in Ada, and most newbies would have 
to do a lot of work to figure out how to do it. I C, all you have to do 
is use the predefined "+" operator.


>>What about the operator overloading possibilities in ada?
> 
> function "+"(A, B : My_Natural) return My_Natural is
> begin
>     return 0;
> end "+";

Actually, one I actually did to myself was to rename "<" to ">". That 
took me quite a while to track down too. :-(

Of course that was in Ada83. With Ada95 the main reason for renaming 
functions is gone, taking this source of error with it (for me at least).

Re: ada paper critic

[sk]

Hi,

> Ted Dennison <dennison@telepath.com>
> for the committed incompetent programmer)

As I said, Hi :-)


>>>What about the operator overloading possibilities in ada
>> function "+"(A, B : My_Natural) return My_Natural is
>Actually, one I actual ... rename "<" to ">" ... Ada83

Yep, using the old text book method to reverse the 
sort order of a generic IIRC.

The whole function renaming can provide hours of
amusement and general naughtiness :

Ingredients :
1) A pain in the ass group member.
2) That group member always "use"s "My_Utilities" for
personal scripting needs (my-utilities being his own
package).
3) Bad security or unlocked terminal.
4) My original example of "+" on Naturals
5) A random number generator in the body.


-- 
-------------------------------------
-- Merge vertically for real address
-------------------------------------
s n p @ t . o
 k i e k c c m
-------------------------------------

Re: ada paper critic

[Gautier]

Ted Dennison:

> Actually, one I actually did to myself was to rename "<" to ">". That 
> took me quite a while to track down too. :-(

A nice way of self-shooting is also to trust too much the
safety of "in" and "out" parameters...

  procedure P(x: in t; y: out t) is
  ...

  z: t;
  P(z,z);

No warning (from the compilers I know) and a lot of amusement too,
especially when P calls Q and so on!

Is there a list for such things ?
________________________________________________________
Gautier  --  http://www.mysunrise.ch/users/gdm/gsoft.htm

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

Re: ada paper critic

[AG]

"sk" <noname@myob.com> wrote in message
news:mailman.1024094403.17747.comp.lang.ada@ada.eu.org...
> > What about the operator overloading possibilities in ada?
>
> type My_Natural is new Natural;
>
> function "+"(A, B : My_Natural) return My_Natural is
> begin
>     return 0;
> end "+";
>
> Yep this is fun too. If this definition is not in an
> obvious location it can take a long time to debug
> when this bites you.

Well, you must be a bit slow debugging-wise ;)
It's a very nice, well-determined, 100% reproducible
bug. Should only take a few seconds to trace through
the code and see where it comes from. I only wish
all the bugs were that easy...

Re: ada paper critic

[Gautier]

sk:

> > function "+"(A, B : My_Natural) return My_Natural is
> > begin
> >     return 0;
> > end "+";
> >
> > Yep this is fun too. If this definition is not in an
> > obvious location it can take a long time to debug
> > when this bites you.

AG:

> Well, you must be a bit slow debugging-wise ;)
> It's a very nice, well-determined, 100% reproducible
> bug. Should only take a few seconds to trace through
> the code and see where it comes from. I only wish
> all the bugs were that easy...

Not so sure: if you inline that "+" function, the optimization
is on, and the "victim" is not prepared to search such a strange
bug it guess it could take more than "a few seconds"!
________________________________________________________
Gautier  --  http://www.mysunrise.ch/users/gdm/gsoft.htm

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

Re: ada paper critic

[tmoran]

>One disadvantage I recovered up to now is the lack of a GUI-Library to
>develop on the graphical sector. Are there any library out (beside GTK's)?
  There are several bindings, of varying thickness, for MS Windows.
Is that what you mean by GUI-Library?

Re: ada paper critic

[Ted Dennison]

Immanuel Scholz wrote:
> Actually he is the only one trying to filter out some arguments AGAINST ada 
> (sometimes more destructive than constructive).

True. Unfortunately, all his points range from 180 degrees wrong to just 
ignorant. When someone is so wrong so consistently over so much stuff, 
you have to think that we are dealing with a case where someone has an 
agenda and it trying to make the facts fit it instead of the other way 
around.

> (Nevertheless, I think that giving the same syntax to Arrays and functions 
> is good, not bad.)

We've actually had a lot of discussion here about that. Almost everyone 
who ever complains about it is an ex-C programmer who's main problem 
always boils down to "it doesn't look like C".

I have very little patience for people who have problems with Ada not 
looking like C. Ada was just about the most thouroughly designed 
language ever, while C was thrown together in a lab over the weekend. 
You might not agree with all of the reasoning, but at least there is a 
rational reason for nearly every difference Ada has.

On the other hand, most of the approaches C took were based on either 
historical accidents, spontaneious whims, or whatever was the quickest 
hack to solve a language problem that day. Perhaps one or two good 
things came out of it, but there's no good coherent design in there at 
all. The only reason people are still using it is that the lab guys who 
created it built the first Unix with it, not because the language itself 
is any good.

Thus, arguing that all languages should use the same features as C is 
like saying all piles of trash should have bannana peels and moudly 
oranges on the bottom because that's the way the biggest mound in the 
dump ended up.

Re: ada paper critic

[Darren New]

Ted Dennison wrote:
> Thus, arguing that all languages should use the same features as C is
> like saying all piles of trash should have bannana peels and moudly
> oranges on the bottom because that's the way the biggest mound in the
> dump ended up.

Fabulous! May I use this elsewhere? :-)

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

Darren New wrote:
> Fabulous! May I use this elsewhere? :-)

Err, sorry. That was supposed to be private mail. :-)

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

[Immanuel Scholz]

Ted Dennison wrote:

> Immanuel Scholz wrote:
> True. Unfortunately, all his points range from 180 degrees wrong to just
> ignorant. When someone is so wrong so consistently over so much stuff,
> you have to think that we are dealing with a case where someone has an
> agenda and it trying to make the facts fit it instead of the other way
> around.

I got most of the real good postings in response to his bad one. This gives 
me two validations:
First, he is either a good psychological skilled troll or a lucky one.
Second, this newsgroup rocks because of not starting a boring flamewar on 
top of this. :-)


>> (Nevertheless, I think that giving the same syntax to Arrays and
>> functions is good, not bad.)
> 
> We've actually had a lot of discussion here about that. Almost everyone
> who ever complains about it is an ex-C programmer who's main problem
> always boils down to "it doesn't look like C".

I am an (ex-)C programmer too, and most part of the time I complain about 
sitting hours before large trees of code and change occourences of a[b] 
into a(i) because a became a function instead of an array. ;-)

Another similar problem:
Are there any kind of "property" like in delphi or "Trolltechs way of C++" 
in Ada - means, can I hide the fact, that an access to a variable or 
member-variable is just a function call and via versa?


> I have very little patience for people who have problems with Ada not
> looking like C. 

I remember this was a very large thread in a newsgroup some years before 
when someone complaint, that C simple does not looks like Pascal ;-). Then 
the time for 

#define begin {
#define Begin {
#define BEGIN {
#define end; }
#define End; }
#define END; }

started. THIS was bad times... ;-)


> Ada was just about the most thouroughly designed
> language ever, while C was thrown together in a lab over the weekend.

And second: Ada was not such a stupid overloaded commitee-bullshit like 
ALGOL or even IPSec. (Although I believe in Ada are some useless things 
too).


> On the other hand, most of the approaches C took were based on either
> historical accidents, spontaneious whims, or whatever was the quickest
> hack to solve a language problem that day. Perhaps one or two good
> things came out of it, but there's no good coherent design in there at
> all. The only reason people are still using it is that the lab guys who
> created it built the first Unix with it, not because the language itself
> is any good.

There comes a dangerous spirit of coolness with C. Someone described it 
like this:

- First you are a newbie. Then all programming languages looks very 
complicated and you choose a descriptive one like BASIC.
- Then you are a newbie hacker with an amazing overestimation of self. 
(Look at www.hydixos.de for an example to all german capables of you ;-)
Then you are searching for a cool-looking language. Cool-looking is nothing 
you used before and what stupid newbies use! It must be a real cryptic like 
C.
- At the last you become aware of the huge problems with C, but then you 
are used to them and usually are too lazy to switch. Then you start to 
search extensive for any reason C is a good choice, although you KNOW it is 
not. You will clutch yourself on every straw you see which might be any 
argument in favour of choosing C, completly disable your judgement.


Immanuel Scholz

Re: ada paper critic

[Brian Rogoff]

On Mon, 17 Jun 2002, Immanuel Scholz wrote:
> Ted Dennison wrote:
> > Immanuel Scholz wrote:
> >> (Nevertheless, I think that giving the same syntax to Arrays and
> >> functions is good, not bad.)
> >
> > We've actually had a lot of discussion here about that. Almost everyone
> > who ever complains about it is an ex-C programmer who's main problem
> > always boils down to "it doesn't look like C".

Unsupported ad-hominem argument. I certainly wish that Ada used different
bracketing for arrays, and the reason it doesn't is unfortunate. However,
this is never going to change in Ada so it isn't worth spending a lot of
time discussing it in the context of Ada revisions, though if you're
talking about a brand new language I suppose it's fair game. Better to
devote some effort to fixable flaws of Ada.

Any fan of Wirth designed languages might also be tarred with the same
brush used on C programmers here.

> I am an (ex-)C programmer too, and most part of the time I complain about
> sitting hours before large trees of code and change occourences of a[b]
> into a(i) because a became a function instead of an array. ;-)

That may be, but any Ada True Believer will chant that in Ada, we don't
give a !@#$ for the writer of programs, we only care about the reader.

Lot's of inane anti-C stuff deleted.

-- Brian

Re: ada paper critic

[Marin David Condic]

As an Ada True Believer in good standing and one who has used the language
for a long number of years, I can honestly say that I cannot recall ever
having decided to change an array reference into a function call, or the
other way around. Maybe its just me. Maybe it was the application domains I
have worked in. But generally, by the time I got to coding something up, the
architecture of the program was pretty well a fixed decision and arrays
stayed arrays and functions stayed functions. So maybe I just can't see why
its such a big deal that arrays and functions have the same syntax - or for
that matter why they should have separate syntax.

Maybe in theory its better for Ada to have "A [X]" and "F (X)" syntax. Maybe
in theory its worse. But it sure seems like if this is in any way a wart -
its a *really* small one. I can't think of any practical circumstances in
which it would have ever made the least bit of difference to me had Ada done
it differently. Certainly, there have to be bigger issues with Ada than just
some superficial syntax like this?

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


"Brian Rogoff" <bpr@bpr.best.vwh.net> wrote in message
news:Pine.BSF.4.40.0206171944480.93931-100000@bpr.best.vwh.net...
>
> > I am an (ex-)C programmer too, and most part of the time I complain
about
> > sitting hours before large trees of code and change occourences of a[b]
> > into a(i) because a became a function instead of an array. ;-)
>
> That may be, but any Ada True Believer will chant that in Ada, we don't
> give a !@#$ for the writer of programs, we only care about the reader.
>

Re: ada paper critic

[Brian Rogoff]

On Mon, 17 Jun 2002, Marin David Condic wrote:
> As an Ada True Believer in good standing and one who has used the language
> for a long number of years, I can honestly say that I cannot recall ever
> having decided to change an array reference into a function call, or the
> other way around. Maybe its just me. Maybe it was the application domains I
> have worked in. But generally, by the time I got to coding something up, the
> architecture of the program was pretty well a fixed decision and arrays
> stayed arrays and functions stayed functions. So maybe I just can't see why
> its such a big deal that arrays and functions have the same syntax - or for
> that matter why they should have separate syntax.

My point isn't that I hate Ada because it does this (I don't) but that the
argument that all people who wish Ada had distinct syntax for these
distinct notions aren't necessarily disgruntled C fans forced to use Ada.
In fact, the reason Ada does it this way isn't because it was argued and
the design team came to a consensus that the way it is done is best.

I also mentioned that it is too late to fix this wart. Even if you made me
the Grand Mullah of the Ada standard, I wouldn't change this now.

> Maybe in theory its better for Ada to have "A [X]" and "F (X)" syntax. Maybe
> in theory its worse. But it sure seems like if this is in any way a wart -
> its a *really* small one.

I find it harder to read Ada code because of this decision. Not a lot
harder, but harder.

-- Brian

Re: ada paper critic

[Robert A Duff]

Brian Rogoff <bpr@bpr.best.vwh.net> writes:

> On Mon, 17 Jun 2002, Marin David Condic wrote:
> > Maybe in theory its better for Ada to have "A [X]" and "F (X)" syntax. Maybe
> > in theory its worse. But it sure seems like if this is in any way a wart -
> > its a *really* small one.
> 
> I find it harder to read Ada code because of this decision. Not a lot
> harder, but harder.

It makes the compiler a little bit more complicated, too.  Not only do
calls and array indexing use the same notation, but plan old variable
names use the same notation as parameterless calls.  It's interesting
that in this:

    function F(X: Integer := 10) return String;

    C: Character := F(3);

The "(...)" notation indicates array indexing, not function calling.

- Bob

Re: ada paper critic

[Hyman Rosen]

Robert A Duff wrote:
 > plan old variable names use the same
 > notation as parameterless calls.

Don't forget that enumeration literals are considered
parameterless functions. It's this syntax which allows
different enumerations to share the same literals, yet
have them be disambiguated by overloading in context.

A very elegeant bit of hackery!

Re: ada paper critic

[Robert A Duff]

Hyman Rosen <hyrosen@mail.com> writes:

> Robert A Duff wrote:
>  > plan old variable names use the same
>  > notation as parameterless calls.
> 
> Don't forget that enumeration literals are considered
> parameterless functions. It's this syntax which allows
> different enumerations to share the same literals, yet
> have them be disambiguated by overloading in context.
> 
> A very elegeant bit of hackery!

Nonsense.  (Sorry. ;-))  The reasoning, apparently, was:

    1. We only want to overload subprograms.
    
    2. But we also want to overload enumeration literals.
    
    3. Therefore enumeration literals must be subprograms.

But the idea that enumeration literals are subprograms is patently
nonsensical.  It confuses people trying to learn the language.
It complicates compilers.  It provides no practical benefit
(i.e. no gain in expressive power).  It causes complication
in the RM (if these things are subprograms, then when exactly
are their bodies elaborated?  Can calling them raise Program_Error?)

The proper line of reasoning should have been 1, then 2, then
"3. Therefore we must have been wrong about 1."  Just define
enumeration literals to be overloadable.  And if enum lits can
be overloaded, why can't (for example) constants (which are more
like enum lits than enum lits are like functions)?

Sorry, "elegeant" is not the term I would use to describe this bit of
hackery.

Numeric literals are also overloaded, in a sense, although the RM
doesn't describe it that way.  (For subtle reasons involving named
numbers (another kludge), it's described in terms of implicit
conversion.)

Notations like aggregate notation are also overloaded.
No attempt is made to call aggregates functions (although
that makes some sense, at least for record aggregates).

- Bob

Re: ada paper critic

[Robert I. Eachus]

Marin David Condic wrote:

> As an Ada True Believer in good standing and one who has used the language
> for a long number of years, I can honestly say that I cannot recall ever
> having decided to change an array reference into a function call, or the
> other way around. Maybe its just me. Maybe it was the application domains I
> have worked in. But generally, by the time I got to coding something up, the
> architecture of the program was pretty well a fixed decision and arrays
> stayed arrays and functions stayed functions. So maybe I just can't see why
> its such a big deal that arrays and functions have the same syntax - or for
> that matter why they should have separate syntax.



Now that you mention it...

I don't think I have ever run into the problem either, but not for the 
reason you suggest.  Let me come in from left field.  I am sure you have 
been burned by non-constant constants in package specifications high in 
the dependency tree.  And often when you change the package to put the 
value in the body and make the call a function you get burned, by 
declarations which took advantage of the staticness of the constant.  So 
when you replace:

     Number_of_Processors: constant 4;

with:

     function Number_of_Processors return Integer;

There are always a few units that need to be modified.  Of course there 
is no problem going the other direction, but no one ever does it.

However, when it comes to:

     function Internet_Address(P: in Processor) return IP_Address;

You always get that one right. At least I hope you do.  I certainly find 
it very unusual to have tabular data that belongs in a package 
specification as a constant array.  (I actually had one recently--a 
table of the first 1000 prime numbers. I hope those don't change on me!)

Re: ada paper critic

[Robert A Duff]

Brian Rogoff <bpr@bpr.best.vwh.net> writes:

> On Mon, 17 Jun 2002, Immanuel Scholz wrote:
> > Ted Dennison wrote:
> > > Immanuel Scholz wrote:
> > >> (Nevertheless, I think that giving the same syntax to Arrays and
> > >> functions is good, not bad.)
> > >
> > > We've actually had a lot of discussion here about that. Almost everyone
> > > who ever complains about it is an ex-C programmer who's main problem
> > > always boils down to "it doesn't look like C".
> 
> Unsupported ad-hominem argument.

I agree.  I understand the arguments both ways, and I happen to think
Ada got it wrong -- function calls should look different from array
indexing (at least in a language with side effects).  But my opinion on
this point has nothing to do with C.

(To be fair, Ted Dennison said "almost everyone", so we can't disprove
him with two counter-examples.  ;-) )

Anyway, sneering at C programmers won't win converts to superior
languages.

- Bob

Re: ada paper critic

[Ted Dennison]

"Alderson, Paul A." <Paul.Alderson@avistainc.com> wrote in message news:<mailman.1024065183.4624.comp.lang.ada@ada.eu.org>...
> If you look at just the language then I'd have to say Ada programs are less

The funny thing about this particular troll is that, if you replace
all occurances of "Ada" with "C", it is actually more accurate.

:-)

Re: ada paper critic

[Immanuel Scholz]

Ted Dennison wrote:

> "Alderson, Paul A." <Paul.Alderson@avistainc.com> wrote in message
> news:<mailman.1024065183.4624.comp.lang.ada@ada.eu.org>...
>> If you look at just the language then I'd have to say Ada programs are
>> less
> 
> The funny thing about this particular troll is that, if you replace
> all occurances of "Ada" with "C", it is actually more accurate.
> 
> :-)

"If you look at just the language then I'd have to say C programs are less
readable than C or C++ programs. "

No, it won't work. ;-)

Immanuel Scholz.

Re: ada paper critic

[Larry Kilgallen]

In article <aedn7o$6b8mk$1@ID-100557.news.dfncis.de>, Immanuel Scholz <news@kutzsche.net> writes:
> Ted Dennison wrote:
> 
>> "Alderson, Paul A." <Paul.Alderson@avistainc.com> wrote in message
>> news:<mailman.1024065183.4624.comp.lang.ada@ada.eu.org>...
>>> If you look at just the language then I'd have to say Ada programs are
>>> less
>> 
>> The funny thing about this particular troll is that, if you replace
>> all occurances of "Ada" with "C", it is actually more accurate.
>> 
>> :-)
> 
> "If you look at just the language then I'd have to say C programs are less
> readable than C or C++ programs. "
> 
> No, it won't work. ;-)

You did it wrong.  It is necessary to make changes in both directions:

  "If you look at just the language then I'd have to say C programs are less
  readable than Ada or Ada++ programs. "

 :-)

Re: ada paper critic

[Vinzent Hoefler]

"Alderson, Paul A." <Paul.Alderson@avistainc.com> wrote:

> I'm not talking about just style either,
>but the actual syntax of the language.  For example:
>
>Ada code:
>
>   MY_BIG_BLOATED_PACKAGE_NAME.MY_BIG_BLOATED_VARIABLE_NAME :=
>MY_OTHER_BIG_BLOATED_PACKAGE_NAME.MY_BIG_BLOATED_ARRAY_OR_FUNCTION(MY_BIG_BL
>OATED_GLOBAL_LIT_PACKAGE.AND_OF_COURSE_A_BIG_BLOATED_LITERAL);

Try this:

|declare
|  MBBPN_MBBVN renames
|      MY_BIG_BLOATED_PACKAGE_NAME.MY_BIG_BLOATED_VARIABLE_NAME;
|  MOBBPN_MBBAOF renames
|      MY_OTHER_BIG_BLOATED_PACKAGE_NAME.MY_BIG_BLOATED_ARRAY_OR_FUNCTION;
|  MBBGLPAOCABBL renames
|      MY_BIG_BLOATED_GLOBAL_LIT_PACKAGE.AND_OF_COURSE_A_BIG_BLOATED_LITERAL;
|begin
|  MBBPN_MBBVN := MOBBPN_MBBAOF (MBBGLP_AOCABBL);
|end;

 :-)

You never heard of renaming? In C terms you would call it a macro,
IIRC. :-)

>C code:
>
>       (for an array)
>   nDaysInMonth = nMonthTable[JAN];

|Days_In_Month := Month_Table (Jan);

What's your problem?

And why do you write n before each variable name? Shouldn't the second
read anMonthTable for an *a*rray of *n*umbers?

Oh I forgot, this is the standard way to bypass the lack of genuine
types in C by *simulating* them.

>The main point here is that the Ada code above requires one to go and lookup
>what MY_BIG_BLOATED_ARRAY_OR_FUNCTION is.

Why? It works. And it still works when you change a heavily
calculating function into a simple look-up-function called array.

>  Is it a function or an array?
>Who knows?

Who wants to know? In most cases it does not really matter.

>The other not so subtle point is that Ada programs tend to use
>very large variable names.

Ada programmers tend to use *descriptive* names.

And do you really think

|#include <my_io_package.h>
|my_io_package_global_variable = ... ;

is substantially better?

Again, the standard way to bypass the scoping problem of C where
everything is global by definition and name clashes often occur?

>  And since we want
>the package name to be descriptive everything referenced inside it uses
>allot of textual real-estate.  Therefore I personally think of Ada as a
>write only language.

LOL

>	1.) Ada is not taught anymore. (Never really ever were that many
>classes for it.)

Stuttgart (Germany) teaches it, AFAIK.

>	2.) Ada development environments lag 10 years behind MSVC for
>example.

So MSVC runs under *nix? I doubt that.

>	3.) Ada has no nice string handling capabilities.

|while (dest*=src*)
|  ;

is more nice than

|Dest := Src;

>	4.) Ada has no in-expensive development suits that are easy to use.

gnatmake My_Program.ada

What can be easier?

>	5.) The Ada language is based upon hardware notions such as integers
>being a certain size and etc.

That's bullshit, sorry.

>		(Would not it have had been better to make numeric
>declarations fit their use instead
>             of forcing the programmer to think about the computer
>hardware?)

Exactly that's what Ada does with Digits attributes for example.
Instead of caring about what floating point type to use to meet the
requirements you simply *specify* the requirements and let the
compiler choose the most appropriate representation.

>		Example:
>			If I want a number that represents the month in
>terms of a whole value
>			would not the following be a better way:
>
>			month : 1..12;

Yes. And that is what I do in Ada:

|type Month is range 1 .. 12;

What is the point you argueing about here?

>			Do I care that a byte or int is allocated?  If I do
>then I'll say so!

Yes. Exactly. Ada.

BTW, what is the size of the int you are talking about? 16, 32, 64
bits?

>			One might argue that you CAN DO RANGES, but my
>pre-emptive counter point is
>                  that one does not have to use pointers in C either!

Huh? Surely I miss something but I do not see the what range
constraints should have to do with pointers.

And

|int main (int argc, char *argv[]) {}

uses no pointers?

>Meaning why does integer exist?

For cases where you do not care about types? As base type for deriving
constrained types from?

>      6.) GENERICS GENERICS GENERICS
>		If the programmer used generics heavily and you must certify
>to level-A you either:

...simply use SPARK that does not include generics. :-)

[lint]
>additional cost and not part of the language.  But it still is available and
>essentially gets you Ada type checking

Woah! Lint gives you Ada type checking? I doubt that.

>and great analysis of your code

That what the Ada *compiler* is already supposed to do.

>(even style!).

You do not need that in Ada. It's self-styling. :-) At least if you do
not try to write C with Ada syntax.

If that really fails:

For the first time : use -gnaty.
For the second time: fire the programmer.

> So pretty much in my eyes all current languages are severely
>flawed in one aspect or another.  It all really boils down to good software
>people - not the language.

I doubt that. Good software people and a good language are always the
better choice.

Perhaps you should take a look at this:

|http://www.adaic.com/whyada/ada-vs-c/cada_art.html

Personally, I even can imagine that chances are good, that a better
language compensates for worse software people.

>  Just remember things have gone boom using Ada
>and things have gone boom using C.  So it seems that the language can't
>prevent these things!

It cannot prevent, that's right. But it *helps* you in preventing
those nasty <boom>s, so in Ada the <boom>s are more seldom.

> The overall point is that Ada is not the answer to
>everything.

Looks like the only statement that contains more than 10% of truth.
But it holds true for *every* language so it is not really an argument
on *anything*.


Vinzent.

Re: ada paper critic

[AG]

"Alderson, Paul A." <Paul.Alderson@avistainc.com> wrote in message
news:mailman.1024065183.4624.comp.lang.ada@ada.eu.org...
> Immanuel,
>
> If you look at just the language then I'd have to say Ada programs are
less
> readable than C or C++ programs.  I'm not talking about just style either,
> but the actual syntax of the language.  For example:
>
> Ada code:
>
>    MY_BIG_BLOATED_PACKAGE_NAME.MY_BIG_BLOATED_VARIABLE_NAME :=
>
MY_OTHER_BIG_BLOATED_PACKAGE_NAME.MY_BIG_BLOATED_ARRAY_OR_FUNCTION(MY_BIG_BL
> OATED_GLOBAL_LIT_PACKAGE.AND_OF_COURSE_A_BIG_BLOATED_LITERAL);
>
> C code:
>
>        (for an array)
>    nDaysInMonth = nMonthTable[JAN];
>
>        (for a function)
>    nDaysInMonth = nMonthLookup(JAN);
>
> The main point here is that the Ada code above requires one to go and
lookup
> what MY_BIG_BLOATED_ARRAY_OR_FUNCTION is.  Is it a function or an array?

And the point is - who cares? As long as it does what it's suposed to do it
could be a wigget or whatever.
Insisting on an artificial distiction is counter-productive. Suppose,
somewhere down the line, you decide
that what used to be an array now needs some more logic so needs to be
implemented as a function. So,
what do you do with all the references that assumed it's an array? Yuck...

[Besides, it's a cheap trick to use all capitals and ridiculous names in the
language you don't like and some
reasonable stuff in the language you do. How about ...

MY_BIG_BLOATED_AND_TOTALLY_UNREADABLE_NDAYSINMONTH = etc etc etc]

> Who knows?  The other not so subtle point is that Ada programs tend to use
> very large variable names.

Ever read a VB program of any size?

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