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

[Sturla Molden]

I've been busy lately, so I haven't had time to answer.

The idea is of course to use Fortran with Python, not to build a 
framework in Fortran. I also find C useful to interface with the 
operating system, and Cython to write C extensions for Python.

Also, if the computationally demaning parts are taken care of by 
libraries (LAPACK et al.), it does not matter from which language we 
call the performance libraries.

Sturla


Den 16.03.2011 20:10, skrev Ravi:
> Comparing Fortran with C++ is like comparing Matlab with Python. Fortran is
> very good at what it does but it does not serve the same audience as C++. The
> typical comparisons work like this:
>
> 1. C++ does not have a standard array type but Fortran does. Python does not
> have a standard numerical array type either; numpy is nice, but, it is an
> external package. The point is that you pick the external array type that
> works well for you in Python/C++ but you use the built-in array type in
> Matlab/Fortran. Whether the flexibility is a problem or a god-send is entirely
> up to you. For modeling high-performance algorithms in silicon, usually in
> fixed-point, Fortran/Matlab are worthless, but C++ (and to some extent,
> python) works very well.
>
> 2. C++ (resp. python+numpy) does not perform as well as Fortran (resp.
> Matlab). The issue with C++ is that aliasing is allowed, but virtually all
> compilers will allow you to use "restrict" to get almost the same benefits as
> Fortran. The analogous python+numpy issue is that it is very hard to create a
> good JIT (unladen-swallow was, at best, a partial success) for python while
> Matlab has a very nice JIT (and an even better integration with the java
> virtual machine).
>
> 3. "Template metaprogramming makes my head hurt." (Equivalently, "python
> generators and decorators make my head hurt".) Neither template
> metaprogramming nor python generators/decorators are *required* for most
> scientific programming tasks, especially when you use libraries designed to
> shield you from such details. However, knowledge and use of those techniques
> makes one much more productive in those corner cases where they are useful.
>
> 4. "I do not need all the extra stuff that C++ (resp. python) provides
> compared to Fortran (resp. Matlab)". C++/python are industrial strength
> programming languages which serve a large audience, where each interested
> niche group can create efficient libraries unhindered by the orientation of
> the language itself. Fortran/Matlab are numerical languages with extra general
> purpose stuff tacked on. Building large scale Fortran/Matlab programs are
> possible (see the Joint Strike Fighter models in Matlab or any large-scale
> Fortran application), but the lack of a real programming language is a pain
> whose intensity increases exponentially with the size of the codebase.
>
> Another way it is usually phrased: "I will use Fortran's (resp. Matlab's)
> integration with Python (resp. Java) when I need a real programming language."
>
> 5. "OOP/generic programming are useless for most scientific programming." This
> is usually just elitism. (While I personally do not believe that OO is worth
> one percent of the hype, I do believe that generic programming, as practiced
> in Python&  C++, are pretty much our primary hope for reusable software.) When
> not elitism, it is a measure of the immaturity of computational science (some
> would say scientists), where large repositories of reusable code are few and
> far between. OO, generic programming, and functional programming are the only
> techniques of which I am aware for building large scale programs with
> manageable complexity.
>
> I would take any Fortran hype with large grains of salt.
>
> Regards,
> Ravi
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion