[noahl]

I believe we should think of Fortran as a domain-specific language for handling multidimensional arrays, rather than a normal programming language. It might be terrible for other things, but it's great for array computations, and that's what people use it for in big simulations. Since it has a well-defined C FFI nowadays, it's easy to connect it to other languages that can do other things (parsing data files, etc.).

Coming from a more traditional CS background, I always thought that Fortran was archaic until I actually had to learn it for some scientific computing. I found it awkward to use, but at the same time, it had array capabilities that I've never seen in any other language.

[dmlorenzetti]

In general, I agree with you. However, modern Fortran also has a strong module system, and some nice looping constructs (like explicitly-labeled loops that let you control "breaking" and "continuing" in nested loops quite easily), that made me like using it for even non-array-oriented programs (for other reasons, I don't use Fortran so much anymore).

The only thing I absolutely hated about Fortran for parsing data files is that, according to the standard, a text file has to end with what amounts to an empty line. Many Fortran environments break this rule intentionally, but occasionally you'll find one that follows the rules. It inevitably bites people who forget that their last line of data must be followed by a newline, or else the line may never get read.

[na85]

Yep, I/O in fortran is kind of a pain. I really like the rest of the language, though.

[m_mueller]

Given the right tools[1] you can have as much templating/macro support as in C++ while keeping everything both performant and user friendly. The key here is to wrap Fortran in script languages to make it do exactly what you want.

[1]https://github.com/muellermichel/Hybrid-Fortran (I'm the maintainer.)

[maaku]

> while keeping everything both performant

Good luck beating the performance of a Fortran optimizing compiler.

[m_mueller]

I don't really get your post. I never said that I want to 'beat' the performance of x86 Fortran. This particular framework is designed to make Fortran GPGPU compatible while not loosing any CPU performance. It was used to speed up the next generation Japanese weather physics by 3.5x (compared to six core Westmere) doing exactly that.

[maaku]

My apologies, I misread your post.

[gngeal]

Why? Any objective reason?

[dmlorenzetti]

One thing that for years made Fortran stand out is that the language explicitly assumes all arrays passed in to a subprogram have no overlaps.

Thus a Fortran compiler doesn't have to do anything special to make sure it preserves order when storing and accessing from two different arrays. Therefore the compiler can be much more aggressive about unrolling loops and changing the order of operations.

By contrast, given a loop like

  for( i=0; i<N; ++i ) {
    y[i] = 2*x[i];
    }

a C compiler has to assume that y[i] might be the same memory location as x[i+1], for example. Thus it has to ensure that the load into y[i] is complete before accessing x[i].

This is one reason you see a lot of C code that does numerical work hand-unrolled, with explicit stores, like this:

  for( i=0; i<N; i+=4 ) {
    xi = x[i];
    xip1 = x[i+1]; xip2 = x[i+2]; xip3 = x[i+3];
    y[i] = 2*xi; ... y[i+3] = 2*xip3;
    }

Now that C provides the "restrict" keyword, a smart C compiler can do many of the same optimization tricks that Fortran has had since day 1.

[gngeal]

One thing that for years made Fortran stand out is that the language explicitly assumes all arrays passed in to a subprogram have no overlaps.

There's a HUGE number of languages that don't allow aliasing in this way. I wasn't thinking about "how to improve C", I had APL, J, K, Q etc. in mind, as well as languages that implement mass array processing with similar semantics in terms of a more conventional syntax.

[dmlorenzetti]

Fundamentally I agree with you. In my original comment, I was just trying to give a historical view of why people took the view that "optimizing Fortran compilers are hard to beat," rather than to defend it.

Personally, I think that idea is hard to justify these days, especially when, in my experience, finding 20-30% speed differences between optimizing Fortran compilers isn't all that hard.

[coolsunglasses]

That's a compiler flag in C and has been for ages. :\

[bmuon]

I'm not sure by now the language's merits are the number one reason Fortran is used, but rather the amount of proven and super fast libraries for number crunching and array/matrix manipulation such as LAPACK.

[yyqux]

It's the only language that has quality, actively-developed compilers, excellent support for multidimensional arrays and can be very effectively optimized. The libraries are a bonus, but support for proper multidimensional arrays (i.e. not arrays of pointers to arrays) in other widely-used high-performance languages it either crippled or non-existent. It's a bit baffling that something better hasn't come along, but I think the wealth of Fortran libraries and amount of work on compiling it would make it hard for a new language to get traction.

[teamonkey]

The fancy array stuff (which honestly isn't anything particularly special these days) was added in F90. I can assure you that there's still F77 code being actively used in the scientific community.

When I was at uni (10 years ago) I worked with libraries written in FORTRAN 4. Those that used F77 were ported only because it was necessary for use with the HP-FORTRAN compiler. The only F90 code in the department was my own.

[walshemj]

why is FORTRAN "terrible for other things" given that it has a lot of useful features for technical programming that more modern languages lack.

You could always look at ratfor if you need to do a lot of character based stuff.

Back in the day I even wrote billing systems and a device driver for PDP's using fortran.

[m_mueller]

Fortran's string support is optimized for easily logging or outputting the numbers you've just crunched. For everything else it's just way too clunky, which is CS people tend to move everything not very performance critical into non-Fortran wrappers. I find Python to be particularly well suited for that task. I've also found a nice and simple module to give Fortran executables a unix style CLI[1]. Putting all this together with GPGPU acceleration makes a pretty mean combination for scientific computations.

[1] http://home.comcast.net/~urbanjost/CLONE/KRACKEN/krackenhelp...