[m_mueller]

> It's not just learnability. In some cases, Fortran can be considered to be faster than C since it can apply something like -fno-strict-alisasing by default.

Yes. In my experience, you can make C as fast as Fortran, but it will be a lot more work (and you need more knowledge about the machine). Fortran's defaults are very strong when it comes to crunching numbers as quickly as possible. Multidimensional arrays with Matlab-like slicing and operations, implemented as performant as possible, is enough reason alone to stay with Fortran.

> Those scientists that are still using Fortran after all these years know what they're doing. It's not that they're ignorant of new technoglogy. A well-informed and open-minded CS person would probably end up using Fortran for these use cases, too.

Well, I'm sort of coming out of CS (computer engineering with focus on software) and I'm using it, so there ;)

[Normati]

I always wonder why you can't just add a library to another language to get most of the features of somebody else's favorite language. If not a library, couldn't any other language add matlab style matrices and end up being as good as it, fortran, etc? Do we really need a whole different language with a whole different set of arbitrary rules just so a few features are easier or faster?

[m_mueller]

For Fortran style multidimensional arrays, libraries fly right out the window. First of all, you need slicing syntax and operators baked into the language. The compiler needs to be aware of the array's storage order, such that it can implement operations like A + B optimally for A, B as n-dimensional arrays. Then it needs to be aware of their boundaries, such that it can align the memory optimally.

So that leaves language level support. So far the only contender that I can see coming up is Julia - and it will take a lot of effort until it can reach performance levels on par with Fortran. This basically would require a big push by one of the big software companies - who all aren't making a lot of money in HPC software anymore. I could see Nvidia picking up the ball at some point, it would suit them well - but then we're getting into vendor lock-in again.

[qznc]

Sure. That is what you get e.g. with NumPy in Python. However, as you already said you only get "most" of it. The remaining niche is still large enough that Fortran has lots of users.

http://www.numpy.org/

[rl9]

One of many possible reasons is the way arrays are stored. In a matrix representation, should the memory be laid out one row at a time or one column at a time? It's mostly an arbitrary decision, but different languages have made differennt choices.

http://en.wikipedia.org/wiki/Row-major_order explains it nicely.

If you wanted to take a native Fortran matrix and turn it into a native C matrix, you'd either need to copy everything to re-arrange the in-memory layout or do funky things with the indexing. Neither option is great.

---

Bringing it back to a higher level, I'd agree that your point makes sense most of the time. In most cases, the cost of a memcpy(3) would be a rounding error. That's certainly the case for most web applications. In a tight loop in a math-heavy application, though, the standards are a bit higher.

[ch_123]

One disadvantage of libraries is that the compiler treats them as regular code. If something is baked into the language, the compiler and run time (if any) can reason about particular operations and optimize them.

[dagw]

couldn't any other language add matlab style matrices and end up being as good as it, fortran, etc?

In theory, sure. In practice a bunch of languages have tried and yet Fortran is still the king.