Re: Ada The Best Language?

[codesavvy@aol.com (codesavvy)]

"Warren W. Gay VE3WWG" <ve3wwg@home.com> wrote in 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?
> 

Crafting new code.  Hopefully I won't have to chase down any more
defects that occur during elaboration :-).  Seriously I agree that the
memory corruption problems can be very nasty and very difficult to
fix.

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

I like your ideas and I agree with the points you are making.  It
seems to me that if indeed Ada 95 offers a better, more productive
programming solution to many problems that are solved using C++ then
it is a travesty that Ada 95 is not more widely used.  I think your
metric for productivity is exactly right.  What has amazed me
regarding this discussion is that so many of the participents seem to
be unconcerned about measuring productivity.  In the final analysis I
believe that in order for Ada 95 to be more widely adopted is a case
that is backed by quantitative data showing the productivity (cost
savings) of using Ada.
 
> 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.
> 

Unchecked_Conversion can "blow away the whole leg" as well :-).  I
think that skilled developers are the most important factor in
acheiving "high productivity."  I've seen some very convoluted Ada
code as well where type definitions were very poorly designed.  You're
right about the surprises that C/C++ has.



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

I basically do agree with your ideas on productivity.  I just would
like to see some quantitative data that support Ada as being more
productive as you have defined productive.  If there have been studies
done or white papers written that make quatitative arguments I would
really like to read them.  You make some very good points but
management for the most part will not listen because they won't take
the risk of using Ada instead of C++ without some hard evidence to
back up the claims regarding the increased productivity by using Ada.