[Numpy-discussion] Fortran was dead ... [was Re: rewriting NumPy code in C or C++ or similar]

[Sturla Molden]

Den 14.03.2011 23:10, skrev Matthieu Brucher:
> - Fortran 95 has an excellent array support, which is not currently 
> available in C/C++ (perhaps with ArBB?)

In C++ you can actually make array libraries that behave almost like a 
Fortran compiler (cf. Blitz++, Intel Array Building Blocks), but they 
must be maintained to keep pace with Fortran compilers.


>
> Class and templates are also better supported in C++.

Fortran has generic programming, but not like C++ templates. C++ 
templates were actually the model of what not to do in Java and .NET 
generics.

Classes: Fortran 2003 has classes. Fortran 95 only have modules, user 
defined types and operator overloading.

Most of my scientific programs don't require fancy OOP. Even with 
Python, origanizing functions in modules covers 90% of what I need to 
do. Matlab programmers also have the habit of just collecting functions 
in .m-files. So I think the "subroutine in a module" abstraction of 
Fortran is sufficient. If I need OOP, I have Python or Cython :-)

Python's i/o is easier to use, if one is used to think of I/O as a data 
stream and familiar with C standard i/o. Fortran's i/o is vectorized 
(cf. arrays) and record based (cf. data bases). This allows parallel 
data import or export. This is because the argument is implicitely 
parallel (an n-dimensional array), and record based i/o means the order 
or read and write does not matter. That is unlike streams, where 
data[n+1] always follows data [n]. It is easy to jump to the conclusion 
that Fortran's i/o is inferior to C, but there is a reason i/o look that 
different. With C one could e.g. use the OS to memory map a file, and 
OpenMP to read the file in parallel (if hardware allows this). In 
Fortran, all such details are implicit in the i/o statements (e.g. open, 
read, write, close), the syntax is standardized, and the implementation 
details for each platform is deferred to the compiler. If we care more 
about scientific programming than systems programming (incidentally the 
typical difference between users of Fortran and C), it might not be that 
interesting to control these low-level implementation datails about i/o.


Sturla