Re: No call for Ada (was Re: Announcing new scripting/prototyping language)

["Richard Riehle" <adaworks@earthlink.net>]

Language advocacy can be an entertaining activity on a cold winter's
evening,
but even the most ardent enthusiasts for one language or another will
eventually
admit that languages are nothing more than tools for composing computer
programs.   The good craftsperson selects the appropriate tool for the job
at hand.

During my forty-plus year career I have had to use a variety of different
programming languages.  In some cases I have had to construct fairly
large programs.  Other times, my programs were small parts of much
larger systems.

During the past four years (actually longer if I count preparation time), I
have
had to put to use, engage, and confront several newer language offerings. Of
these new offerings, I rather like some aspects of Ruby, some ideas in C#,
and have gained a new level of respect for certain functional languages.

Still, each of these new languages is a tool.   My responsibility, as a
computer
software practitioner, is to understand when to pick the right tool for the
right
job.  On a large-scale project, I must realize that several different
languages
might be required.   Also, some people will be more skilled with one
language
than another or some pre-existing code might be better suited to the
solution
than brand-new code in the latest whiz-bang language.

Under some circumstances, C++ is a perfectly appropriate choice. It is no
better than Ada for these circumstances, but it is acceptable.   In some
other
set of circumstances, Ada is a perfectly good choice.  Again, it is no
better
than C++, but works out just fine.

There are still other problems where language choice does matter.   For
programming
an small microcomputer (e.g. I-8051) C is almost always a better choice than
either Ada or C++.   For large, mainframe data processing systems, modern
COBOL
(Yes, COBOL has been modernized) is probably a better choice.    The worst
possible choice for those mainframe systems is probably C++, but lots of
irresponsible
software managers are allowing such code to disrupt their development cycle.

For windows  (MS) programming, C++ still has some edge over Ada simply
because it is
more closely associated with the MS programming libraries.  However, I have
been involved
in a least one significant project where Ada proved more portable across
more kinds of
windows environments than C++.

We select Ada when dependability is an issue.   A clear requirement of safe
software is
that of predictability.   C++ is well-known to be the source of much that is
unpredictable.
We certainly do not want to use tools with inherent unpredicatbility in the
creation of
predictable, deterministic software solutions.   In such cases, Ada is the
correct tool.
Some might suggest that Eiffel also fits that description.   The language
definition for
Eiffel probably does.  One needs to examine implementations to determine
whether
the result will involve complete predictability.

Meanwhile,  SQL remains useful.   Visual Basic is a good tool for those
applications
that lend themselves to such solutions.   Java is good for a limited range
of things, but
is used for more things than it is good for.   C++ continues to have much to
recommend it.

People do not select their programming tools as wisely as they select their
carpentry
tools.  Usually, someone learns a language and sticks with it they way some
people
stick with the same religion into which they were born, or the same
political party
into which they were born.

The religiofication of language arguments leads nowhere.   Reasonable people
must understand
that languages are designed by people, and every language is flawed in one
way or another.  We
must admit the flaws in our preferred language before the other fellow will
admit the flaws in
his/her preferred language.  As we do so, we might just come up with some
ideas for the next
improved language rather than remain paralyzed with the our current
favorite.

Richard Riehle