[Muted]

I'm also confused about this. I don't understand what is wrong with Fortran. In school we learned Fortran 2003 for numeric simulations etc. For my master thesis I programmed in C and there were a lot of things in C that I missed from Fortran. 1) Fortran is easy to learn, no need to know pointers etc 2) very math friendly, easy to extract subarrays/submatrices etc, no need to pass around array lengths etc. matrix's are really easy to deal with. I remember in C we ended up rewriting all two dimensional arrays (matrices) to column major arrays cause it was a pain to deal with (or maybe we were noobs) 3) useful built in functions such as matrix multiplications, in C you end up writing a lot of functions to do what seem like very simple things 4) Great math libraries such as BLAS/LAPACK 5) Seems to me like it less error prone than C (spend a lot less time debugging)

This is just my experience with it. Somewhat to my surprise I really ended up liking Fortran, and the new code doesn't look at all like the old code. For what we did it was also slightly faster than C. If I were to write a numeric program I wouldn't think twice about what language to use. I feel like Fortran is an undervalued language for calculations. But then again, I am by no means an expert.

[RogerL]

It is not "cool". That's the main problem, which is no problem at all.

Now, if Bloomberg's code is a spaghetti monster (I have no idea), that is a problem. But that is a problem of legacy code, not a 'Fortran' problem.

I think it is a bad article based on hearsay by one ex-bloomberger.

[dragonwriter]

> Now, if Bloomberg's code is a spaghetti monster (I have no idea), that is a problem. But that is a problem of legacy code, not a 'Fortran' problem.

This I think is the key point: lots of time when I've seen people mistake a practices problem like this (that result in expensive-to-maintain "legacy" code) with implementation language problems, they end up doing a conversion to a new language (often doing the worst thing you can do with a poorly specified, poorly documented, but basically working codebase, a "big-bang" replacement rather than an incremental one) without fixing the process issues, and so end up creating a new poorly-specified, poorly-documented, often less-well-working "instant legacy" codebase that just happens to be in a currently-fashionable language.