4 ms·

For what it is worth - I write Fortran professionally (in some of the use cases you describe) and I doubt its usefulness. The way I see it, Fortran exists toda

For what it is worth - I write Fortran professionally (in some of the use cases you describe) and I doubt its usefulness. The way I see it, Fortran exists today because of inertia, not because it still has technical superiority. These mountains of Fortran code represent decades of investment and undocumented "features" that you could never code around during a rewrite. And so today, new code is bolted on, with a prayer that nothing breaks, may god have mercy on your soul.

mkoubaa 5y ago
The key advantage of fortran is that it doesn't allow pointer aliasing, which allows the compiler to vectorize more. Couple that with the typical fortran use cases and compiler vendors competing on performance by vectorizing more and more. What you end up with is a language with a reputation for being faster for computation
- necheffa 5y ago
  When C99 introduced the restrict keyword this argument fell apart. But I can assure you, the vast majority of legacy Fortran is not vectorizable. At least not without a bit of refactoring. Oh and did I mention, most of this legacy code was hand optimized for memory utilization. You see, back in the day 8k of memory was cutting edge HPC and about half that went to the OS and compiler. Well we all know, everything is a balancing act between time and space - the old timers traded time for space just to be able to do the computation at all on the hardware they had.
  - dralley 5y ago
    > When C99 introduced the restrict keyword this argument fell apart. 1) Nobody puts "restrict" everywhere, and in C it can be very dangerous to do so unless you're exceedingly careful. 2) The fact that few codebases use it means it's riddled with compiler bugs even if you are exceedingly careful. Just look at how many times Rust has had to disable noalias due to LLVM bugs and regressions.
    - necheffa 5y ago
      Restrict is used where it matters. Just because Fortran does the equivalent of implicitly using restrict everywhere does not mean the compiler actually statically checks for abuse. You can just as easily write bad pointer aliasing code in Fortran and depending on what optimization level you built with you may or may not experience memory corruption and/or segmentation fault at run time.
      - zozbot234 5y ago
        AIUI, the only language in common use that has comprehensive static checks for their equivalent to 'restrict' is Rust. Not coincidentally, there's quite a bit of interest in Rust adoption for numerics-heavy and scientific codes, the traditional preserve of FORTRAN.
  - pjmlp 5y ago
    No it didn't, it only introduced yet another source of UB, when C "experts" forget to use it the way ISO C rightfully expects.
    - necheffa 5y ago
      You seem to be operating under the assumption that the Fortran compiler will catch pointer aliasing. In fact major implementations of Fortran do not (for technical reasons). So the standard just says "don't do it, LOL" but then you are able to write Fortran violating this. Which is how you end up with bugs that go away when you switch optimization levels.
      - pjmlp 5y ago
        You seem to be operating under the assumption that the C developers know how to use restrict, when in practice they don't, so it hasn't made the argument fell apart. In fact, only C++ is able to confortably beat Fortran, despite not having official support for restrict, because of the stronger type system and compile type metaprogramming that offer optimization opportunities out of reach to C compilers. Usually HPC places like CERN and Fermilab don't migrate their aginging Fortran code to C, rather C++.
noobermin 5y ago
Man, why is inertia considered a bad thing? "new code is bolted on, with a prayer that nothing breaks" is literally all of software development. How many times do things break because some fool decided we need to use js framework 2022.04.07 when 2022.03.05 worked fine but new, shiny etc thus break. "Old" does not mean broken automatically, people seriously need to excise this assumption in software development because it simply isn't true.
- wallfacer120 5y ago
  I strongly suspect there is an preference-oscillation in coding languages that is similar to the one found in broader culture between serif and sans-serif fonts. Can't fix on what it would be though?
- bayindirh 5y ago
  HPC administrator, researcher and scientific software developer here. Inertia is not a bad thing, but a long living code evolves in strange ways, because of us, humans. First of all, programming languages and software design has a symbiotic relationship. They feed each other. Support for required patterns and new technology is added to languages, and designs are made in confines of language capabilities. Moreover, technology changes with every generation. Hardware change, capabilities change, requirements change, designs and languages change. More importantly mindset change. So you're bolting modern designs over "vintage" designs. Inevitable shims get coded (sometimes implicitly), and thing get complicated, even with best documented designs and developers with well intentions. The code pushed down solidifies, knowledge fades, and documentation get lost unless it's bundled with the code repository. As a result, legacy code becomes something of a monster, where developers don't want to see, touch, or work with. My research was coded with C++11 in the beginning. If I want to modernize with C++14 or add new parts with C++14, these parts will probably look so different that it'll look like two different languages glued together with black magic. It's the same thing with long living FORTRAN code. Only with longer legacy. The culture and dynamics around scientific and academic programming is different from both FOSS and commercial software. This needs to be taken into account.
  - 5y ago
NGRhodes 5y ago
One of the people in my team has a PHD in weather forecast modelling and it was only a few hours ago we were talking about the Met Office having a decade(s ?) old Fotran core with lots of stuff bolted on.
- hilbert42 5y ago
  Was the conclusion that decades old Fortran existing good or bad, likewise the bolt-ons? Ideally, if given a chance, what's the consensus of what you'd all like to do?
StreamBright 5y ago
When we cannot re-make the things we made before is a sign of a slow decline.
- necheffa 5y ago
  More likely, a rewrite doesn't look good on a quarterly spreadsheet and "shockingly" code designed by Johnny Two-Shoes in the 60s that uses COOMON blocks both for internal storage as well as an API is incredibly difficult to test and thus incrementally modify. Bonus points for next to no documentation. College software engineering textbooks that explain why global memory is generally a terrible design choice were written off the lessons learned from legacy Fortran.
- colechristensen 5y ago
  It's really not. It is simply very expensive to build up experimental validation of simulation code rewritten in a new language, and much more expensive than the aesthetic value given by programmers who want new things. There's nothing magic about the old things, there's just an existing ecosystem which works which would involve a whole lot of effort to recreate and most people think they have better things to do.
  - hilbert42 5y ago
    QED. (What you're saying makes sense, I don't understand why anyone would disagree after considering the facts.)

mkoubaa 5y ago

The key advantage of fortran is that it doesn't allow pointer aliasing, which allows the compiler to vectorize more. Couple that with the typical fortran use cases and compiler vendors competing on performance by vectorizing more and more. What you end up with is a language with a reputation for being faster for computation

necheffa 5y ago
When C99 introduced the restrict keyword this argument fell apart. But I can assure you, the vast majority of legacy Fortran is not vectorizable. At least not without a bit of refactoring. Oh and did I mention, most of this legacy code was hand optimized for memory utilization. You see, back in the day 8k of memory was cutting edge HPC and about half that went to the OS and compiler. Well we all know, everything is a balancing act between time and space - the old timers traded time for space just to be able to do the computation at all on the hardware they had.
- dralley 5y ago
  > When C99 introduced the restrict keyword this argument fell apart. 1) Nobody puts "restrict" everywhere, and in C it can be very dangerous to do so unless you're exceedingly careful. 2) The fact that few codebases use it means it's riddled with compiler bugs even if you are exceedingly careful. Just look at how many times Rust has had to disable noalias due to LLVM bugs and regressions.
  - necheffa 5y ago
    Restrict is used where it matters. Just because Fortran does the equivalent of implicitly using restrict everywhere does not mean the compiler actually statically checks for abuse. You can just as easily write bad pointer aliasing code in Fortran and depending on what optimization level you built with you may or may not experience memory corruption and/or segmentation fault at run time.
    - zozbot234 5y ago
      AIUI, the only language in common use that has comprehensive static checks for their equivalent to 'restrict' is Rust. Not coincidentally, there's quite a bit of interest in Rust adoption for numerics-heavy and scientific codes, the traditional preserve of FORTRAN.
- pjmlp 5y ago
  No it didn't, it only introduced yet another source of UB, when C "experts" forget to use it the way ISO C rightfully expects.
  - necheffa 5y ago
    You seem to be operating under the assumption that the Fortran compiler will catch pointer aliasing. In fact major implementations of Fortran do not (for technical reasons). So the standard just says "don't do it, LOL" but then you are able to write Fortran violating this. Which is how you end up with bugs that go away when you switch optimization levels.
    - pjmlp 5y ago
      You seem to be operating under the assumption that the C developers know how to use restrict, when in practice they don't, so it hasn't made the argument fell apart. In fact, only C++ is able to confortably beat Fortran, despite not having official support for restrict, because of the stronger type system and compile type metaprogramming that offer optimization opportunities out of reach to C compilers. Usually HPC places like CERN and Fermilab don't migrate their aginging Fortran code to C, rather C++.

noobermin 5y ago

Man, why is inertia considered a bad thing? "new code is bolted on, with a prayer that nothing breaks" is literally all of software development. How many times do things break because some fool decided we need to use js framework 2022.04.07 when 2022.03.05 worked fine but new, shiny etc thus break. "Old" does not mean broken automatically, people seriously need to excise this assumption in software development because it simply isn't true.

wallfacer120 5y ago
I strongly suspect there is an preference-oscillation in coding languages that is similar to the one found in broader culture between serif and sans-serif fonts. Can't fix on what it would be though?
bayindirh 5y ago
HPC administrator, researcher and scientific software developer here. Inertia is not a bad thing, but a long living code evolves in strange ways, because of us, humans. First of all, programming languages and software design has a symbiotic relationship. They feed each other. Support for required patterns and new technology is added to languages, and designs are made in confines of language capabilities. Moreover, technology changes with every generation. Hardware change, capabilities change, requirements change, designs and languages change. More importantly mindset change. So you're bolting modern designs over "vintage" designs. Inevitable shims get coded (sometimes implicitly), and thing get complicated, even with best documented designs and developers with well intentions. The code pushed down solidifies, knowledge fades, and documentation get lost unless it's bundled with the code repository. As a result, legacy code becomes something of a monster, where developers don't want to see, touch, or work with. My research was coded with C++11 in the beginning. If I want to modernize with C++14 or add new parts with C++14, these parts will probably look so different that it'll look like two different languages glued together with black magic. It's the same thing with long living FORTRAN code. Only with longer legacy. The culture and dynamics around scientific and academic programming is different from both FOSS and commercial software. This needs to be taken into account.
- 5y ago

NGRhodes 5y ago

One of the people in my team has a PHD in weather forecast modelling and it was only a few hours ago we were talking about the Met Office having a decade(s ?) old Fotran core with lots of stuff bolted on.

hilbert42 5y ago
Was the conclusion that decades old Fortran existing good or bad, likewise the bolt-ons? Ideally, if given a chance, what's the consensus of what you'd all like to do?

StreamBright 5y ago

When we cannot re-make the things we made before is a sign of a slow decline.

necheffa 5y ago
More likely, a rewrite doesn't look good on a quarterly spreadsheet and "shockingly" code designed by Johnny Two-Shoes in the 60s that uses COOMON blocks both for internal storage as well as an API is incredibly difficult to test and thus incrementally modify. Bonus points for next to no documentation. College software engineering textbooks that explain why global memory is generally a terrible design choice were written off the lessons learned from legacy Fortran.
colechristensen 5y ago
It's really not. It is simply very expensive to build up experimental validation of simulation code rewritten in a new language, and much more expensive than the aesthetic value given by programmers who want new things. There's nothing magic about the old things, there's just an existing ecosystem which works which would involve a whole lot of effort to recreate and most people think they have better things to do.
- hilbert42 5y ago
  QED. (What you're saying makes sense, I don't understand why anyone would disagree after considering the facts.)