Rick Thorne writes:
> In truth, I like Ada too. I'm a former Ada man myself, as I believe I
> mentioned. There are great things about the language, and since we're all
> aware of them there's no point in going into them. I also prefer Beta to
> VHS.
Mathew Heaney responds:
This is actually a specious comparison. Though Beta had superior picture
quality, it had only half (or a third?) of the playing time of VHS. The
market decided that playing time was more important, and so chose VHS.
(Credit goes to Robert Dewar for pointing this out in a previous post.)
Arguments about Beta format being "better" usually omit the contribution
of playing time in the decision to chose VHS.
So I don't buy the argument that Ada has "failed" even though it is
"better."
I would say that Ada is not as popular for a few reasons, among them:
1) Tony Hoare severely criticized Ada in his Turing Award lecture,
saying (literally) that the future of mankind was at stake if we were
to use Ada, and that Ada was "doomed to succeed." Who's gonna argue
with Hoare? If he said it, it must be true, right?
In retrospect, his criticisms seem a little, well, dated. One of the
things he said would cause life on Earth to end was using exceptions!
Although exceptions can be misused, that's true of all language
features, and nowadays, everyone seems to think exceptions are a
Pretty Good Idea.
People sometimes "forget" to mention that Hoare's lecture was
directed at an early version of the language. Ada wasn't
standardized until 1983, and Hoare's speech took place in 1980. The
language was in fact made simpler between its 1980 draft and its 1983
final version.
2) The world wasn't ready for another large language. Parnas, Hoare,
Dijkstra were all critical of the language, noting especially its
size, and when guys like that talk, people listen. I suspect
(perhaps I am re-writing history) that Hoare's speech influenced the
ACM canvassers, who *rejected* the language during the ballot, citing
its size as a concern.
People (like P. J. Plaugher) sometimes lump together "large"
languages, putting Ada in the same bucket as PL/I and Algol 68. I
don't think this is a fair comparison, because Ada is a consistent
language, reflecting the vision of its architect (even if you don't
happen to like that vision). In his paper "If C++ is the answer,
what is the question?", Plaugher gave a lame criticism of Ada,
explaining that programmers could nest packages to any level they
wanted. Huh?
I've seen Ada put in the imperative group of C and Fortran,
explaining the fact that Ada doesn't use distinguished-receiver
syntax as proof of its emphasis on procedural programming. Even
Brown University professor Peter Wegner seems to ignore the fact that
Ada has abstract data types, labeling Ada merely "object-based"
because it "uses packages as the unit of decomposition." Huh?
3) Most programmers think that getting run-time errors, and then using a
debugger to find and fix those errors, is the normal way to program.
They aren't aware that many of those errors can be detected by the
compiler. And those that are aware, don't necessarily like that,
because repairing bugs is challenging, and, well, sorta fun.
You are not giving a programmer good news when you tell him that
he'll get fewer bugs, and that he'll have to do less debugging.
Basically, we still live in the dark ages of programming, not unlike
the time engineers were learning about boiler technology by figuring
out why a boiler exploded, scalding people to death (remember the
Therac-25?). People will probably have to die in order for "software
engineering" to be a true engineering profession, instead of the
buzzword that it is today. Sad but true.
4) Early compilers were way, way too expensive, and compilers were (and
still are today) very difficult to implement. As a language
designer, Jean Ichbiah didn't concentrate enough on language
implementation issues. (By contrast, Tucker is a compiler-writer's
language designer. Suffice to say, things would be very different
had Red, the version proffered by Ben Brosgol then at Intermetrics,
been chosen.)
The obvious repercussion of this is that there weren't any cheap
compilers (say, in the US$50 - US$100 range) that you could run on
your PC at home, so no one could experiment with the language. Ada
essentially missed the boat in the PC revolution, and so was never
able to develop the grass-roots support that Pascal and C had
(because those languages were relatively easy to implement, and were
therefore much more readily available).
Again, we see that there are many issues that factor into a decision
to purchase a compiler (just like as for buying tapes for your VCR).
You can tell the client about how he's going to have fewer bugs
(superior picture quality), but forget to mention that the compiler
will cost US$3000 (has less playing time).
The market chose availability and cost of compilers over quality of
language. This might not be a very smart decision, because the cost
of human labor to find and fix bugs is way, way, way more expensive
than any compiler, but since we don't use metrics in this industry,
decision-makers don't now that.
5) There is an entire industry devoted to selling tools to repair the
defects in the C language (tools for finding memory leaks, type
errors, etc). Guys like Les Hatton have a vested interest in keeping
things exactly as they are, because their livelihood depends on
people using error-prone languages. Those people just aren't going
to stand on the sidelines while you tell programmers that if they use
Ada, they can throw way all their other tools too.
6) Ada didn't have type extension and dynamic binding, and so missed the
boat on the object technology revolution. You just weren't cool
enough in the 80's, if you didn't use an object-oriented language.
Why wasn't Ada83 object oriented? It depends on who you ask.
According to Bertrand Meyer (peut-etre il a parle a Jean?), Jean
--who had been writing Simula compilers, and was thus familiar with
the paradigm-- thought that dynamic binding would have been too
radical for the conservative DoD, who after all were the ones
commissioning the language, and so he figured they wouldn't go for
it. According to others, Jean in fact didn't want type extension and
dynamic binding, because he didn't think it was necessary.
(Although, ironically, it was Jean who did push for inheritance of
operations. In retrospect, I think this turned out to be a bad
language design decision, because very, very few Ada programmers
--even longtime ones-- really understand how the inheritance model of
Ada83 works, and therefore don't use it. One "programmer" who did
understand this model was Tucker Taft, who made this the cornerstone
of the mechanism to add type extension to the language.)
You have to understand the climate of the times. Ada was largely a
reaction to languages like Fortran. They [the commissioners -- the
Dod] wanted once and for all to determine everything at compile time,
so you could eliminate errors like the parameters of an invocation of
a subprogram not agreeing with the parameters of the declaration.
Certainly not an unreasonable desire!
At that time, Smalltalk was the popular object-oriented language, and
method lookup really was slow, but only because the language was
interpreted. Sadly, many people then and even today overlook this,
and conclude that "object-oriented programming makes your program run
slow," which squelched the idea for inclusion in a deterministic,
real-time language. (Example: at SIGAda *this* year (1998) someone
got up to the microphone to ask the presenter a question, explaining
that he did real-time systems, and he wanted to know if he should be
nervous about object-oriented programming! Some rumors just die
hard.)
Of course we know now that dynamic binding is nearly as efficient as
static binding. The Smalltalk legacy lives on, however, and reuse
via inheritance came to be seen as the Measure Of All Good Things.
But there is a dark side to this, called the "fragile base class"
problem. Deep inheritance hierarchies create a lot of coupling
between abstractions, creating a tension between reuse and
information hiding. An abstraction is basically exposing its
representation by announcing that it inherits from another
abstraction, and we should all know the kind of maintenance headaches
you have when you don't practice information hiding.
Thankfully, the tide seems to be turning, and people are beginning to
realize that type extension is not so great after all, and that
"mere" aggregation is often preferable. Deep inheritance hierarchies
as a re-use mechanism may be fine for by-reference languages like
Smalltalk and Eiffel, but leaf-classes in a by-value language like
Ada95 or C++ become VERY SENSITIVE to the representation of the
ancestor classes, which means massive re-compilations are often
required any time you touch a base class. (This is the sort of
problem we had for other reasons in Ada83, which motivated the
inclusion of child packages in Ada95.)
If you are an Ada95 or C++ programmer who programs "the pure
object-oriented way" by creating deep inheritance hierarchies, then
YOU ARE MAKING A HUGE MISTAKE. You're going to spend all your time
just compiling.
Funny story: A new programmer just started using Ada, and posted a
question to this newsgroup. He had been reading in Mike Feldman's
introductory book about the abstract data types in Ada, and remarked
that ADTs reminded him of object-oriented programming. He wanted to
know what the difference was between the two.
Good question.
Guys like Pete Coad who write things like "Ada is not
object-oriented. PERIOD." miss the whole point, which is that the
important thing is language support for user-defined abstractions.
Ada83 had that, and then some. If you use a "pure" language like
Smalltalk or Eiffel, your entire world is inheritance hierarchies,
and so you think any language without deep inheritance hierarchies
must be lacking.
(Aside: I hate the term "pure object-oriented," because it makes a
lot of naive programmers think that "pure" must be "better." This is
the same reason I don't like how Wegner created a hierarchy from
"object-based" to "class-based" to "object-oriented," because
programmers are going to think "object-oriented" is better than
"object-based." These shouldn't be in a hierarchy, because they are
just alternate implementation techniques; one is better than another
only to the extent that it helps you solve a problem. Just look at
the singleton pattern. In a "pure" language, you have to jump
through hoops to create the singleton, which is an object-based
abstraction.)
What also happened during the 80's is that the term "object-oriented"
changed meaning. It used to refer a data-centric style of
programming that emphasized abstraction, and what you do to an
abstraction, in contrast to a procedural style, which emphasized
strictly what you do. Given that definition, people were happy to
call Ada an object-oriented language.
For whatever reason (probably due to Wegner), the term
object-oriented came to mean language support for type extension and
dynamic binding, and if your language didn't have that, then you
couldn't call it object-oriented. And so Smalltalk programmers like
Pete Coad could criticize the Ada for not being truly
"object-oriented."
But this is like saying you can only call them "jeans" if they have a
zipper fly. If your blue cotton pants made by Levi have only a
button fly, and not a zipper, then they're not really jeans.
I hope you see how ridiculous this nomenclature issue is.
Object-oriented is a paradigm, a way of thinking. Ada83 had direct
language support for modeling in terms of abstractions, which is the
sine qua non of object-objected programming.
I like having type extension and dynamic binding in the Ada95, but
you'd be wrong to think that this changes my style of programming
much. The most important additions to the language were better
support for real-time programming, and hierarchical name-spaces (child
packages). The tagged type stuff is just frosting on the cake.
7) The mandate.
I don't think the government was trying to "bully us" with the mandate,
they were just trying to manage the process. But by mandating that Ada
be used for all systems --even those for which it wasn't necessarily
suitable-- they diluted the value of the language in those systems where
it really is an advantage to use Ada.
If you didn't like the policy, that's fine, but don't throw the baby out
with the bath-water.
At the time, the US DoD was the number one consumer of software, and
they had huge software costs that were only growing. They had to get
their costs down (hundreds of languages were being used), and the
success rate up (many systems weren't even being delivered), and one way
they chose to do that was to commission the design of programming
language that the DoD could use as their standard language for building
real-time, embedded systems.
I think their intentions were good, but the management of that process
wasn't so good, and many programmers share the sentiment that the gov't
was trying to ram Ada down their throats.
I don't blame you or any other programmer for being offended by this
policy, but don't blame Ada the language. I myself used to scream "I
can do anything I need to in Fortran. Why do I need Ada?" But as I
started to use Ada over the next few weeks and months, I gradually began
to understand what the language was buying me.
Judge the language based on its own merits, separately from any opinion
you may have about how the DoD commissions software systems. If the
gov't does something stupid, why blame Ada?
As someone pointed out a few years ago, Ada is a large woman, but once
you get your arms around her, you learn to really love her.
> C++/Java and others have considerable strengths of their own that make
> Ada unnecessary. YES - unnecessary. C++ and Java are perfect forms
> of protest. They were developed by a handful of people (not a
> government bureaucracy like Ada was) AND they're incredible languages,
> whether or not YOU agree.
This is a common misconception. The language was commissioned (paid
for) by the DoD, but it certainly wasn't designed by a "government
bureaucracy." Ada was designed by Jean Ichbiah, then of Honeywell/Bull,
with input from a group of reviewers comprising members of industry and
academia.
But be careful not to construe this as "design by committee." As John
Goodenough pointed out in HOPL-II, Jean vetoed committed decisions that
were 12-to-1 against him.
(Another story: I met Jean Sammet at this year's SIGAda conference, and
I asked her about her experience during the Ada design process. She
told me that she disagreed with many of Ichbiah's decisions, and still
thinks he was wrong.)
So the moral of the story is, don't blame the gov't for putative errors
in the language. If you want someone to blame, then blame Jean Ichbiah.
I'm reading a great book now called Why People Believe Weird Things, by
Micheal Shermer, in which the author explains what rational thinking is,
and how skepticism is a process. Basically, people believe something
because that want to, not because of any scientific arguments you make.
There are guys out there who dislike Ada, but they do so because they
want to, not because of any rational analysis of its merits or flaws.
Sometimes even their arguments are factually incorrect, like saying that
"Ada was designed by committee," ignoring the fact that Jean vetoed
language design arguments that were 12-to-1 against him. It's not
unlike creationists who explain the "fact" that evolution violates the
2nd law of thermodynamics. (No, it does not, as any book on freshman
physics will tell you.)
I've explained the reasons Ada why I think is not as popular as C++, and
I'd like to hope that it will convince Ada's detractors that Ada isn't
so bad after all. But as Robert Dewar pointed out, a person who has
made an irrational decision probably isn't going to be swayed by
rational arguments!
Read Shermer, and you'll understand.
|
