fortran95 or c for a new stellar evolution program?

Ernest N. Mamikonyan ernie314 at drexel.edu
Mon Nov 21 17:16:50 GMT 2005


Sorry, Bill, I hit Reply, not ReplyAll.

I would like to join Piet in the flexibility-modularity-clarity 
argument. And to this end I want to emphasize programming paradigm, not 
programming language. To me, it's obvious that the most appropriate 
paradigm for modern, large, and efficient scientific codes with complex 
data structures is *object-oriented*. It's probably not my place to 
explain to you the benefits of object-orientation.

We can argue endlessly about our favorite OO language but few people 
will pick Fortran90 for this. I don't know Fortran90 but I find 
FORTRAN77 utterly repulsive. And a few months ago, you told me that 
there is no way to store pointers to functions in Fortran90; there is no 
*real* object-orientation without function pointers - this is a fact. I 
discount Fortran on the basis of being *the crappiest and ugliest 
language on earth*; I'd rather code in assembly.

Your other choice was C. In C you can build robust object-oriented 
systems but the syntax is rather unnatural. Of course, you're twisting a 
procedural language into object-orientation. The things you're not going 
to to be able to do anything about are:
* insufficient and obsolete error-handling mechanism
* can achieve some abstraction but not as complete as with C++
* no real (enforced) data encapsulation unless you go through real hoops
* most likely to be less efficient than the equivalent C++
   implementation
* again, unwieldy syntax and obfuscation
can't think of any more right now

For me, there is only one choice for this type of code - C++. I know you 
specifically excluded this from your language choices but I beg to 
differ with your statement:
"... and c++ doesn't add critical new functionality for this kind of 
application."
What about:
* real data abstraction and encapsulation
* polymorphism
* inheritance
* exceptions for error-handling - infinitely better than function return
   values for complicated codes with many different parts communicating
Do you not think that these features will be useful, or even critical, 
for a code with complex data structures? Or *will* you have complex data 
structures? If not, then C might be more viable. I find exceptions 
extremely useful in a multifaceted code, though. And C++ is showing the 
signs of being heavily relied upon in the future and is still evolving. 
As far as efficiency, I disagree with some of the things that have been 
said about this. C is much more difficult for compilers to optimize than 
Fortran because there is possible pointer aliasing. But pointers are 
necessary unless you want to program in a straitjacket...I mean Fortran. 
All signs are now pointing toward C++ for efficiency, even over 
FORTRAN77. With things like expression templates, a lot of computation 
can be forced at compile-time. Even simpler things like using a size as 
a template parameter can create fixed-size arrays with all the operators 
optimized at compile-time. Admittedly, some of the more advanced 
features, especially those related to template metaprogramming, have yet 
to make their way into most compilers, at least in efficient 
implementations.

Now back to what Piet was saying about modularity and all that good 
stuff. C++ just happens to be my favorite language with these features, 
but you might want to pick something that you prefer (we all know you 
have strong opinions but I'm not the one to talk here either). I know 
Piet, for example, likes Ruby; many people prefer Python. Again, as Piet 
says, with that approach, the computationally intensive pieces will have 
to be written in a compiled language but the overall structure of the 
code will be able to benefit from the object-orientation.

- -- 
Ernest N. Mamikonyan    Email: ernest at physics.drexel.edu
Department of Physics,    Phone: (215) 895-1544
Drexel University    Fax: (215) 895-5934
Philadelphia, PA 19104    Web: www.physics.drexel.edu/~ernest



More information about the stellar-discuss mailing list