Mark Lundquist wrote:
> Another one that I've noticed is the truism that Ada is supposed to be
> good for programming in the large, or the humongous, or whatever. I've
> heard this in several different forms, along the lines of "C++ is good
> for projects up to a million lines of code or so, but beyond that you
> need Ada."
> This theme is repeated by Ada apologists and vendors in the same voice
> or with the same motivations as the "reliability" theme, and with the
> same effects. It's also repeated by those who wish to sound
> even-handed, or as a concession -- a charitable way of saying "that
> language must have some reason to exist -- maybe it's 'programming in
> the large'...").
> In any case, it makes it sound as though there is some penalty for
> using Ada that dominates in small or medium-sized projects, and that
> the benefits do not emerge until you reach the level of "way huge
Exactly. The perception is all bass ackwards.
The flavor of both of these statements ("Ada should
be used mainly for very large projects", and "Ada is
mainly good for safety critical projects") is
that Ada is something you only should use if you
absolutely have to, if you've got no other choice,
or when you're backed into a corner because of
the size of your project or its safety requirements.
Continuing to sell Ada along these lines will be its
downfall for two reasons: 1) projects that fit in
either of these two categories are not any kind of
mainstream, not even the mainstream of the real-time
systems niche; and 2) programmers are persuaded that
Ada a necessary evil rather than an enjoyable and
That's why I say that these kinds of appeals are
useful only for attracting systems engineers and
project managers to Ada, not programmers. Managers
think of *all* programming languages (and
programmers!) as necessary evils to begin with.
Only programmers get excited about programming
languages. Who's leading the Java "revolution"?
Managers? If you think so, you're wrong.
Managers (as managers; yes, there are plenty of
software project managers who are programmers at
heart) don't give a damn about programming
languages. Neither do executives or marketing
people or accountants. No one in the organization
cares about programming languages at all except
What actually has to happen in real life is that
programmers and their managers and the project's
systems engineers have to come to an *agreement*
to use Ada. So, it's OK to continue to try
to convince managers and systems engineers to
choose Ada, but if the programmers in that shop
do not want Ada, it won't happen; or at least it
won't last. Ask Ed Seidewitz.
But as long as we are talking about things that
persuade the managers, we might try a different
tack there as well. There are really only two
concrete things in a manager's mind (and no,
I'm not implying they all have rocks in their
heads!): schedule and budget. To persuade project
managers, you need to demonstrate that these two
things are going to be powerfully affected by the
choice of programming language, and that they will
get dramatic results by choosing Ada. How you
do this is up to you; but let me suggest a very
insightful piece of literature that may help:
"How to Lie with Statistics" by Darrel Huff.
But really, all the information is out there and
has been available for some time to make a good
management case for Ada (cf. the Zeigler paper and
the other presentations at AdaIC); it has simply lain
fallow without being incorporated into a wide-
spread marketing campaign. Practically the only
people who have read or seen that material are DoD
software people, squirreled away from the world in
black monolithic buildings engraved with the words
"Ministry of Peace" (ok, so I get carried away; sue
me); the rest of the world doesn't have a clue. You
can't just "build it and they will come", you've
got to get the message out in a focused, intelligent
way to the right people.
I tell my managers at work every now and then
"I'd hate to see what this project would be like
if we had used C or C++; we'd be so far behind
it would kill us." Or, "Most of the integration
problems we've been having on this project are
the places where we have stepped outside the
bounds of the language. Where the Ada compiler
has been able to check things for us, we've had
very little difficulty".
(Since one of my managers reads this list, I'd
better say in a hurry that I'm never lying or
even exaggerating when I make these statements.
Hi Larry! ;)
mailto:[log in to unmask]