Ada versus language-X and "getting real work done" (was): 64 bit addressing and OOP

[xanthian@well.com (Kent Paul Dolan)]

[Sorry if you see this half a dozen times, groups.google.com was
having a senior moment, never confirmed the previous attempt to post
this article.]

Richard Riehle <richard@adaworks.com> wrote:
> soft-eng wrote:

>> If the DOD had its way, _everything_ would have been
>> written in Ada.

It helps to remember the context.  The DoD had, and has to
this day, a situation where battlefield computers programmed
in different languages couldn't talk to one another.  A
couple of obvious results of this kind of situation are that
people die from friendly fire problems, and that people die
from corrupted transmissions.  It was, and still is,
important that the computer software share a single
language, with that language's exact semantics for
primitives and user declared types, so that communication
succeeds and at least the people fighting on our side get to
claim they got killed by the enemy instead of friendly
forces or computer glitches.

One of the most direct ways to assure that software talent
for this common language was and remained available was to
make it the case that _all_ DoD software was written in this
same language, mandatorily.  Top Secret clearances are
expensive to produce, and keeping cleared people employed as
contractors is easier if their language skills translate
between application desmenes.

Beyond that, DoD had many languages that were in use nowhere
else, so finding programmers at all for any program on a
staffing up-curve was problematic; while having a DoD-wide
language also in widespread commercial use would have made the
programming staff-finding chore simpler.

Making the language mandatory DoD-wide made sense for other
reasons as well.  Logistics bobbles can kill people in
wartime at least as readily as howitzer aiming bobbles, it's
just usually less immediately obvious.

A side result of the need to have all kinds of applications
programmed in this common language is that the language had
to support the idioms of a wide varieties of applications:
to do scientific calculations like FORTRAN, business
calculations like COBOL, communications bit fiddling and
calculations like C, and so forth.  This _does_ tend to make
for a fairly large language, but various application areas
can pretty much stick to the subsets included for their
needs and ignore the parts they don't need, so the language
isn't so large from the viewpoint of any one programmer.

> In 1996, Assistant Secretary of Defense, Emmett Paige, an
> Ada advocate, decided that Ada had sufficient success in
> the projects where it had been used that it should stand
> on its own merits instead of being a part of a mandate. 

Which was total BS, and a whitewash besides.

BS because you don't "optionally" need battlefield
compatibility, "optionally" need programmer portability;
these are always needed, and the mandate should have been
strengthened and better enforced, not removed.

Whitewash, because what had actually happened was a
rebellion among the services, that should have had a large
number of officers cashiered if not court-martialed.  Abuse
of the exemption system had gutted the Ada mandate, and
commands, one where I worked among them, were scamming the
exemption system to get ongoing exemptions for problems they
caused themselves in the first place, in very
straightforward attempts to avoid converting software staff
to Ada software staff, and prolonged so long as they could
keep getting exemptions that let them avoid doing the hard
work needed to become unexemptable.

If the Ada mandate hadn't been dropped, the rebellion would
have to have been treated as what it was.  The DoD chose to
cave rather than apply military standards to a military
discipline problem.

> In the early days of Ada, the mid-1980's, when compilers
> were not adequate and people using the language did not
> understand how it was different from what they already
> knew, there were a fair number of failures.

> Since that time, and with the advent of the Ada 95
> standard, there have been significant successes with Ada.
> The compilers are as good as one will find with any other
> language.  The language supports an level of reliability
> not found in most other languages.   It turns out to be
> easier to understand and learn than seemed to be the case
> when it was an entirely new set of ideas.

This is way true.  As a statistic of one, I'm a much better
programmer in many other languages (C, C++, Pascal, Fortran,
Java, Perl, Modula-2, StarLogo, for examples), but I
_prefer_ programming in Ada. It is just a much better
programming language [and this isn't a casual comment; I say
this having committed software development professionally
that delivered code in a gross of programming languages and
dialects over a long career] than the others.

>> Theoretically, they are all working in Ada using very
>> strict procedures.  In actual practice, there are a lot of
>> people who are actually getting real things done!

The mythology of "people getting stuff done by ignoring the
rules" is that the bozos doing so only consider the short
term costs: what it takes to meet management's ridiculously
short milestones.  Factoring maintenance costs into the
picture, these people should be shot, but their managers
should preceed them to the firing squad for allowing what
they do to happen.  What you really have here is the
"programmer as prima donna" syndrome: rules are for other
people, "I'm a hacker!"

Indeed.

> And many of those people are getting real things done in
> Ada.

Especially in the transportation industries, worldwide.

> There is a long list of highly successful military and
> non-military software written in Ada.  Most of it is
> targeted to safety-critical software rather than the
> desktop.  We certainly can point to failures in projects
> that used Ada.   We can also point to failures in projects
> using any other language.  In my experience, the failures
> in which Ada was used had nothing to do with Ada.  In most
> cases, those failures had to do with poor management and
> poor engineering.

That, of course, can be said about software failures
independently of language issues: management is expected to
succeed given _any_ Turing complete language, but "software
management" is still mostly an oxymoron: the technically
incompetent leading the unherdable technocrats.

>> It keeps everybody happy.  The cushy-job crowd spends
>> years to do projects-that-will-go-nowhere using various
>> revisions of Ada, following very complicated specs.

It helps to remind those who think of programming as a
"cushy job" that programmer burnout rates are high,
programmer divorce rates extraordinary, programmer work
hours are obscene, programmer job security is next to
non-existent, programmers come home from long work weeks of
programming to spend hours more in unpaid self-training to
keep up with a field that abandons those who stop learning
for even six months.

> Those complicated specs are necessary because they are
> related to complicated systems.   Ada has been highly
> successful in uncomplicated systems, and also highly
> successful in some of the most complex safety-critical
> systems ever designed and deployed.    In case you did not
> know it, every time you board a commercial jetliner, there
> is a high probability you are depending on Ada at many
> levels, for your safety and dependability of arrival.

>> The get-the-job-done crowd, in the meanwhile, can get all
>> kinds of exemptions and stuff, and gets a lot of real
>> work done.  The real work can then even get some Ada
>> framework around it to keep the Ada people feeling
>> productive!

And now you have an unmanageable, unmaintainable mess that
should never have been allowed to happen: heads should roll.

> You either don't know much about the current state of Ada
> software practice, or you were on a project that was badly
> managed and are one of those who thinks the problem was
> Ada.  I recall a project at NASA Kennedy Space Center
> where I found a lot of people complaining about Ada.  It
> turned out that Ada was not the problem.   Rather, the
> management had insisted that all programming use a vi
> editor.   The engineers assumed this was inherent to Ada
> and constantly complained about Ada when the problem was
> that they hated the editor.

Which is hilarious; the vi(), nvi(), stevie(), vim(),
elvis(), and so on, family of editors were first written for
the use of _secretaries_; they are the easiest editors to
use imaginable, with wonderful ergonomic, navigation, and
search-and-replace mechanisms, and the more up-to-date
versions are far past wonderful, with text type specific
color syntax highlighting, Turing complete scripting
languages, and a wealth of special purpose features.  Like
any powerful tool, they take time and training to achieve
high skill levels and productivity though [for example, I'm
writing this article in vim(), from which I will then cut
and paste the whole article into my browser's utterly
incompetent editor widget, to avoid the pain of using that
widget), and many people, dropped into vi() unwarned, suffer
horribly.

> Another project was on a contact won by a large and
> overly-bureaucratic organization that staffed their
> leadership team with some of the most incompetent people I
> have ever seen in software development.

Given what I've seen at various employments, incompent
people doing software management is utterly the norm.

You get a combination of Peter Principle Promotions:
programmers with no leadership skills suddenly floundering
foolishly in jobs they should never have accepted; and
Lateral Ludicrousness: horizontal transfers of folks who
might be wonderful warehouse worker managers, arriving with
the idea that because you can manage something with
essentially no technical content, you have the skills to
manage something with intensly challenging technical
content, but where most of the management issues are
technical issues, and most of your decisions have to be made
having no idea what the disputing parties are saying.

> The programmers were relatively good, but they were
> saddled with this ineffe[c]tive management.  The project
> was delayed, delayed, delayed, and the complexity
> increased due to the meddling of these incompetent
> managers.  The contract was later won by another
> contractor that had better and more experienced
> leadership.   They did the job, in Ada, just fine after
> firing (should have set fire to) some of the deadwood that
> was keeping things from getting done.

Amen, except the second crowd is a fairy tale in my wide and
long experience.

> I have seen project after project completed successfully
> using Ada, often on-time and withing budget.

with budget; use budget;  burn_budget(); ???  ;-)

> Sorry your experience is different.   The issue is not the
> language, but the competence of the people using it.   I
> find Ada easy to understand, easy to use, and a great
> pleasure to engage for simple and complex programming
> tasks.  My experience is that people properly trained will
> find it as pleasant as I do.

As with vi(), as with ClearCase, if you don't _learn_ the
tool thoroughly _before_ forming your initial in-use
opinions of it, you'll hate it forever.

> When I compare it to the other languages I know, including
> Java and C++, I realize that Ada is still the best option
> for any real-time embedded software system where a high
> level of safety is required.  The concurrency features are
> far superior to those in Java, and the surprises far less
> frequent than one enjoys in C++.

True.

On the downside, as a no-longer-mandated and distinctly
fringe, almost "cult", language, Ada lacks the wide variety
of intensely useful and daily burgeoning libraries of
already invented wheels of Java, the programming hordes
willing to debug open source code of C and C++, the
just-for-fun applications and game authoring tools that make
other languages more able to attract young programmers to
become language-X junkies.

Mostly, this is due to conscious decisions, budget
shortsightedness or unconscious arrogance in the Ada
community: "our language is just so damned incredibly
superior in its serious applications, there is no need for
it to cater to the unwashed masses".

That way lies relegation to the dustbin of programming
languages history, the track down which Ada seems inexorably
headed to this day, whatever its admitted successes.

Ada was intended to replace obscure languages like Jovial.
Instead it has become one of them.  The Countess of Lovelace
should sue for damages to her good name.

> Richard Riehle

Crossposted to comp.lang.ada, which _really_ should add
comp.lang.ada.*, where * == {misc,gnat,advocacy,???}, to give
discussions like this a home.