Re: Bye-bye Ada ? (Ada95 Wholesale Changes?)

["Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca>]

Hyman Rosen wrote:
> Richard Riehle wrote:
> 
>> In Ada, used well
> 
> I suspect that you are a Japanese Joiner as well :-)
> 
> I think that any of the regular posters here would be
> able to program as well in C++ as in Ada. I'm pretty
> sure that if I had to work in Ada it wouldn't take me
> very long to get up to expert level.

Well, I can say that for small projects, your statement
is probably true.

But I can speak for my own experience, that in
largish C++ projects, I always spent an incredible amount of
time looking in core files and working with a debugger to
find out why some "strange behaviour" was happening in
those C++ projects. Sometimes it was related to those
automatic type promotions, and at other times, it was
related to memory corruption problems of one sort or
another (and it need not even be your own code! Sometimes
C++ library code does this to you).

On top of all this, once you get your large C++ application
to actually work, you then want to "port it" to another
platform, with sometimes a different compiler (or even
a different/updated gcc compiler). What do you find?

   - Changed behavior in automatic type promotion, leading
     to changed application behavior
   - #include file problems
   - C++ library incompatibilities/limitations

Sure you can say that this occurs due to poor planning,
or design. But the Ada point is that this is not checked,
nor enforced up front by your tools.  My hobby time is
time I hate wasting this way ;-)

In smallish projects, Ada sometimes takes me longer. This
is usually due to library issues and bindings.

The payoff is huge though (for me) in largish projects. In
the last 4 years (I think) of using Ada (since my conversion ;),
I've only encountered memory corruption once (I had freed
an object twice due a logic/design error).  The rest of
my time is "quality time with the compiler", learning how
to avoid certain design errors, and learning how to better
engineer modules so that the dependencies are pure and
correct (C++'s elaboration is pale by comparison). My
debugging time is 25% or less of the C++ debugging time.
(This gives me a much more pleasant use of my hobby time).

When I debug, it is because I am finding out why _I_ made
some logic error. It is not due to corruption, or some
faulty elaboration order; not due to external memory
references that the linker decided were the same (name
collision), not due to #include file sequence, not due
to automatic type promotion surprises etc.

SUMMARY:

I don't agree with your statement for large projects.


> You're probably right about the level of C++ code around.
> It's easy to bludgeon C++ code into submission when it
> won't compile, instead of understanding what is wrong.

I also believe that inexperienced programmers can produce
better code in Ada95. You won't get the same from them
in C++, even if they can wrap their head around the existing
code they must read and customize.

But then, this is just my opinion on the subject.


DON'T TRY THIS AT HOME 8-)

Ada programmers may wince at this, but here is something that
I find really useful about Ada95 for my own Open
Source development:

If I look at a spec of a package I want to "clean up", and
I don't like the way the data type is presented, and want
to make some sort of wholesale change to the package, I'll
first make the necessary tweaks or major changes to the
specs. This may include:

  - Changing constants to enumerated types / vice versa
  - Changing a weak type to a strong type
  - Making types more range specified (subtypes)
  - Changing function/procedure API changes
  - Change a record/tagged type (class) to the other kind
  etc.

Then I jump into emacs, and start invoking "make" and let
the compiler tell me about all of those new errors that will
now spew of the compiler. Using emacs I jump to the source
of the error (using emacs macros) and make all the necessary
changes, until the errors go away. With Ada95 this has
never failed me, though I expect some little case may
bite me some day, doing changes like this.

THIS HAS NEVER WORKED WELL FOR C++. C++ would never identify
all of the necessary changes, because of the number of
"automatic conversions" and so on.  C++ never tells you
that you have a missing case in a switch statement, and
its very forgiving mixing enumerated types with ints etc.
C++ will not tell you when a related constant or #define
needs to be updated.

This Ada95 feature has made it possible for me to very
quickly produce clean library interfaces, because I am
not reluctant to make wholesale changes when I
think it might be beneficial to the client.


CURIOUSITY POLL?

I'd be interested if anyone actually uses this type of
procedure in more "critical" application development roles.
I am sure that others must take advantage of this, if not
secretly so? ;-)  Is this type of thing frowned upon by
DOD projects, or do they even know this type of thing
happens? Just curious.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg