TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy


Options: Use Forum View

Use Proportional Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
"Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
Thu, 8 Oct 1998 14:14:15 -0500
Samuel Mize <[log in to unmask]>
Samuel Mize <[log in to unmask]>
<[log in to unmask]> from "Neil Evans" at Oct 8, 98 04:24:23 pm
text/plain; charset=US-ASCII
text/plain (115 lines)
Neil Evans wrote:
> I cant really find much in the way to say bad
> about it, I'm sure there's a lot of you out there which would say thetas
> because it doesn't have any bad points,

No, I'm not a Scientologist.  (They believe in Thetans.)

I doubt that anyone here would say Ada has no drawbacks compared to
some other language, for some specific applications.

For instance, if you want to explore self-adapting programs for AI
research, you want to use something like LISP which is designed to
allow a program to modify itself, not something like Ada which takes
steps to prevent it.

Ada was designed for embedded applications.

- They must be reliable.  It's worse than inconvenient to reboot your
  airplane during a dogfight.

- Their code will be kept and maintained for a long time.  Upgrades
  to embedded systems must be thoroughly tested and reliable, so they
  tend to be rather conservative and use as much proven, unchanged
  code as possible.

- The customer wants to set rigid up-front requirements (a definition
  of what the software would do) before coding starts.  They're
  paying millions for you to develop their system, they want to feel
  certain it will do what they need.

A lot of commercial software development has exactly the opposite view.

- Reliability is much less important than new and flashy features.

- A given module is often discarded, not upgraded, since it will be
  significantly changed to add new features, or to accomodate new
  features in other modules.

- The customer gets new features as they are released.  Customers may
  request specific features -- and they will certainly chase neat
  features that appear on the market -- but they can't demand things
  up-front and withhold payment.

It may sound like I'm knocking commercial development, but I don't mean
to be.  These are the characteristics that the market demands.
Unreliable, feature-laden software outsells reliable, simple software.

Anyway, since the goals of commercial development are at right angles
to the goals that drove the development of Ada, it's hardly surprising
that many commercial developers don't care for it.

Specific issues that get raised are:

- takes too long to learn

  This is trivially true if you want to start coding on your next
  project tomorrow, and you don't currently know Ada.  Learning
  Ada (or X-windows or Windows or whatever) is an investment.

  And, there is more to learn than just syntax.  You have to learn
  to use Ada properly.  If you code Ada with inappropriate methods,
  you can get the worst of both worlds.  It will take forever to
  get a poorly designed system to compile, and it will be full of

- ease/speed of coding

  Ease and speed of coding are where Ada's strong typing and run-time
  checking get knocked for making the programmer's job too hard.  And,
  if you don't mind the occasional core dump, bad result or Blue Screen
  o' Death, it's true.

  If you add coding and testing time, most people find that the total
  time spent is similar whether you use Ada or another language.

  Ada makes you do more work up-front in coding.  If you really get into
  the Ada mindset, you will do a LOT more work coding than if you bang
  something out in C, C++ or Java.  Your code will be more reliable,
  it will be easier to maintain, and it will skip through testing a
  lot faster.  Trouble is, commercial developers don't care too much
  about reliability and maintainability, and they don't believe
  testing will go faster -- "software is sofware," they figure.

  Until you personally experience this, it's hard to believe how
  much difference in testing time careful engineering can make.

  Also, "coding complete" is a milestone that managers often want to
  hit as early as possible, in case testing takes longer than planned.
  And since they demand fast, thought-free coding, testing always DOES
  take longer, so they feel justified.

  This is approaching ad hominem -- I'm not saying ALL, or even most,
  commercial developers takes this approach.  I'm trying to describe
  a trend I've seen some places.

- too slow, executables too big

  This used to be a reasonable objection in some environments.  It
  is a problem in fewer environments as compilers mature.

Also, the most recent big trend was object-oriented programming.  Ada
has only recently integrated facilities for this.  As a result we
missed the "PR wave" for being an OO language.

There are other points to the discussion, but this may help you.  Look
around on the net, look in the advocacy items at --
their arguments suggest what objections have been raised.

Sam Mize

Samuel Mize -- [log in to unmask] (home email) -- Team Ada
Fight Spam: see \\\ Smert Spamonam