Hacker News Reader

Comment by 6gvONxR4sf7o | Hacker News Reader

Fortran actually isn't a static language. It's evolved over time. The last significant revision according to wikipedia is just over a year old. The beauty and horror of it probably depends which era of it you're looking at.

View on HN

In the late 90s I remember a saying roughly "I don't know what language scientists will be using in 20 years, but it will probably be named Fortran"

As someone professionally involved with computational physics / geophysics, I can vouch that Fortran is still heavily used in these domains.

EDIT: for a modern, relatively new and highly-used scientific codebase that uses Fortran90 exclusively, see PFLOTRAN: https://bitbucket.org/pflotran/pflotran/src/master/

That is witty on so many levels I'm simply in awe

The quote is from Tony Hoare, winner of the 1980 Turing Award, in 1982.

https://arstechnica.com/science/2014/05/scientific-computing...

I also like the saying "you can write FORTRAN in any language".

After Fortran got its array syntax 29 years ago, there aren't many languages that you can use to write array-manipulating code like in Fortran. Maybe just Julia and NumPy?

What are the highlights of Fortran's array manipulation capabilities?

Well, things like... you have 2, 2 dimensional arrays of the same size, A and B.

You want to make a new array, where each cell in A is added to the same cell in B. So you are going to do a loop over 2 variables, right?

in FORTRAN the code is...

C = A + B

in Julia the code is C = A .+ B

Interesting. Does it result in a compile error if you try arrays of different sizes? (If it's just a run time error, I don't see how it's different to implementing this with operator overloading in any language that supports it).

Sure, if you try with non conformable arrays, gfortran for example would tell you something like this:

  Different shape for array assignment at (1) on dimension 1

Note that a scalar is conformable to any array, so that A = 2 for example would work for any shape of A, and would fill A with 2's.

That's what I do in C++ with Eigen or boost::ublas or any other library. Operator overloading is not a feature limited to Fortran.

Fortran gets its performance from prohibition of aliasing, which is something that C++ admits as per the standard. One could enable the same performance boosts with a non standard compiler flag, but this breaks a lot of codebases, including the Linux kernel AFAIK.

Aliasing is a pox upon the world. There's a lot of work gone into stuff like UBSan for C++. I think aliasing should be added to stuff that it checks for. Dunno how much overhead that would be though.

Taking rows and columns is still nice in Eigen. For example taking the second column of a matrix is m.col(1) (Eigen, 0-based indexing) and m(:,2) (Fortran, 1-based indexing unless specified something else).

But more generic array slicing with strides seems to get nasty in Eigen. For example if

    v2 = v(1:2:20)

    Map<RowVectorXf,0,InnerStride<2> > v2(v.data(), v.size()/2);

in Eigen, I don't want to read the docs for how to do the same for 2- or 3-dimensional arrays.

https://eigen.tuxfamily.org/dox/group__TutorialReshapeSlicin...

In Julia, it is C = A + B too. (You don't need the elementwise operator ('.') if the operation is a well defined expression in linear algebra.)

All array languages (apl and its derivatives).

Raku (perl6).

R, Matlab/Octave, Mathematica

IIRC, most people who use Fortran use it because there are extremely specialized physics libraries (or astronomy, or chemistry, and so on) that were probably written three to four decades ago by an extremely intelligent PhD student who lacks a proper programming background.

Which suggests that the biggest source of horror would be that most code you'll come across was written by a non-programmer who is intelligent enough to translate an extremely complicated and niche problem domain into very clever and completely un-idiomatic code, who likely was unable to read their own library mere months after graduating because most PhDs don't fully understand their own thesis within months after graduating.

For sure, there are a few cases like the one you mention (I personally work with this kind of code in a daily basis), but that's not the reason most people use Fortran. There are many libraries with a level of robustness and performance that you won't find anywhere else, there are highly optimized compilers, and it is the standard language in many fields.

It's also quite safe for non-programmers. Those non-programmers write complex algorithms, but the code itself is not "clever and completely un-idiomatic". Most often, it is quite naive, just a series of formulas one after the other. You will find very long subroutines, bad names, some obvious inefficiencies, and maybe some spaghetti, but nothing to be afraid of.

My understanding from supercomputing center folks is that, if you just want to run these half a dozen equations for a bajillion nodes in parallel as fast as possible, it is still the best language for the job. Not speaking from personal experience, though.

"Idiomatic" depends on language and domain and era and purpose. Consider the dgemm method in BLAS (double general matrix multiply, powers all sorts of modern code like numpy). It's such a workhorse, used by everything under the sun. But it does one thing. It multiplies two matrices of doubles. You're going to want to optimize the hell out of it and ensure it's correct, then never revisit it. It's been around (in the exact same form as far as I can tell) nearly as long as I've been alive. The right, idiomatic code for that is going to look different from the right, idiomatic code for something at the business logic level that changes every 6 months. It does it a disservice to shit on it like you are.

You're going to want to optimize the hell out of it and ensure it's correct, then never revisit it.

Balderdash. Claptrap. Codswallop. Poppycock. What if you want to revisit it to make it run on parallel processors? Optimize it for a new CUDA architecture or caching scheme? A new instruction set that handles sparse matrices better? Code lives forever, at every level.

For this kind of linear algebra, you're going to have a different routine for a sparse matrix (dcoomm) or a symmetric one (dsymm) or a triangular one (dtrmm) or symmetric banded matrix vector product (dsbmv) or whatever. Hopefully those are separate functions from your dense one (dgemm), which is what I'm talking about. You'll also have a different function for CUDA (which exists in cuBLAS) than for multi-core (in ScaLAPACK? PLASMA?) than for single-CPU (in BLAS), which is what I'm talking about. General matrix multiply in this sense isn't "all the different matrix multiplies." It's a function with a very specific purpose, and yeah you don't really need to revisit it every decade.

Either way, it's not that much horror: http://www.netlib.org/lapack/lapack-3.1.1/html/dgemm.f.html

I like it when some of my colleagues use Fortran, because their code in other languages is even more horrible.

BTW, the 'non-programmer' you seem to not think much of probably used an RPN calculator. Food for thought.

> the 'non-programmer' you seem to not think much of

If what I wrote lead to that as your main take-away, then I apologize for expressing myself badly, because nothing could be further from the truth! I studied physics myself at one point, and base this on conversations with friends who (unlike me) didn't drop out. Specifically, those who were asked by their professor to update old libraries during their PhD thesis.

Could be worse... Matlab?

Coming from a C++/Java background, I loved the fact that in 2 hours I was able to learn enough Fortran 77 to take ownership of a very large app.

I think one of the reasons its still frequently used in some parts of academia is a Grad student can figure it out in a few day of self-study and move on to doing their actual research from there. As opposed to if you want them to work with a large C++ program, getting them familiar enough with the language to be useful can take half a semester.

I’m a professional FORTRAN developer. I would say even FORTRAN 90 has a very rich and capable feature set. The problem is not the language, it’s the other developers :). A lot of codes have been developed by people used to FORTRAN 77, so even if they’re using new features the codes are poorly designed.

Reply on news.ycombinator.com