Another nail in Ada's coffin or an opportunity?

Another nail in Ada's coffin or an opportunity?

[Paul Whittington]

Last month I sent an email to the editor of Object Magazine regarding the
misleading nature of one of his articles on Java technology.  Well he
published my email and a response from the author of the original article. 
The author makes some good points that require some good responses.  

This is an internationally distributed publication and as such is an
oppurtunity for the Ada community to get some broad visibility.  I
encourage you to respond to the editor of Object Magazine at
jwilliams@sigs.com.

Below you will find my email to the editor followed by the author's
response.


In your December 1996 issue you published, "Why Java is a Key Technology
for the Intranet," (by Nancy Nicolaisen, p.28) that perpetuates a dangerous
common misunderstanding and shows an apparent lack of awareness.  Let's
begin with the title, "Why Java is a Key Technology for the Intranet". 
Java is not a key technology for the Intranet, or the Internet for that
matter!  The key technology here is the JVM and its associated standard
libraries, of which there is no mention in the article.  Java is just
another upstart, nonstandard, ill-defined mutating computer language that
promises to waste countless hours of software developers precious time, as
we try to keep up with its inevitable changes, and provide the marketing
machines with yet another banner to wave proclaiming a new generation of
silver bullet products.  No mention is made of the fact that it is entirely
possible to implement JVM compilers for any number of computer programming
languages.

The fact is that JVM compiler implementations for languages other than Java
has already begun, and products based on some of these compilers are
already publicly available. As a case in point, consider the "ObjectAda for
Windows:Professional Edition" product from Aoix, one of the largest
companies in the object-oriented tools market (www.aonix.com).  Along with
a state-of- the-art native WIN32 compiler for Ada95, the world's first
ISO-and ANSI-standard fully object-oriented computer language, the product
includes a JVM targeting capability.  There is also an effort underway to
produce a Free Software Foundation GNU Ada95 JVM compiler, based on the
current FSF GNU GNAT Ada95 compiler available for a wide variety of
platforms.

In the article you pose the question: " Why Bring Java Into the Enterprise
Shop?" Why indeed?  In your response you imply that Java is responsible for
the important JVM features of portability, scalability, and multithreading.
 This is of course not true!  These are characteristics of the JVM, not
Java!  Ada is more portable, more scalable, and has a far more complete,
tested and M\mature multithreading model that Java, including complete
thread-safe programming support with full guarding capabilities.  In fact,
during the thirteen-year history of Ada not only has the language matured
into a complete robust, general purpose, object-oriented programming
language, but the Ada market now provides compilers and tools that are as
good as or better than those of the C++/Java languages seem to be slowly
but surely migrating towards being a semantic replica of Ada95.  Consider
the semantic comparison chart (available at
www.adahome.com/Resources/Languages/chart3.html) seen below.

Studying this chart carefully makes me think that either Sun designed Java
by starting with Ada95, know to support good software engineering
characteristics, and modifying its syntax to be similar to C++ for
marketing reasons, and modified it to support good software engineering
characteristics.  In either case, I'm left with the question, "Why did Sun
spend, and continue to spend, [its] R&D dollars designing and developing a
language that, through the investment of millions of taxpayer dollars
including its own, had already been designed, developed, tested, matured,
and fielded over the course of a decade or so?" 


Also in the article you pose the question "How many other
application-development systems can give you these advantages (ORB
bindings, support for the workstation class platforms, and the desktop)
form a single code base?"  Well Ada 95 can do all of this, as well as
provide support for native code generation on may platforms including the
JVM, bindings to native subsystems such as X-Windows, WIN32, ODBC, etc.,
and access to several extensive source code reuse libraries, none of which
Java can do.  In addition to all of this, research has shown that initial
development and maintenance costs for Ada can be as little as half that of
C, and by induction less than that of C++ and Java.

In my seventeen years of programming I've used many languages, including
various assemblers, APL, C, C++, Java Pascal, Modula-2, FORTH, and Ada, and
I've yet to find a better language that Ada for its domain.  I'm not a fan
of big government, nor do I think that, in general, the federal government
does things very well, but in the case of Ada I've found an exception, and
it really gets my goat that we've spent millions of taxpayers dollars to
develop and excellent technology that is being thrown out with the bath
water.  It's time for U.S. companies to start making software development
decisions based on business-case analysis, and stop making them based on
the opinion of some geek developer who thinks that the latest silver bullet
written up in some industry [publication] is the right way to do things. 
To managers I say:show a little intestinal fortitude, get informed about
the real costs and payoffs of competing software development technologies,
make business decisions like you're supposed to, and tell your coddled guru
to take a hike if "if doesn't work for him man!"  To software developers I
say grow up, start acting like the engineering professionals you say you
are, keep yourself and your managers informed, and stop believing the
silver bullet garbage already!


Paul Whittington
AdaSAGE Development Team
Lockheed Martin Idaho Technologies Company
United States Department of Energy


The Author Responds:

Many thanks for your well-researched letter.  You make several excellent
points, proving once again that in the area of technology, perhaps more
than any other, there is ample room for intelligent people to respectfully
disagree.  Though Ada has many strengths, perhaps the most persuasive
argument against it is the one you make, albeit obliquely, in your last few
sentences.

Although the language has been with us more than a decade, it has sparked
little interest in the private sector.  The population of fluent Ada
programmers is small, and its aftermarket for tools and components wouldn't
even register on the yardstick used to measure similar activity for
mainstream languages such as C, C++, and Java.  

These combine to dampen optimism regarding the prospects for Ada's
emergence as a key distributed technology.  No project manager concerned
with schedules and budgets willingly chooses a language that would require
comprehensive retraining of a development team, and few projects can come
to completion on schedule without the leverage of a vital and innovative
tools-and-components aftermarket.  Look at any successful programming
language technology in use today, and you will find that it offers
enterprise development these advantages.

Though Ada was an elegant creation, the marketplace has voted against it. 
Clinging to it in the face of this reality will only narrow the prospects
of development efforts reliant on it.

Nancy Nicolaisen

Re: Another nail in Ada's coffin or an opportunity?

[tmoran]

  Hypercard.
A few years ago Hypercard on the Macintosh was as fashionable as Java
is today.  Has it taken over the world as predicted?  Journalists make
their living writing exciting articles, not producing successful
software.  Any correlation between the goals is rather random.

>mainstream languages such as C, C++, and Java.
>...
>comprehensive retraining of a development team,
  Java, and C++ if used in an OO fashion rather than as yet another C
compiler, certainly do require comprehensive retraining of a development
team, so this is an argument in favor of Basic, C, COBOL, and, yes, Ada.

>to completion on schedule without the leverage of a vital and innovative
>tools-and-components aftermarket.
  Perhaps the author is simply unaware of the 'vital and innovative
tools and components' offered for Ada.  Or does 'vital and innovative'
mean 'lots of ad space in this magazine'?  And surely the size of a
'components' market is dictated more by the application area than the
language.  It's hard to imagine, for instance, a wide open market for
'jumbo jet control' software components, regardless of language.

>Look at any successful programming
>language technology in use today, and you will find that it offers
>enterprise development these advantages.
   By "successful programming language" does the author mean COBOL?
Or Fortran or C or Ada or some flavor of Basic?  Surely she can not be
refering to C++ or Java, since there is little (no?) experience of
successful large projects written in either on which to base her
assertion.  Observation suggests that, contrary to her assertion,
large projects have been done by large companies using mostly in-house
technology rather than purchased tools and components.

Re: Another nail in Ada's coffin or an opportunity?

[Ted Dennison]

> Though Ada was an elegant creation, the marketplace has voted against it.
> Clinging to it in the face of this reality will only narrow the prospects
> of development efforts reliant on it.
> 
> Nancy Nicolaisen

I know I supposed to be indignant about this, but statements like this
just make me laugh.

While this is an incredibly lame (and incorrect) excuse not to use Ada
to develop software, it is a great reason not to write articles in
magazines about it.

So I'll just wish Ms. Nicolaisen the best of luck in her future writings
about Java (or whatever she can sell next week).


-- 
T.E.D.          
             |  Work - mailto:dennison@escmail.orl.lmco.com  |
             |  Home - mailto:dennison@iag.net               |
             |  URL  - http://www.iag.net/~dennison          |