Re: Ada The Best Language?

["Warren W. Gay VE3WWG" <ve3wwg@home.com>]

Bertrand Augereau wrote:
> Don't take it as a troll, but the fact that some people here write C/C++
> makes me think they are not aware of all of the C++ features which make it
> (I think) able to compete with Ada95, at least for most common applications.

Troll?

The best features of C++ still leave numerous faults in the final product:

  - No overflow checks
  - In some cases, no divide by zero checks (this feature may need to be
    enabled on your platform).
  - No array bounds checking, unless you use classes to do this for you
    (a very costly approach for small arrays)
  - Casting
  - Unnecessary dynamic errors (things that could be statically check
    at compile time instead).
  - Everything is externally available (or at least, within the namespace),
    which leads to unwanted module interactions/conflicts.
  - implied conversions
  - weak enumeration types

All this is just the tip of the iceberg. For a fuller description of C++'s
problems (apart from the Ada comparison), see "Handbook of Programming
Languages", Volume 1., MacMillan Technical Publishing (I don't have the book
here, so I don't have ISBN). There's quite a description of C++'s problems
there, which don't address all of the inherited problems of C. Put the two
together, and you have one whopping list of problems.

In the final analysis, we're not really talking about a specific 
feature comparison here anyway. We're really just 
comparing how the languages and the compilers of same such compare.
How they permit the user to develop quality software, and of course within
reasonable time frames. 

Sure, there are "techniques" that can be used to _reduce_ exposure, or
enhance type safety etc. But this is generally lame by comparison to
what the Ada language enforces. Another way to say this might be to
suggest that Ada enforces the "techniques".

So if we're still talking about "productivity", it still
must be compared over the whole life cycle of the code. Not just
"delivery" of the code. There are no sufficient "productivity gains" 
in the C++ language that will bail itself out of the cost of 
debugging and troubleshooting the product later.

Regarding "common applications" :
=================================

Unless you're talking about quick 'n dirty, throw away code,
I don't think you can dispense with the need for reliable code. 
Especially if I am paying you to deliver me as much.

Look at the Windows code crashes/seizures etc.,
it's surprises, or when it does not deliver on functionality 
that it is supposed to.

Netscape/Explorer are two other big applications that
could greatly benefit from being developed in Ada95. Ada will not
make all of these problems go away, but the original point was that
CPU cycles will be expended by the Ada compiler to help the developers 
of these projects, to identify problems before they occur. BEFORE,
testing begins.

Consider which approach you would use below?

    The C/C++/Java approach :

    1. Build hang glider
    2. Flight test it
    3. If you live through the test, fix test identified bugs.
    4. Repeat 2 and 3 as required

Or..

    The Ada approach :

    1. Build hang glider
    2. Fix identified bugs
    3. Repeat 2 as required
    4. Flight test

The 2nd approach is much safer, and is over the whole life cycle
of the project, is much cheaper. If we can't agree on that,
then we won't agree on much else ;-)

Anyway, WRT the subject line "Ada the Best Language?", I don't think
that you can mandate a "best" unless you identify the application, and
the user. This is like saying "what is the best car to buy?" However, 
I do believe that Ada is a better choice for _many_ software 
applications today. I think it is starting to get more recognition
in light of this, also.

wwg.

> "Warren W. Gay VE3WWG" <ve3wwg@home.com> a �crit dans le message news:
> 3B57195E.A3A3FED@home.com...
> > codesavvy wrote:
> > > Brian Rogoff <bpr@shell5.ba.best.com> wrote in message
> news:<Pine.BSF.4.21.0107181114410.3159-100000@shell5.ba.best.com>...
> > > > On Wed, 18 Jul 2001, Jean-Pierre Rosen wrote:
> > > > > From: "codesavvy" <codesavvy@aol.com>
> > >.......snip........
> > > > Ada has built in concurrency, and since it isn't a !@#$ing flat
> language
> > > > like C++ (you may nest function definitions, and you have lexical
> scope)
> > > > its a lot easier (IMO of course) to use Ada concurrency than some
> hacked
> > > > on thread library in C++. That's a big plus over C++ IMO.
> > >
> > > I agree with you.  I really do like the Ada 95 concurrancy model.
> > > However, I doubt if the gain in productivity is substantial but I
> > > could be convinced otherwise.
> >
> > What soooo many people keep overlooking in this "productivity issue"
> > is the _TOTAL_ cost. This has been repeatedly been pointed out by others
> > here, but many C/C++ zealots seem to fail to completely grasp this issue.
> > The amount of time spent in a debugger for Ada is small. The amount of
> > "weird bug" issues is also extremely small for Ada code in general.
> >
> > I have spent a major part of my career chasing down other peoples' (and
> > in some cases my own ;-) memory corruption problems. Sure, it was very
> > efficient to slap together that C/C++ project. But when you add all that
> > time to find out where the memory corruption came from, and all those
> > future bug reports that eventually required investigation, Ada wins
> > hands down on a comparison comparison basis. Where do you want to spend
> > your time? In the debugger, or crafting new code?
> >
> > The challenge is to get everyone to recognize that you don't measure
> > productivity in terms of delivering the final product. Measure it in
> > terms of delivering the "_perfected_ product". Then consider the cost
> > of maintaining it after it is delivered/installed.
> >
> > Another way to look at this issue is that the Ada compiler uses CPU
> > cycles to spot programming errors for you. Conversely, the C/C++
> > compiler only looks for gross errors, but otherwise blesses your
> > code with the ability to "blow away the whole leg", if that is the
> > instruction you have given. And with automatic type promotion etc.,
> > C/C++ leaves a few surprises in store for good measure.
> >
> > Anyway, the whole issue keeps coming down to the point of how you
> > want to measure "productivity". You need to expand your view on that
> > IMHO.
> >
> > --
> > Warren W. Gay VE3WWG
> > http://members.home.net/ve3wwg

-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg