6 ms·

1. There are thousands of scientific subroutines written in Fortran that are stable and well tested - in fact, there are well established formal libraries of th

1. There are thousands of scientific subroutines written in Fortran that are stable and well tested - in fact, there are well established formal libraries of them that go back over 60 years. The researchers know and trust them. 2. Despite the sneers and derision that Fortran has been subjected to from non-Fortran programmers over recent decades, Fortran is an excellent language to do intensive scientific and mathematics work. Compilers are optimized for calculation/math speed and large intensive calculations. From the outset, it could handle complex numbers, double precision, etc., etc. natively without having to resort to calling libraries/special routines as other languages had to do back then. 3. Scientific enterprise alongside mainframes and supercomputers have well established and stable ways of working including program and data exchange etc. Essentially, a well established computing ecosystem/infrastructure surrounds scientific computing that researchers know and understand well. There is no need to change it as it works well. Moreover, it's a stable and reliable environment when compared to other computing environments - Fortran was introduced long before the cowboys entered the computing field, back then the programming/computing environment was more formal and structured, this contributed to that stability. For the record, Fortran was the first language I learned, and my programming back then was done on an IBM-360 using KP-26 and KP-29 keypunches and 80-column Hollerith cards.

TazeTSchnitzel 6y ago
It took until C99 for C to have complex numbers and `restrict`. Those are two features FORTRAN has had for a much longer time, right?
- hilbert42 6y ago
  You're testing my memory now. If I recall correctly, at least complex numbers were in the WATFOR (University of Waterloo) FORTRAN-IV compiler that I used in 1968 on the System/360. (That said, I've always understood it was there from at least FORTRAN II.) I seem to recall needing 'i' for vector stuff, Maxwell's equations etc. (If I'm wrong it must have been on the VAX FORTRAN-IV several years later. Correct me if I'm wrong.
- pjmlp 6y ago
  And like in everything C, unlike Fortran, there is no way for the compiler to validate if restrict is being used properly. Use it wrong, break the compiler assumptions and the bug hunting fun starts.
  - TazeTSchnitzel 6y ago
    How does Fortran enforce this, actually? Does it just not let you pass the same array to a function via multiple parameters?
    - bodhiandpysics1 6y ago
      Fortran didn't originally have pointers, and pointer based code is relatively rare in fortran, so making requirements about pointer aliasing doesn't have same potential to completely break your code that it does in c. The reason c can't actually restrict the restrict keywoard, is that the standard would break code!
      - gnufx 6y ago
        The storage association rules have nothing to do with pointers like that. Code will typically break because arguments are passed with copy-in/copy-out semantics, not by reference.
    - gnufx 6y ago
      It does, indeed, but that's not the only way to associate storage. Using INTENT to specify whether an array is updated is useful.
  - gnufx 6y ago
    Mostly the compiler won't catch violation of the storage association rules. Toolpack had a useful tool for strict F77 code which was a boon fixing stuff not to break with the Alliant compiler, which was the first one the project I inherited used that took advantage of the optimization opportunity. Possibly Cray's would have done, but hadn't been used for a while at that point. The fact that people won't believe the rules exist, is a continual source of bug hunting in Fortran unfortunately. At least restrict is visible.
- tobmlt 6y ago
  I __think__ Fortran just never gave you this particular footgun. No aliasing of pointers allowed from the getgo. It was never an issue. Somebody let me know if that is wrong. I read Complex numbers came in FORTRAN IV, so mid 60’s. I never used anything older than FORTRAN 77, and it certainly had complex numbers, and also ways for the “inventive” programmer to make use of pointer like functionality. You could e.g. pass functions to functions, if you were so inclined.
  - hilbert42 6y ago
    "I read Complex numbers came in FORTRAN IV, so mid 60’s." FYI, this link [PDF] https://personalpages.manchester.ac.uk/staff/paul.johnson-2/resources/fortranShort/link-wiki.pdf https://personalpages.manchester.ac.uk/staff/paul.johnson-2/... contains the peculiar statement "Over the next few years, FORTRAN II would also add support for the DOUBLE PRECISION and COMPLEX data types." At face value, that statement implies complex numbers came later but before FORTRAN III, which also implies a point release (FORTRAN II was released in 1958). Moreover, I read somewhere that FORTRAN III had it but it wasn't widely released. Likely then that FORTRAN IV was the first widely released version with complex numbers. As it was released in 1961, we should assume then that this was the likely date.
    - tobmlt 6y ago
      Pretty cool, thanks for the details! This is about what I’d expect from ancient FORTRAN. (I read fortran IV off Wikipedia, maybe there was fine print)
      - hilbert42 6y ago
        You'll note from one of my other posts that FORTRAN-IV was my intro into programming. However, that was toward the end of the decade not the beginning. By then, many universities were running the WATFOR FORTRAN-IV compiler from U. Waterloo. At the time it was anything but ancient. We students felt both cocky and privileged in that we knew that we were some of the very few people in the country who had access to a state-of-the-art IBM mainframe. BTW, the mainframe, a System/360, had just 44kB memory and ran 7 concurrent operations at once. It was a red-letter day when the '360 got upgraded to 77kB memory. The university's rag had the fact as large headlines on its front page.
readflaggedcomm 6y ago
Tested in the sense of test suites and formal proofs? That would be valuable to other disciplines using other tools. But this article isn't about fundamental algorithms being correctly-implemented in an endowment of legacy code, it's about defending a siloed language choice, which seems like an antiquated concern to me. I applaud anyone using a tool that works for them, but if it's good, then its users have accomplished things which transcend an individual tool.
- hilbert42 6y ago
  "But this article isn't about fundamental algorithms being correctly-implemented in an endowment of legacy code, it's about defending a siloed language choice, which seems like an antiquated concern to me." 1. The first comment I would make is that the headline premise is wrong or at least deliberately misleading. Let's start with a correction. I would very much doubt that climate models are written in programming languages from 1950s. The Fortran code of the 1950s was not that much like the Fortran code that I learned in the late 1960s, and that late 1960s code bears little resemblance with modern Fortran code of today. Furthermore, the Fortran standard is certainly not dead, it is being continually updated: http://fortranwiki.org/fortran/show/Standards http://fortranwiki.org/fortran/show/Standards. 2. When I made comment about libraries going back 60 or so years, this would imply that libraries written in Fortran II ca 1956 or so would pose a problem today. I would suggest that it is not so because the process of updating libraries is formal and strict, thus an updated Fortran II subroutine would work perfectly well with today's modern Fortran. This 'upgrade' process is not like converting code from say Pascal to C or whatever, for here we are still within the confines of the Fortran framework and that that conversion process is well understood, straightforward and procedural. 3. This isn’t my idea, nor am I defending something that I learned decades ago and don't want to give up. Frankly, I do little Fortran programming these days so it's essentially irrelevant to me. The point I made and that I make again is that there is a sophisticated scientific computing environment in existence and it is used by thousands of current researchers and scientists around the world. Scientists would not use antiquated software on cutting edge science if it did not work. The fact is modern Fortran is a modern programming language that delivers the goods par excellence—likely much better than any other language, especially so given its long and mature infrastructure. For example, here are the first two reference I came across on the net, there are thousands more just like this: https://arxiv.org/abs/hep-ph/0612134 https://arxiv.org/abs/hep-ph/0612134 https://www.sciencedirect.com/science/article/abs/pii/S0010465518302200 https://www.sciencedirect.com/science/article/abs/pii/S00104... 4. Now let's look at the current situation—'modern' software. To begin, you should read this 27-year old Scientific American article titled 'Software's Chronic Crisis' from September 1994: https://www.researchgate.net/publication/247573088_Software's_Chronic_Crisis https://www.researchgate.net/publication/247573088_Software'... I would contend that this article is just as relevant today as it was 27 years ago if not more so. In summary it says. • Programmers work more like undisciplined artists than processional engineers (this problem remains unresolved). • Essentially programming is not true engineering (since the time of the article, computer science has progressed somewhat but on the ground we still have multitude of unresolved problems). • If programming is to be likened to engineering then it is in a highly unevolved state somewhat akin to the chemical industry ca 1800. Its practical function or operation is a mismatch with the everyday world or we wouldn't have the proliferation of problems that we currently have. When, these days, one examines the situation with literally hundreds of different computer languages in existence, it is clear that there isn't enough human time and effort to rationalise them all and develop a coherent set of tools, in essence almost everything around us is only half done. We stand in the midst of an unholy Tower of Babel and it's an unmitigated mess (I could spend hours telling you what's wrong but you'll know that already). The crux of the problem is that programmers spend much time and resources learning one or more computer languages and that it's dead easy to poke fun at mature languages such as Fortran as being old fashioned and out of date. The fact is they either do not adequately understand them or the reasons why they are used, or it is both. The fact is it is this very maturity of Fortran that makes it so valuable to scientist and engineers. Those who are not conversant with or do not program in Fortran have simply not understood the reasons for its success. Scientists and engineers have found the most reliable, stable and best fit available and that is to use a modern version of Fortran—simply because its reliable and it works. This article only shows authors lack of understanding of the problem. Oh, BTW, let me add that I have no contention with theoretical computer science models. It's just the divide between theoretical computer science and what happens in practice is as wide as it ever was.
LargoLasskhyfv 6y ago
Ahem ;-) Somehow your mention of cowboys entering the field feels irritating, considering Kazushige Goto and his contributions to BLAS while being in Austin, TX. Banzai!
- gnufx 6y ago
  While Goto typically gets the plaudits (and obviously did good work there), you should credit van de Geijn in that area long term.
  - LargoLasskhyfv 6y ago
    Oops. Haven't even been aware of that. Anyways, irritation over 'cowboys entering into the field' still stands, because it happened in Austin, TX. Yeehaw! ;-)
ianai 6y ago
That makes it pretty clear that Fortran is set up to be the perfect foe to "latest has to be greatest" programmers.
saboot 6y ago
Researcher in Nuclear Engineering chiming in with a similar experience. Much of our code is the same way, and in fact our field more or less invented many computing methods used today. One widely used simulation code called MCNP [1] can trace it's origins back to running on the ENIAC at Los Alamos in the 40s(!). At some point, it was considered a major upgrade when it was rewritten into fortran90. [1] https://en.wikipedia.org/wiki/Monte_Carlo_N-Particle_Transport_Code https://en.wikipedia.org/wiki/Monte_Carlo_N-Particle_Transpo...
tzs 6y ago
> From the outset, it could handle complex numbers, double precision, etc., etc. natively without having to resort to calling libraries/special routines as other languages had to do back then. At least until sometime in the '80s another advantage of Fortran over C was that it could handle single precision floating point. C always promoted float to double when you did arithmetic with it. Arithmetic was faster on floats than doubles, and that could make quite a difference in a big simulation that was going to take a long time to run. The high energy physics group at Caltech back then had a locally modified version of the C compiler that would use single precision when the code tries to do arithmetic on floats. Some of the physicists used that for programs that otherwise would have been in Fortran.

TazeTSchnitzel 6y ago

It took until C99 for C to have complex numbers and `restrict`. Those are two features FORTRAN has had for a much longer time, right?

hilbert42 6y ago
You're testing my memory now. If I recall correctly, at least complex numbers were in the WATFOR (University of Waterloo) FORTRAN-IV compiler that I used in 1968 on the System/360. (That said, I've always understood it was there from at least FORTRAN II.) I seem to recall needing 'i' for vector stuff, Maxwell's equations etc. (If I'm wrong it must have been on the VAX FORTRAN-IV several years later. Correct me if I'm wrong.
pjmlp 6y ago
And like in everything C, unlike Fortran, there is no way for the compiler to validate if restrict is being used properly. Use it wrong, break the compiler assumptions and the bug hunting fun starts.
- TazeTSchnitzel 6y ago
  How does Fortran enforce this, actually? Does it just not let you pass the same array to a function via multiple parameters?
  - bodhiandpysics1 6y ago
    Fortran didn't originally have pointers, and pointer based code is relatively rare in fortran, so making requirements about pointer aliasing doesn't have same potential to completely break your code that it does in c. The reason c can't actually restrict the restrict keywoard, is that the standard would break code!
    - gnufx 6y ago
      The storage association rules have nothing to do with pointers like that. Code will typically break because arguments are passed with copy-in/copy-out semantics, not by reference.
  - gnufx 6y ago
    It does, indeed, but that's not the only way to associate storage. Using INTENT to specify whether an array is updated is useful.
- gnufx 6y ago
  Mostly the compiler won't catch violation of the storage association rules. Toolpack had a useful tool for strict F77 code which was a boon fixing stuff not to break with the Alliant compiler, which was the first one the project I inherited used that took advantage of the optimization opportunity. Possibly Cray's would have done, but hadn't been used for a while at that point. The fact that people won't believe the rules exist, is a continual source of bug hunting in Fortran unfortunately. At least restrict is visible.
tobmlt 6y ago
I __think__ Fortran just never gave you this particular footgun. No aliasing of pointers allowed from the getgo. It was never an issue. Somebody let me know if that is wrong. I read Complex numbers came in FORTRAN IV, so mid 60’s. I never used anything older than FORTRAN 77, and it certainly had complex numbers, and also ways for the “inventive” programmer to make use of pointer like functionality. You could e.g. pass functions to functions, if you were so inclined.
- hilbert42 6y ago
  "I read Complex numbers came in FORTRAN IV, so mid 60’s." FYI, this link [PDF] https://personalpages.manchester.ac.uk/staff/paul.johnson-2/resources/fortranShort/link-wiki.pdf https://personalpages.manchester.ac.uk/staff/paul.johnson-2/... contains the peculiar statement "Over the next few years, FORTRAN II would also add support for the DOUBLE PRECISION and COMPLEX data types." At face value, that statement implies complex numbers came later but before FORTRAN III, which also implies a point release (FORTRAN II was released in 1958). Moreover, I read somewhere that FORTRAN III had it but it wasn't widely released. Likely then that FORTRAN IV was the first widely released version with complex numbers. As it was released in 1961, we should assume then that this was the likely date.
  - tobmlt 6y ago
    Pretty cool, thanks for the details! This is about what I’d expect from ancient FORTRAN. (I read fortran IV off Wikipedia, maybe there was fine print)
    - hilbert42 6y ago
      You'll note from one of my other posts that FORTRAN-IV was my intro into programming. However, that was toward the end of the decade not the beginning. By then, many universities were running the WATFOR FORTRAN-IV compiler from U. Waterloo. At the time it was anything but ancient. We students felt both cocky and privileged in that we knew that we were some of the very few people in the country who had access to a state-of-the-art IBM mainframe. BTW, the mainframe, a System/360, had just 44kB memory and ran 7 concurrent operations at once. It was a red-letter day when the '360 got upgraded to 77kB memory. The university's rag had the fact as large headlines on its front page.

readflaggedcomm 6y ago

Tested in the sense of test suites and formal proofs? That would be valuable to other disciplines using other tools. But this article isn't about fundamental algorithms being correctly-implemented in an endowment of legacy code, it's about defending a siloed language choice, which seems like an antiquated concern to me. I applaud anyone using a tool that works for them, but if it's good, then its users have accomplished things which transcend an individual tool.

hilbert42 6y ago
"But this article isn't about fundamental algorithms being correctly-implemented in an endowment of legacy code, it's about defending a siloed language choice, which seems like an antiquated concern to me." 1. The first comment I would make is that the headline premise is wrong or at least deliberately misleading. Let's start with a correction. I would very much doubt that climate models are written in programming languages from 1950s. The Fortran code of the 1950s was not that much like the Fortran code that I learned in the late 1960s, and that late 1960s code bears little resemblance with modern Fortran code of today. Furthermore, the Fortran standard is certainly not dead, it is being continually updated: http://fortranwiki.org/fortran/show/Standards http://fortranwiki.org/fortran/show/Standards. 2. When I made comment about libraries going back 60 or so years, this would imply that libraries written in Fortran II ca 1956 or so would pose a problem today. I would suggest that it is not so because the process of updating libraries is formal and strict, thus an updated Fortran II subroutine would work perfectly well with today's modern Fortran. This 'upgrade' process is not like converting code from say Pascal to C or whatever, for here we are still within the confines of the Fortran framework and that that conversion process is well understood, straightforward and procedural. 3. This isn’t my idea, nor am I defending something that I learned decades ago and don't want to give up. Frankly, I do little Fortran programming these days so it's essentially irrelevant to me. The point I made and that I make again is that there is a sophisticated scientific computing environment in existence and it is used by thousands of current researchers and scientists around the world. Scientists would not use antiquated software on cutting edge science if it did not work. The fact is modern Fortran is a modern programming language that delivers the goods par excellence—likely much better than any other language, especially so given its long and mature infrastructure. For example, here are the first two reference I came across on the net, there are thousands more just like this: https://arxiv.org/abs/hep-ph/0612134 https://arxiv.org/abs/hep-ph/0612134 https://www.sciencedirect.com/science/article/abs/pii/S0010465518302200 https://www.sciencedirect.com/science/article/abs/pii/S00104... 4. Now let's look at the current situation—'modern' software. To begin, you should read this 27-year old Scientific American article titled 'Software's Chronic Crisis' from September 1994: https://www.researchgate.net/publication/247573088_Software's_Chronic_Crisis https://www.researchgate.net/publication/247573088_Software'... I would contend that this article is just as relevant today as it was 27 years ago if not more so. In summary it says. • Programmers work more like undisciplined artists than processional engineers (this problem remains unresolved). • Essentially programming is not true engineering (since the time of the article, computer science has progressed somewhat but on the ground we still have multitude of unresolved problems). • If programming is to be likened to engineering then it is in a highly unevolved state somewhat akin to the chemical industry ca 1800. Its practical function or operation is a mismatch with the everyday world or we wouldn't have the proliferation of problems that we currently have. When, these days, one examines the situation with literally hundreds of different computer languages in existence, it is clear that there isn't enough human time and effort to rationalise them all and develop a coherent set of tools, in essence almost everything around us is only half done. We stand in the midst of an unholy Tower of Babel and it's an unmitigated mess (I could spend hours telling you what's wrong but you'll know that already). The crux of the problem is that programmers spend much time and resources learning one or more computer languages and that it's dead easy to poke fun at mature languages such as Fortran as being old fashioned and out of date. The fact is they either do not adequately understand them or the reasons why they are used, or it is both. The fact is it is this very maturity of Fortran that makes it so valuable to scientist and engineers. Those who are not conversant with or do not program in Fortran have simply not understood the reasons for its success. Scientists and engineers have found the most reliable, stable and best fit available and that is to use a modern version of Fortran—simply because its reliable and it works. This article only shows authors lack of understanding of the problem. Oh, BTW, let me add that I have no contention with theoretical computer science models. It's just the divide between theoretical computer science and what happens in practice is as wide as it ever was.

LargoLasskhyfv 6y ago

Ahem ;-) Somehow your mention of cowboys entering the field feels irritating, considering Kazushige Goto and his contributions to BLAS while being in Austin, TX. Banzai!

gnufx 6y ago
While Goto typically gets the plaudits (and obviously did good work there), you should credit van de Geijn in that area long term.
- LargoLasskhyfv 6y ago
  Oops. Haven't even been aware of that. Anyways, irritation over 'cowboys entering into the field' still stands, because it happened in Austin, TX. Yeehaw! ;-)

ianai 6y ago

That makes it pretty clear that Fortran is set up to be the perfect foe to "latest has to be greatest" programmers.

saboot 6y ago

Researcher in Nuclear Engineering chiming in with a similar experience. Much of our code is the same way, and in fact our field more or less invented many computing methods used today. One widely used simulation code called MCNP [1] can trace it's origins back to running on the ENIAC at Los Alamos in the 40s(!). At some point, it was considered a major upgrade when it was rewritten into fortran90. [1] https://en.wikipedia.org/wiki/Monte_Carlo_N-Particle_Transport_Code https://en.wikipedia.org/wiki/Monte_Carlo_N-Particle_Transpo...

tzs 6y ago

> From the outset, it could handle complex numbers, double precision, etc., etc. natively without having to resort to calling libraries/special routines as other languages had to do back then. At least until sometime in the '80s another advantage of Fortran over C was that it could handle single precision floating point. C always promoted float to double when you did arithmetic with it. Arithmetic was faster on floats than doubles, and that could make quite a difference in a big simulation that was going to take a long time to run. The high energy physics group at Caltech back then had a locally modified version of the C compiler that would use single precision when the code tries to do arithmetic on floats. Some of the physicists used that for programs that otherwise would have been in Fortran.