Comments on: Why is most science programming done in fortran?

By: Stefano Borini

Stefano Borini — Sat, 07 Aug 2010 16:49:57 +0000

@MSB:

> There are two methods in Fortran to solve this problem:
> “use ModuleName, only: ItemName” will select only “ItemName”
> from the module “ModuleName”, so if that module has items that
> you don’t need that clash with another module, they are omitted
> and don’t clash. If two modules have items that you need that
> have the same name, you can rename the item: “use ModuleName,
> OrigName => NewName”. Clash gone!

yes, but you will have to specify it by hand for each routine you need to import. This can become very tedious as you have to cherry pick what you need, and write even more boilerplate code. Compare to how python solves the problem:

import foo
import bar

foo.hello()
bar.hello()

In Fortran you would have to “USE foo” and “USE bar”, plus rename the hello routines with “USE foo, hello => foo_hello” and “USE bar, hello => bar_hello”. This introduces two problems, the first is given above: you need to do it for any routine you need and clash, which can be a lot if you are, for example, using two IO modules with a standard interface for conversion among different formats.

The second problem is that if you are particularly unlucky, and instead of hello you have Conn_getRemoteServerInfo (25 chars) and the module Network (7 chars), to stay consistent in style you will have to do USE Network, Conn_getRemoteServerInfo => Network_Conn_getRemoteServerInfo which is 33 chars and therefore in excess of the standard.

The identifier issue I raise however is a minor point and unfortunate case, though. It is not representative, you can work around it, but during actual programming we did hit it. The root cause was forcing a namespacing-like workaround to keep things organized and programming OO-style without doing OO at all (don’t ask, I fought against it but sometimes a compromise is needed), in a language that does not support nested namespaces.

By: MSB

MSB — Fri, 29 Jan 2010 03:51:58 +0000

An ISO Technical Report defined a standard addition for variable length strings. An open source implementation exists since 2003. You “use” iso_varying_string. Deferred length allocatable scaler strings (Fortran 2003) provide dynamic length strings. Some compilers supporter this already, e.g., Intel ifort since mid-2009.

Re: “When you use USE, you import every symbol in your scope, meaning that if you have two different modules, but with the same symbol name inside, they will clash. Unless thereâ??s a trick I donâ??t know about, this means you cannot import them at the same time.”

There are two methods in Fortran to solve this problem:
“use ModuleName, only: ItemName” will select only “ItemName” from the module “ModuleName”, so if that module has items that you don’t need that clash with another module, they are omitted and don’t clash. If two modules have items that you need that have the same name, you can rename the item: “use ModuleName, OrigName => NewName”. Clash gone!

“short identifier limit”? 31 characters in Fortran 95, 63 in Fortran 2003. Longer than this, the lines of the program will get rather long…

By: Stefano Borini

Stefano Borini — Sat, 05 Dec 2009 05:28:32 +0000

> 1) a lot of code to perform a task ??
> let me give a counter example
> Java (cold be C or C++):
>
> float[10][10] a;
> for (int i=0; i a[i][j] = 0;
>
> Fortran:
>
> real::a(10,10)
> a = 0

The example you present specifically addresses one strength of fortran (90): handling arrays. For any other task, it will take more code. I cannot show you real examples here, but you are welcome to download the Q5Cost library for real cases of bloat code to perform trivial tasks such as exception handling.
By the way, if the example you gave was C, I would not zero an array the way you did, I would simply use bzero().

> 2) modular programming is easy with fortran 95, Object
> programming is with fortran 2003.

Not really. Modular programming is “easy” once you know how it works, but the way is implemented makes it a pain to handle. Namespacing is limited to basically one level, and you cannot rename your module import. When you use USE, you import every symbol in your scope, meaning that if you have two different modules, but with the same symbol name inside, they will clash. Unless there’s a trick I don’t know about, this means you cannot import them at the same time. This breaks havoc if you want to use two different modules with the same interface but with different implementation (for example, if you want to read data from a file format and store it into another file format).

> 3) if fortran has IMPLICIT, it also have IMPLICIT NONE and
> each compiler has flags to prevent implicit statement.

Yes, but they are not turned on by default. This is one case where backward compatibility should have been dropped for the sake of forcing a bit of proper coding style. We would have much better code around now.

> 4) Dynmic memory allocation, aggregation: not missing any more
> since fortran 90

Except for strings.

> 5) dynamic strings: foreseen in fortran 2003, not yet
> implemented by compilers. The only cons so far.

well, last time I checked we are in 2009

> Nevertheless, charaster(100) and Character(101) are more like
> an double and a float than an int and a string, as thay can be
> compared and assinged to each other…

In other words, they are like two different datatypes, with forced implicit coercion.

> 6) GUI programming, Networking, DB access, real time,
> inter-process communication and much more… Yes, I’ve done that
> in Fortran 15 years ago when I was programming Satellite
> control center, with high requirements on reliability.

Interesting. Using what public available libraries ? I guess they were internally produced in your case. This unfortunately limits its access to the rest of the world, making adoption of fortran for these tasks basically nil.

> Conclusion: The language is secondary and you cannot say
> “Don’t use that or that language”. There are Pros and cons
> for all of them, and it always depends on the programmer…

Exactly what I said, and I totally agree with you. I would not use python for a low level device driver and I would not use Fortran to access a MySQL database.

By: Magermans

Magermans — Wed, 02 Dec 2009 14:44:08 +0000

Perhaps the comment is late, but it is , I think, relevant.
First of all, I’m a fan of Java. I also work on some simulation software written in Fortran.

1) a lot of code to perform a task ??
let me give a counter example
Java (cold be C or C++):

float[10][10] a;
for (int i=0; i

Fortran:

real::a(10,10)
a = 0

2) modular programming is easy with fortran 95, Object programming is with fortran 2003.

3) if fortran has IMPLICIT, it also have IMPLICIT NONE and each compiler has flags to prevent implicit statement.

4) Dynmic memory allocation, aggregation: not missing any more since fortran 90

5) dynamic strings: foreseen in fortran 2003, not yet implemented by compilers. The only cons so far. Nevertheless, charaster(100) and Character(101) are more like an double and a float than an int and a string, as thay can be compared and assinged to each other…

6) GUI programming, Networking, DB access, real time, inter-process communication and much more… Yes, I've done that in Fortran 15 years ago when I was programming Satellite control center, with high requirements on reliability. A lot safer than doing them in C or C++.

Conclusion: The language is secondary and you cannot say "Don't use that or that language". There are Pros and cons for all of them, and it always depends on the programmer…

Pol Magermans
Software Engineer
University of Liège, Belgium.