Re: Ada The Best Language?

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

codesavvy wrote:
> "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........
> > 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.

Ain't they fun? I have been spending this week and last at work, trying to
find the source of some memory corruption. So far, I have managed to find 3 
new "other" memory problems, that I wasn't looking for.. scarey!

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

The www.adaic.org site is a starting place. See:

    http://www.adaic.org/intro/c.html

I am sure that others in this ng can give additional references, and in
some cases testimonials ;-)

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

I think you will find that Ada programmers do their level best to avoid
anything that has "Unchecked" in it. In some cases, their coding mandate
(flight critical systems) will demand it. In others, it may just be a 
matter of pride ;-)

However, another benefit of Ada that I like, is that due to a lack of a
macro preprocessor, I can do a grep of Ada source code looking for 
"unchecked" and not miss any instances of it due to macro hiding -- a
major pain in C/C++ sometimes. Once you have this information, you can
scrutinize those sections again, to see if they are related to problems
you might have.

$ grep -i unchecked *.ad[sb]

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

Try http://www.adaic.org/intro/c.html and maybe others in this ng will
point you to other studies.

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