Greetings,
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.
Best,
Sam Mize
--
Samuel Mize -- [log in to unmask] (home email) -- Team Ada
Fight Spam: see http://www.cauce.org/ \\\ Smert Spamonam
|