TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy


Options: Use Forum View

Use Monospaced Font
Show HTML Part by Default
Show All Mail Headers

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

Print Reply
Samuel Mize <[log in to unmask]>
Reply To:
Samuel Mize <[log in to unmask]>
Mon, 9 Nov 1998 10:20:42 -0600
text/plain (90 lines)

Dr. Panos Asproulis wrote:
  We decided to produce a new version of this code written
  in a modern programming language (currently in Fortran 77)
  and we mainly consider C++ and Fortran 90 as the new
  language to use.

I have written code from an object-based design in a procedural
language like Fortran 90 (I used Ada).  I would far rather do that
than try to build a reliable and accurate math-intensive system using
a C-based language, especially if you will need to support this code
on multiple architectures.  A major problem with C++ is that it
retains most of the accuracy and debugging problems of C.

The best way to learn what problems C has is to read a few of the books
intended to help people code C more reliably, and see what hoops they
have to jump through.  You might look at these books:

   C Traps and Pitfalls, Andrew Koenig

   Writing Solid Code, Steve Maguire

At least half of "C Traps and Pitfalls" is describing problems that
Ada automatically avoids or locates for you.  I don't recall much of
the Fortran I did 15 years ago, but my impression is that most of
these "pitfalls" don't exist in Fortran 77, let alone Fortran 90.  If
you have any concern for the reliability and accuracy of your system,
I suggest you read at least Chapter 1, Lexical Pitfalls, and see how
many ways a one-character typing error can change your C program into
a different, legal C program that does something else.

"Writing Solid Code" is widely considered an authority on writing the
best C code possible.  Its subtitle is "Microsoft's Techniques for
Developing Bug-Free C Programs."  This may or may not impress you,
depending on your own experience with Microsoft products.  OK, maybe
that's ad hominem.  Let's look at the book itself.  Chapter 1
discusses how nice it would be if there were a compiler that could
catch more of your logical errors.  The author appears unaware that
Fortran and Ada both qualify.  Chapter 2 discusses the use of
assertions, many of which are provided automatically by a modern
strongly-typed language (and the code overhead of these assertions can
be automatically removed by compiling without run-time checks).

In short, if your company doesn't already have heavy experience with
C, then C or C++ is a risky direction to take unless your company is
the "600-pound gorilla" in your field, and your customers have very
few options, even if you deliver buggy, inaccurate software.

Fortran 90 I know nothing about.

Here are some advantages Ada gives you:

- The strongly defined math model should allow you to design your
  system so you can port to multiple platforms easily.  C has always
  given access directly to the hardware model, whatever that happens
  to be.  (I don't know if the ANSI C standard enforces a single
  model of math.)

- The object-oriented and procedural facilities are fully integrated,
  so you can use the right paradigm for each subsystem or module,
  rather than be forced into an all-or-nothing decision.  Most large
  systems that I personally have worked with have had parts that are
  simplified by O-O design and coding, and parts that would be
  made appallingly complicated by an O-O approach.

- Ada helps you define and enforce your subsystem and module
  boundaries.  If you build your interfaces carefully, you can find
  many integration errors with the compiler, early in coding, instead
  of hunting them out in subsystem or system test.

- The strong data typing allows you to find a lot more errors earlier
  in development, when they are cheaper to fix.  And Ada 95 has
  specific facilities to help you write portable numerics packages
  within a strongly-typed framework.

It is true that most of Ada's "big wins" have been in embedded control
systems, not numerical systems.  Ada 83 did not get a lot of use in
numerical systems -- its numeric model was good, but different from C
or Fortran, and most companies chose to stay with a numeric model they
already understood.  The numeric model in Ada 95 is more like Fortran's,
which makes this a good time to change languages to Ada.

Sam Mize

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