Re: Was: Re: Ada95 in Germany

["Marin D. Condic" <mcondic-nospam@quadruscorp.com>]

Roger Racine wrote:
> The language has been at least a part of numerous problem programs (if
> not failures, then cost overruns) that I know about, in many
> languages.  For Ada, the problems have come about when the team tries
> to over-design the system.  Ada has many wonderful features, such as
> tasking, tagged types, etc.  However, if over-used (how about 10
> levels of inheritance, tasks used essentially as procedures, . . .;
> not the real problems to protect the innocent) on what was thought at
> the time to be a fast processor (68010, 80386 DX), these features can
> be time hogs.
> 
Been there. Done that. Got the T-Shirt. I'm currently working on some
code that was apparently written by a bunch of C++ programmers who got
sent to an Ada class and then went hog-wild with some of the new
features they learned. (This is just a guess, but the code looks kind of
C-ish and there I'm seeing the same things you describe: Tasks used as
procedures or just overapplied, too many levels of inheritance, too many
data types, etc.)

While there is evidence that the programmers at least got sent to a
class and hence had *some* understanding of what they were doing, there
seems to be a lack of experience in designing large systems in Ada at
work here. The software is not a "failure" but it could have been
improved considerably if the design had been guided by one or more
experienced Ada programmers. (Pretty tough to get that experience
without building something like this which you just accept as "less than
perfect")

BTW, I'd expect exactly this sort of quality if you took a bunch of Ada
programmers who knew nothing of C++ and dumped them into that
environment. Each language has its peculiarities and ways of doing
things. We'd probably fight the language going in that direction just as
they do coming in our direction.

> Of course the real problem was with the people, not the language.  But
> we Ada lovers tend to say that Ada helps prevent problems.
> Unfortunately there are people who love abstraction, and abstraction
> can be a problem if used badly.
> 
It ultimately always has to come down to people. Misuse of a tool is not
the tool's fault. I'd think that management of a program being done in
Ada by a formerly C++ staff would need to consider the tools and see to
it that some knowledge and experience is built up on the project before
entering into design. 

Yes, Ada prevents problems, but in my mind the problems it prevents are
the superficial design flaws. No language can stop a project from making
fundamental design flaws. If a project fails for superficial design
flaws (excessive crashes for numeric errors, memory references, etc.)
then you might blame the language. If it fails because of fundamental
design flaws (excessive complexity leading to size/time problems,
overshot schedules trying to integrate incompatible subsystems, etc.)
then its not the language but the engineering management that is to
blame.

MDC
-- 
=============================================================
Marin David Condic   - Quadrus Corporation -   1.800.555.3393
1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233
http://www.quadruscorp.com/
m c o n d i c @ q u a d r u s c o r p . c o m

Visit my web site at:  http://www.mcondic.com/

"Capitalism without failure is like religion without sin." 
        --  Allan Meltzer, Economist 
=============================================================