7 ms·

I find it remarkable that modern Fortran implements many advanced features while remaining backward compatible with Fortran 77, which, visually, looks like a di

I find it remarkable that modern Fortran implements many advanced features while remaining backward compatible with Fortran 77, which, visually, looks like a different language.

jabl 5y ago
Fortran 90 introduced 'free form', a more modern syntax compared to ye olde FORTRAN. Typically free form source code is denoted by a '.f90' extension whereas '.f' is for the old style fixed form.
- sampo 5y ago
  It is weird that Fortran was modernized 30 years ago, but the old prejudicies live on. Maybe programming languages teachers in CS departments are now telling their students the same jokes "look how primitive FORTRAN is" that their own teachers told them a generation earlier. So the primitive FORTRAN 77 lives on in Computer Science lore, while Fortran 90/95/03/08/13 is what people in the actual number crunching community use. Let's wait until 2050s and see, whatever Fortran 2050 will be like, if CS people will still joke about Fortran as if it was FORTRAN 77.
  - BlackFly 5y ago
    People will joke about the primitiveness of Fortran as long as they are required to preface every module and program with `implicit none`. Also, every time they pick up lapack and need to specify the "leading dimension of A" they will recall how Fortran had it's roots in a language without dynamic memory allocation and how they're still living with that legacy. Fortran's legacy leaks all over the place: you rapidly get a feel that it is something which is old and creaky, even if it is actually old and rock solid. The ergonomics are very much not modern, though, but as with all discussions of ergonomics, that is going to depend on how you like to hold your tool. Not that other languages which have widespread support also have similar historical mistake leakage. Null vs Optional in Java comes to mind. The python 2 -> 3 debacle was a similar sort of "historical mistake correction" but the breakage of backwards compatibility lead to quite some polarization. Actually, in python 2 -> 3, the python core developers tried to fix a historical defect that fortran still has: print as a keyword vs a function.
    - theodorethomas 5y ago
      <as long as they are required to preface every module and program with `implicit none`> A small price to pay for being able to run code from 60 years ago. And no, there is no such requirement as such. <need to specify the "leading dimension of A"> A very clever way of applying your algo to a submatrix from the days of sequence association and no array expressions. Nothing to do with dynamic memory allocation and you know the compiler will have no excuse to copy data. Why is it a defect that I/O needs keyword? Fortran has doubled-down on that "defect" by making coarray references through syntax [] and not an MPI-like procedure call. I don't think it's a defect at all, it's a strength.
      - BlackFly 5y ago
        I really don't understand why you're arguing with my explanation. I'm not attacking fortran, I'm explaining why it will feel old to people: because it has things in it that people moved on from. Heck, I'd even agree that it is a sort of bad attitude to automatically discount something because of such legacy. But there are clear historical artifacts in the language (like most languages today). > A very clever way of applying your algo to a submatrix from the days of sequence association and no array expressions. This isn't why you specify the leading dimension, it is just a useful feature of the leftover artifact of the lack of dynamic allocation. If the algorithms were written today, the array slicing notation would simply be used to achieve that. Back in Fortran 66 days, you would compile a large 2d array to solve the biggest problem you wanted to solve because you couldn't dynamically allocate. The alternative would be to change the source code and compile, but that was untenable. Then you would set your array elements with ordinary matrix notation but you would need to specify the stride to the solver to work with that: thus yes, it was solving a block, but it is only capable of solving the upper block. So clearly not intended for general submatrix solving: it is meant for using the upper block of a matrix in lieu of dynamically allocating the matrix to the correct size. Alternatively they could have required people to work with 1d arrays and manually handle the matrix indexing, but that would have been unfriendly.
        jabl 5y ago
  - pjmlp 5y ago
    C++ suffers from the same fate, you see some people talk here about how modern C++ fixes many of the flaws and so on, yet those same CS teachers keep teaching C+ (no typo) as if we were in 1994 or something. Or C like K&R C book was just published yesterday.
  - Zababa 5y ago
    The usual response is to ask what's the share of modern FORTRAN compared to old FORTRAN. If most of the people working with FORTRAN work with the old one and don't modernize it, then the reputation is deserved.
    - theodorethomas 5y ago
      No such thing as modern FORTRAN. It’s been “Fortran” for the last 31 years. People don’t modernize their codes because the Fortran compilers allow them to, and the Standard is reluctant to delete old features (and compilers would not delete them anyway). Unfortunately, that means that old bugs can lie undetected. I don’t think any other language/compilers have squared that circle. And there’s plenty of new projects started in Fortran.
      - Zababa 5y ago
        Replace "modern FORTRAN" with "mostly FORTRAN 90" then. The person I replied to was saying that FORTRAN's reputation as a old and antiquated language may not be deserved because there are new standard. My question was: are they actually used? If 99% of the C++ in the wild is C++98 and lower, C++11 and higher existing don't make it a "modern" language. Most people will work with the old version, and thus it would deserve a reputation as old and antiquated.
        theodorethomas 5y ago
        I am trying to read your statement without concluding that you think that ignorance is a justification for a reputation.
        Zababa 5y ago
        That's not my point. My point is that if a modern FORTRAN exists and almost no one uses it, then the reputation for FORTRAN for not being modern is justified because most people that will work with it will work with the old version.
- gus_massa 5y ago
  And there is the "intersection format" http://fortranwiki.org/fortran/show/Continuation+lines http://fortranwiki.org/fortran/show/Continuation+lines that use a careful placement and combination to make the code legal in the fixed and free format. It's useful when your coworkers have a lot of old code and refuse to modernize it, and you want to at least make the new code nice.
silverfrost 5y ago
and Fortran 77 is compatible with Fortran 66
- pklausler 5y ago
  Except where it wasn't, of course. F'66 always executes each DO loop at least one iteration, while F'77 introduced zero-trip DO loops.

I find it remarkable that modern Fortran implements many advanced features while remaining backward compatible with Fortran 77, which, visually, looks like a different language.

jabl 5y ago

Fortran 90 introduced 'free form', a more modern syntax compared to ye olde FORTRAN. Typically free form source code is denoted by a '.f90' extension whereas '.f' is for the old style fixed form.

sampo 5y ago
It is weird that Fortran was modernized 30 years ago, but the old prejudicies live on. Maybe programming languages teachers in CS departments are now telling their students the same jokes "look how primitive FORTRAN is" that their own teachers told them a generation earlier. So the primitive FORTRAN 77 lives on in Computer Science lore, while Fortran 90/95/03/08/13 is what people in the actual number crunching community use. Let's wait until 2050s and see, whatever Fortran 2050 will be like, if CS people will still joke about Fortran as if it was FORTRAN 77.
- BlackFly 5y ago
  People will joke about the primitiveness of Fortran as long as they are required to preface every module and program with `implicit none`. Also, every time they pick up lapack and need to specify the "leading dimension of A" they will recall how Fortran had it's roots in a language without dynamic memory allocation and how they're still living with that legacy. Fortran's legacy leaks all over the place: you rapidly get a feel that it is something which is old and creaky, even if it is actually old and rock solid. The ergonomics are very much not modern, though, but as with all discussions of ergonomics, that is going to depend on how you like to hold your tool. Not that other languages which have widespread support also have similar historical mistake leakage. Null vs Optional in Java comes to mind. The python 2 -> 3 debacle was a similar sort of "historical mistake correction" but the breakage of backwards compatibility lead to quite some polarization. Actually, in python 2 -> 3, the python core developers tried to fix a historical defect that fortran still has: print as a keyword vs a function.
  - theodorethomas 5y ago
    <as long as they are required to preface every module and program with `implicit none`> A small price to pay for being able to run code from 60 years ago. And no, there is no such requirement as such. <need to specify the "leading dimension of A"> A very clever way of applying your algo to a submatrix from the days of sequence association and no array expressions. Nothing to do with dynamic memory allocation and you know the compiler will have no excuse to copy data. Why is it a defect that I/O needs keyword? Fortran has doubled-down on that "defect" by making coarray references through syntax [] and not an MPI-like procedure call. I don't think it's a defect at all, it's a strength.
    - BlackFly 5y ago
      I really don't understand why you're arguing with my explanation. I'm not attacking fortran, I'm explaining why it will feel old to people: because it has things in it that people moved on from. Heck, I'd even agree that it is a sort of bad attitude to automatically discount something because of such legacy. But there are clear historical artifacts in the language (like most languages today). > A very clever way of applying your algo to a submatrix from the days of sequence association and no array expressions. This isn't why you specify the leading dimension, it is just a useful feature of the leftover artifact of the lack of dynamic allocation. If the algorithms were written today, the array slicing notation would simply be used to achieve that. Back in Fortran 66 days, you would compile a large 2d array to solve the biggest problem you wanted to solve because you couldn't dynamically allocate. The alternative would be to change the source code and compile, but that was untenable. Then you would set your array elements with ordinary matrix notation but you would need to specify the stride to the solver to work with that: thus yes, it was solving a block, but it is only capable of solving the upper block. So clearly not intended for general submatrix solving: it is meant for using the upper block of a matrix in lieu of dynamically allocating the matrix to the correct size. Alternatively they could have required people to work with 1d arrays and manually handle the matrix indexing, but that would have been unfriendly.
      - jabl 5y ago
- pjmlp 5y ago
  C++ suffers from the same fate, you see some people talk here about how modern C++ fixes many of the flaws and so on, yet those same CS teachers keep teaching C+ (no typo) as if we were in 1994 or something. Or C like K&R C book was just published yesterday.
- Zababa 5y ago
  The usual response is to ask what's the share of modern FORTRAN compared to old FORTRAN. If most of the people working with FORTRAN work with the old one and don't modernize it, then the reputation is deserved.
  - theodorethomas 5y ago
    No such thing as modern FORTRAN. It’s been “Fortran” for the last 31 years. People don’t modernize their codes because the Fortran compilers allow them to, and the Standard is reluctant to delete old features (and compilers would not delete them anyway). Unfortunately, that means that old bugs can lie undetected. I don’t think any other language/compilers have squared that circle. And there’s plenty of new projects started in Fortran.
    - Zababa 5y ago
      Replace "modern FORTRAN" with "mostly FORTRAN 90" then. The person I replied to was saying that FORTRAN's reputation as a old and antiquated language may not be deserved because there are new standard. My question was: are they actually used? If 99% of the C++ in the wild is C++98 and lower, C++11 and higher existing don't make it a "modern" language. Most people will work with the old version, and thus it would deserve a reputation as old and antiquated.
      - theodorethomas 5y ago
        I am trying to read your statement without concluding that you think that ignorance is a justification for a reputation.
        Zababa 5y ago
        That's not my point. My point is that if a modern FORTRAN exists and almost no one uses it, then the reputation for FORTRAN for not being modern is justified because most people that will work with it will work with the old version.
gus_massa 5y ago
And there is the "intersection format" http://fortranwiki.org/fortran/show/Continuation+lines http://fortranwiki.org/fortran/show/Continuation+lines that use a careful placement and combination to make the code legal in the fixed and free format. It's useful when your coworkers have a lot of old code and refuse to modernize it, and you want to at least make the new code nice.

silverfrost 5y ago

and Fortran 77 is compatible with Fortran 66

pklausler 5y ago
Except where it wasn't, of course. F'66 always executes each DO loop at least one iteration, while F'77 introduced zero-trip DO loops.