[Wilya]

Fortan isn't dead, by far.

There is a lot of scientific and industrial code (in astronomy, aeronautics, ...) that is in Fortran. And I'm not talking about legacy stuff that is only in maintenance mode. These codes are still evolving and get new functionalities. They're not in Fortran only for legacy reasons (though that plays some part). They're in Fortran because Fortan is still the right tool for the job.

Scientific computing, where is IO is pretty much never the bottleneck, is a completely different world from web development. Python/Numpy is usable for some tasks, but only because it delegates a lot of stuff to underlying FOrtran code..

[kyllo]

Yeah, anyone who has installed numpy, matplotlib, etc has probably noticed that you need a Fortran compiler to build the native extensions...

[jofer]

Actually, you don't. A fortran compiler is optional, and used mostly for f2py and I think(?) for the LAPACK bindings. (The fortran bindings are more efficient than the C bindings for reasons I don't remember at the moment.)

Numpy's (and matplotlib's, actually) core is written in C.

Scipy is a different story, however. A lot of scipy's internals are written in fortran.

That having been said, fortran is a _very_ nice language for a significant portion of scientific programming tasks. IO in fortran is rather painful, though, i.m.o. Tools like f2py (which still doesn't really support fully modern fortran, unfortunately) make it very easy to combine fortran and python, for whatever it's worth.

[kyllo]

Yeah maybe I was thinking of scipy. I've only built numpy and scipy from source once, and it was to install scikit-learn, which has both of them as a dependency. I had to install gfortran first.

[mbq]

My favourite example is randomForest, probably the most often used implementation of Random Forest, one of the most popular machine learning method. And it is an R package calling C calling Fortran 77.