Re: Why is Ada considered "too specialized" for scientific use

[Vincent LAFAGE <lafage@ipno.in2p3.fr>]

Nasser M. Abbasi a �crit :
> I was browsing the net for scientific software written in Ada, and came 
> across this strange statement:
> 
> http://farside.ph.utexas.edu/teaching/329/lectures/node7.html
> 
> "Scientific programming languages
> What is the best high-level language to use for scientific programming? 
> This, unfortunately, is a highly contentious question. Over the years, 
> literally hundreds of high-level languages have been developed. However, few 
> have stood the test of time. Many languages (e.g., Algol, Pascal, Haskell) 
> can be dismissed as ephemeral computer science fads. Others (e.g., Cobol, 
> Lisp, Ada) are too specialized to adapt for scientific use.
> 
> ......
> 
> The remaining options are FORTRAN 77 and C. I have chosen to use C "
> 
> I find this strange, because I think Ada can be the best programming 
> language for numerical work.  So, I do not know why the author above thinks 
> Ada is "too specialized to adapt for scientific use".  Is there something in 
> Ada which makes it hard to use for  scientific  programming?
> 
> The main problem I see with Ada for scientific use is that it does not have 
> as nearly as many packages and functions ready to use output of the box for 
> this, other than that, the language itself I think is better than Fortran 
> and C for scientific work.
> 
> (the above quote is from a course on Computational Physics at University of 
> Texas at Austin, may be I should write to the professor and ask him why he 
> said that, but I am not sure I'll get an answer, my experience is that most 
> professors do not answer email :)
> 
> --Nasser 

just my 2 (numerical) eurocents

I have been developping some Fortran (77) code during my PhD (17 years ago).
It was a basic MonteCarlo Code for simulation of electron-positron 
collision.
1001 SLOC (physical Sources Lines Of Code, measured with sloccount)
Not big, most work went into chiseling the analytical low-level 
expressions so that the numerical approach would be used at its most.
No dedicated simplification or hardware related optimisation beyond what 
the compiler provides with -O3.
Not much software engineering: only using Fortran 77 with COMMON thought 
as objects, and a minimum modular approach.
The result was fast, but it would be arrogant boasting to describe how 
much ;-)

Time passed and then Open MP appeared. I wanted to test my old pal 
reference code on my brand new two-core CPU, without much effort, I thought.
To ease the move to parallel code, and to learn more about the now 
unavoidable Fortran 90 (which simply copied the easiest part of Ada 83),
I first translated my code to F90 (not simply compiling the same code 
with an F90 compiler).
I turned the COMMON into modules (a.k.a. package) and a type within this 
package, and according to the famous equation :
     module + type = class
it resulted in an object oriented code ;-) .
1150 SLOC
Time-wise, I was paying only a 20% abstraction penalty with the same 
compiler. Not bad.

The objectification process was made in C++ at the same time. A quite 
painful translation indeed, but C++ was my way to earn money at that time...
1259 SLOC.
Not only the translation was painful, but the compilation gave me result 
flawed with memory faults that I had to debug. In the end, I finally had 
the same accuracy as Fortran 77, but...
The result looks like a good start for a flame war: C++ was 7.5 times 
slower than Fortran 77. With the same compiler (g++ versus g77/gfortran).
I do not think it is so significant in fact, as my algorithm relies 
heavily on complex number, which are well integrated in Fortran, but 
pays the full abstraction penalty in C++... The good way to do it in C++ 
would be to use libraries such as Boost or Blitz.
We can do it, but then do we really want to go through the hassle of 
extra layers?

My program wasn't still parallelized, and Ada became the next candidate 
for the test.
1120 SLOC.
The translation was swift, and when the compiler finaly let me go, the 
code ran (no debug needed) and was delivering the same accuracy as 
Fortran 77, and only a factor 2 of speed loss (compared to 7.5 for 
C++...). With gnat (to stay in the same compiler family).
Given that complex number are not hard-embedded in Ada, they should pay 
the abstraction price, but they keep the price low.

Later, I could capitalize on the tasks and protected objects to 
parallelize my program in Ada, which is as yet still not done in 
Fortran... But this is another story.

I plan to do it in Java as well, but I expect almost the same thing as 
for C++: it will not be testing the strong point of the language, but 
really peeking at its weakest point: complex numbers.

So, as far as performance is concerned, Fortran was, IN THIS CASE, the 
winner. Ada, was a strong contender.
I will not elaborate too much on the easiness of translation: when you 
have worked for many month with such a short program, and converted it 
to 2 other languages, the 3rd translation can not be so hard.

I believe that if I had to translate (or even write) other more 
significant codes, I would use the ability of Ada to interface with 
other languages: I would keep my low level routines in fast Fortran, and 
have the general flow of the computation driven by Ada, to make the 
whole picture clearer and more efficient.
In between, I try to code more in Fortran 90, which is a close nephew of 
Ada 83.

* I did the same kind of multi-language port for my education, with a 
quasi-random number generator, starting from a C++ version,
and I have not yet found a way as elegant, and memory-wise efficient, to 
store an upper triangular matrix as in C++.
* I also miss some syntaxic sugar of Fortran that allows to refer to 
line I of a matrix M as a vector with M(I, *)
=> If someone would like to discuss it, I will be glad to exchange on these.

Best regards,
Vincent

PS : for language crusade, I believe that the problem of Fortran is 
"Fortran users", who are mostly not computer scientist. I hear the Ada 
fans boast "Ada doesn't make assumptions about the programmer: he can be 
uneducated, but the compiler will save him", but I strongly doubt the 
actual population of Ada coders be AS uneducated (or 
software-engineering-unconscious) as the actual population of Fortran 
coders (averaged over the last 50 years).