14 ms·

Why are most climate models in Fortran?

119 points by JohannMac 6y ago

crb002 6y ago
The tooling is stable so when you link to FORTRAN binaries the ABI tends not to bitrot. IMHO FORTRAN might get a borrow checker before C/C++ to be on parity with Rust for memory safety.
hilbert42 6y ago
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.
- 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.
enriquto 6y ago
Not only "climate models"... a large chunk of scipy is just a thin Python layer over decades-old Fortran code. That many physicists chose to use the real thing instead of the fisher-price interface speaks in favor of them.
- wrnr 6y ago
  Gonum wraps the same code, from what i could tell fortran seem to have a neat way to handle more specialised number systems like dual numbers and hyperbolic numbers.
  - spacedome 6y ago
    You can do operator overloading in fortran to add a new number type, don't remember the details but I wrote a quaternion library once.
- analog31 6y ago
  Actually, as a user of the fisher-price interface, I'm glad that it can bind to C and FORTRAN libraries, so my numerics are based on the highest quality code.
  - enriquto 6y ago
    I'm also a very happy user of the dumbed-down interfaces. But I find it strange when my fellow users are surprised or even horrified at the fact that some people still write and maintain Fortran and C code. Hell the Python interpreter they use is written in C! But apparently if you write in C you are some sort of old man yelling at clouds.
- cozzyd 6y ago
  It is sad indeed that so few new languages have a stable ABI like Fortran and C.
waynesonfire 6y ago
Something really strange happens when an industry sector is highly populated. Thinking, fortran vs javascript or freebsd vs linux. Seems like a sector with high population and low barrier to entry is prone to illusory superiority that lowers the quality of the system.
Hankenstein2 6y ago
I work at one of the labs mentioned and get paid for running not only the climate models but mesoscale models as well, which are also written in Fortran. The premise of the article is that Fortran, 70 years later is still an appropriate tool to use for crunching numbers which it absolutely is but it neglects one major problem. Like the COBOL issue that was all the rage 20 years ago, it is difficult to hire younger generation programmers that want to and are excited to develop in Fortran.
- thelastestate 6y ago
  My understanding is that they're mostly fortran programs linked together with unix scripts which are run on HPCs - could the models run in a more distributed way like high quality grid computing setup? Lastly, what's the best way to find and learn more about the models?
  - cbkeller 6y ago
    Switching to any sort of commercial grid or cloud computing setup would be rather complicated by the fact that climate models are critically dependent on the fast, low-latency interconnects (e.g., infiniband) of a proper HPC system to achieve good performance at scale. This is usually coordinated with hand-written message passing via MPI directly in the relevant top-level Fortran (or C/++) program. There are some other (i.e, “embarrassingly parallel”) scientific computing problems where a higher-latency distributed setup would be fine, but in climate models, as in any finite-element model, each grid cell needs to be able to “talk to” its neighbors at each timestep, leading to quite a lot of inter-process communication.
  - JBorrow 6y ago
    Difficult to run true HPC software like this as a 'grid'. High speed, low latency communication (with MPI) is required.
  - milancurcic 6y ago
    Yes, they run in the cloud, see e.g. https://cloudrun.co https://cloudrun.co (disclaimer: my side-business), but others have done it as well, for a few years now. On dedicated, shared-memory nodes, it's no different from HPC performance-wise. It can be even better because cloud instances tend to have later generation CPUs, whereas large HPC systems are typically updated every ~5 years or so. But for distributed-memory parallel runs (multi-nodes), latency increases considerably on commodity clouds which kills parallel scaling for models. Fortunately, major providers (AWS, GCP, Azure) have recently started offering low-latency interconnects for some of their VMs, so this problem will soon go away as well.
cbkeller 6y ago
High performance scientific computing is very much still a FORTRAN, C, and C++ game. And of those, FORTRAN has some compelling advantages in terms of first-class built-in support for multidimensional arrays, and quite excellent compilers. And, as others have noted, until the `restrict` keyword in C99, there were optimizations in FORTRAN that were not even possible in C. I mostly used C for my (small-scale) HPC work in grad school because it’s what I knew best, but at several points I wished I had learned Fortran instead. Probably one of the only “higher level” languages that’s ever been used for serious petascale scientific computing is Julia (first with Celeste on the astro side, possibly soon with CliMA for climate modeling), which not coincidentally follows similar array indexing conventions as FORTRAN. And while that’s what I mostly use now, I don’t see Fortran going away any time soon. If anything, with cool new projects like LFortran [1] making it possible to use Fortran more interactively, it’s probably quite a good time to learn modern Fortran! [1] https://lfortran.org/ https://lfortran.org/
- deleted 6y ago
  [deleted]
- yodelshady 6y ago
  Open question: why are multi-dimensional arrays, and matrices specifically, so neglected in almost every other language? They map well to practically freakin' everything, for what seems like.. not that much effort on the language design side, but an enormous amount of tedious, duplicated effort on the user side.
  - hntrader 6y ago
    This is a great question and I hope you get an answer to this. The number of woeful ad-hoc solutions I've seen to people handling matrix data in Java/C# for what should've been otherwise very basic analysis ... Something with pandas-like capability in a lower level language would be amazing.
    - krona 6y ago
      Something with pandas-like capability in a lower level language would be amazing. More like numpy than pandas but I've used x-tensor (c++) with great success in several projects: https://xtensor.readthedocs.io/en/latest/index.html https://xtensor.readthedocs.io/en/latest/index.html
pjmlp 6y ago
Why doing the examples in Fortran 90 in 2021 blog post, when 2018 is the most recent standard revison?
- jcranmer 6y ago
  I'm not an expert in Fortran, but my understanding is that Fortran 90 is basically the equivalent of C++11--it added a slew of major features (such as free format code and array notation) that makes it a pretty different language from pre-90 code. Even if newer language revisions add some more useful features, it's the core set from Fortran 90 that's worth differentiating, much as I might describe modern C++ code as C++11 even if the project requires C++14 or C++17.
  - ch_123 6y ago
    This is absolutely correct - Fortran standards after 90/95 have mostly added extra features, rather than fundamental changes to how people write Fortran. Fortran 2003 added OO support, but I don’t believe that has seen widespread adoption.
    - ryl00 6y ago
      Fortran 2003 also added BIND(C) and ISO_C_BINDING, which are massively useful in standardizing the C interop.
      - madhadron 6y ago
        Oh, that's a nice thing. I still remember carefully appending underscores to names to thing to make C and FORTRAN talk in gcc/g77.
- hatmatrix 6y ago
  I don't think it would look different. There is a big difference between Fortran 77 and Fortran 90, but less between Fortran 90 and Fortran 2018, at least for this example.
CookieMon 6y ago
How is Fortran coming along with GPUs? (last I looked it was being done with proprietary compiler language extensions, but that was a while ago) Are modern supercomputers faster than a cluster of consumer-grade GPU cards?
- sampo 6y ago
  > Are modern supercomputers faster than a cluster of consumer-grade GPU cards? On the top500 list, #1 does 400,000 TFlop/s, #500 does 1000 TFlop/s. How much would the kind of GPU cluster you're thinking of do? https://www.top500.org/lists/top500/2020/11/ https://www.top500.org/lists/top500/2020/11/
- ch_123 6y ago
  > How is Fortran coming along with GPUs? (last I looked it was being done with proprietary compiler language extensions, but that was a while ago) There is support for CUDA in Fortran. In fact, Nvidia purchased one of the main Fortran compiler vendors (PGI) and is open sourcing their compiler as flang. CUDA is the predominant GPU programming model in the HPC space. There are open standards, but they are nowhere nearly as widely used. > Are modern supercomputers faster than a cluster of consumer-grade GPU cards? Fundamentally, supercomputers use the same processors and GPUs that you find in consumer hardware. The differences tend to lie in A) the sheer quantity of hardware used (think millions of cores for Top 10 systems), B) high bandwidth, low latency interconnects and C) some market segmentation by hardware vendors (e.g. Nvidia deliberately limits the double-float performance of consumer hardware)
  - CookieMon 6y ago
    Wow, the PGI compiler becoming open-sourced is awesome.
sampo 6y ago
Hint for commenters: Since Fortran 90, it's spelled Fortran, not FORTRAN. By using the latter you signal that your experience on the topic is from 30 years ago. https://en.wikipedia.org/wiki/Fortran#Fortran_90 https://en.wikipedia.org/wiki/Fortran#Fortran_90
- jcranmer 6y ago
  But Fortran is case insensitive, so it should be no problem if you spell it Fortran or FORTRAN or fORtRaN.
- shortlived 6y ago
  Interesting... iOS will autocorrect to “FORTRAN”
- fuzzfactor 6y ago
  >it's spelled Fortran, not FORTRAN. By using the latter you signal that your experience on the topic is from 30 years ago. Excellent idea to help filter out those having the lesser number of decades experience.
  - hilbert42 6y ago
    Correct, but as I mentioned above, one should use the original acronym form when referring to an old version that was specifically named that way.
- hilbert42 6y ago
  Right. Sometimes old habits die hard and I use FORTRAN when I mean Fortran but I don't do it intentionally nor do I do it out of ignorance. (I note that as I type this into Firefox, its speller still wants to capitalize the word! As I've discovered so do many other editors and word-processors.) In recent years I've adopted the following nomenclature and you'll note I've done so here in my earlier posts. That is to treat the name of each specific version as a proper name. As FORTRAN IV was originally called that including the Romanized numerals for the version number I use that out of respect for those who originally named it in the same way I'd always use say John and not john. Nowadays, when I refer to Fortran in its generic sense I use its new default name rather than its old acronym form.
colllectorof 6y ago
Engineers are horrified to learn that mathematical modeling is done in a language created in the 50s, but aren't bothered by the fact that the dominant computer interaction model used in the field right now dates back to pre-WW2 teleprinters. Someone is lacking in self- and historic awareness. What practical problems does Fortran cause when used for numerical computing?
- enriquto 6y ago
  Somebody should warn them about avoiding accidentally using Pythagoras theorem, that was introduced 2500 years ago.
  - Trex_Egg 6y ago
    Funny
  - amelius 6y ago
    Unlike computer software, mathematical theorems don't suffer from bit rot.
    - pron 6y ago
      Neither do languages, especially formal ones.
      - deleted 6y ago
        [deleted]
      - IshKebab 6y ago
        FORTRAN isn't a formal language though.
        pron 6y ago
        Of course it is, just like all programming languages. If it weren't formal, a computer couldn't interpret it precisely. Formal means mechanical; a language whose calculus can be carried out by a machine.
dgellow 6y ago
I'm not familiar at all with the world of high performance scientific computing. Are C++, Rust, Nim, Zig, & co. even remotely considered as potential candidates in the future, or is it really only C and Fortran with no expectation to see much changes? Just curious.
- Chemiseblanc 6y ago
  C++ sees a fair amount of use and has some mature libraries written in it like the trilinos collection alongside being able to use existing C libraries. I think for other languages the limiting factor is the maturity of their linear algebra libraries and if someone has written bindings to use MPI
- hpb42 6y ago
  C++ is widely used for High Energy Physics. The ROOT framework [0], developed at CERN, is mostly C++. I'd be tempted to say that Rust could be used as well, but the equivalent of MPI and OpenMP for Rust is still not as fast as in C++/C/Fortran.[2] That's easy to understand: there are decades of investment in MPI/OpenMP for C/C++/Fortran, and Rust is not there yet. Also, in some cases where high throughput is needed, languages with garbage collector are not suited. In this scenario, deterministic execution time and deterministic latency are very important. Not directly related to HPC, but Discord migrated from Go to Rust for this reason[2]. [0] https://root.cern/ https://root.cern/ [1] https://github.com/trsupradeep/15618-project https://github.com/trsupradeep/15618-project [2] https://blog.discord.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f https://blog.discord.com/why-discord-is-switching-from-go-to...
  - dgellow 6y ago
    Thanks, discord’s article is fascinating.
- IshKebab 6y ago
  I haven't read the article but in my experience FORTRAN is used because a lot of really complex numerical routines were written years ago by really smart people in FORTRAN and nobody really wants to rewrite them. There are exceptions - the basic LAPACK stuff has modern alternatives (e.g. Eigen for C++, nalgebra for Rust). But there are a ton of more specialist libraries, e.g. ARPACK that people probably aren't going to rewrite. That said, there's a FORTRAN to C transpiler that works pretty well. I used it when I needed ARPACK and didn't want to deal with FORTRAN.
hatmatrix 6y ago
C and C++ are definitely the competitors to Fortran; not Chapel or Python. In the life sciences, large amounts of Fortran code has been rewritten in C/C++. But they have orders of magnitude more funding than climate science and teams of professional programmers to maintain the code. Fortran is a domain-specific language for scientists, and excels at array arithmetic (for graph-based problems though, maybe look elsewhere). Even badly-written code can run reasonably fast, which is not the same for C/C++. There is also the decades of concerted hardware and compiler optimizations that make Fortran hard to beat on HPC systems. It's not as readable as Python, but it's more readable than C/C++ written by a professional programmer.
- cozzyd 6y ago
  There's a saying among physicists that you can write Fortran in any language.
  - hatmatrix 6y ago
    I've seen it with my own eyes. It's not pretty, but usually works.
jessaustin 6y ago
TFA would seem more reliable if it didn't have such a needlessly obscurantist Fortran-python code comparison. Nothing about the two languages calls for different base case logic! That is, in order to prevent confusion, the "Python3" code should have been this: def fibonacci(n): if n < 2: return n else: return fibonacci(n-1) + fibonacci(n-2)
- hyperrail 6y ago
  From the other side, I thought the Fortran code had too much syntactic ceremony. I haven't written Fortran in a while, but I was pretty sure that for illustrative examples like this, you could dispense with the entire MODULE declaration, the use of END FUNCTION Fibonacci instead of just END, and the usually-optional :: separator between the variable's type and name. Something like this? Again, no recent experience: implicit none recursive function fibonacci(n) result (fib) integer n integer fib if (n < 2) then fib = n else fib = fibonacci(n - 1) + fibonacci(n - 2) endif end (The IMPLICIT NONE has to stay because of the now-regrettable Fortran convention that without it, the type of a variable is determined by the first character of the name (n would be integer because variables starting with m, n, i, etc. are integer, while fib would be floating point).)
complex_pi 6y ago
Fortran is hot at the moment :-) See "Resurrecting Fortran" (blog post by Ondřej Čertík https://news.ycombinator.com/item?id=26445438 https://news.ycombinator.com/item?id=26445438 https://ondrejcertik.com/blog/2021/03/resurrecting-fortran/ https://ondrejcertik.com/blog/2021/03/resurrecting-fortran/ ) about the promising Fortran "standard lib" and the Fortran community in general (see the related website https://fortran-lang.org/ https://fortran-lang.org/ ). The story here is interesting but lacks a bit about this wider context.
person_of_color 6y ago
Anyone doing gen-art in Fortran?
simplicio 6y ago
Another advantage to Fortran in academic settings, at least the older version of Fortran, is that there isn't much to the language. Someone already familiar with programming can pick it up in a day or two. So if your a Prof with a large code-base that you want to have a stream of Grad-students, undergrad research assistants, assoc. Profs etc. contribute to before they move on, having a language that doesn't require squandering half a semester on learning to code before you can start doing actual science is a big bonus.
spartee 6y ago
Author here - Thanks for reading!! Lots of great comments here. Happy Pi day!
JustSomeNobody 6y ago
Because there is absolutely nothing wrong with using Fortran for what Fortran is very good at.
airhead969 6y ago
Fortran will always be around because there's too much investment in it. A nuclear reactor simulator I ported from UNIX to Win32 in 1998 was several million lines of code written by nuclear engineers (not software engineers) and physicists. It's over 60 years old now.
dwheeler 6y ago
The actual title is, "Why are Climate models written in programming languages from 1950?". I think the assumption that "old is bad" is the cause of many, many, many foolish decisions. Useless code rewrites, company reorganizations that are not significant improvements, and many other bad ideas hinge on this Worship Of The New. Why are we using an alphabetic system originally developed c. 1800BC? It's old, we should switch to new writing systems every 10 years because they're new, right :-)? Older is not better. Newer is not better. Better is better. There's no point in switching something if the destination isn't better, and even if it's clearly better, it needs to be so much better that it's worth the switching cost.
- madhadron 6y ago
  And it's just a misunderstanding. I think it was Perlis who said, "We don't know what the programming language of the future will look like, but we know it will be called FORTRAN."
  - gnufx 6y ago
    Hoare said "I don’t know what the language of the year 2000 will look like, but I know it will be called Fortran". He also said "ALGOL 60 is alive and well and living in Fortran 90", which is a decent compliment from him.
    - madhadron 6y ago
      Ah, thank you.
- anthk 6y ago
  This. The OS I use dates back to BSD 4.4, which is a rewrite and rehasing on some OS which is about 50 years old. The audio plug is over 100 years old, and modern TTY's date back to what, 80 years? If it works, it works. Also, damn Calculus is over 200 years old. Or maybe 2000, depending if you compare it to the method of exhaustion or not.
chris_va 6y ago
(disclaimer: I work in a Climate&Energy R&D Lab) I don't entirely agree with the overall assertion of this article. The author has some valid points, but I think it misses the forest for the trees. TLDR: I think Fortran tooling and HPC clusters are a self-reinforcing local maximum. They are heavily optimized for each other, but at the cost of innovation and extensibility. For example, we'll never get a fully differentiable climate model in Fortran. The tooling does not exist, and there are not enough Fortran developers to make a serious dent in the tooling progress made outside of the HPC world. The MPI stacks these codes rely on are not great for hardware outside of a supercomputer, and Fortran codes basically are built around full interconnect. I have many PFLOPs at my disposal that I cannot use because these codes are too brittle without being entirely rewritten. At the end of the day, everything is a Turing machine, so you can technically do whatever you want in Fortran or any other language (or mix and match), but strategically staying in Fortran leaves a lot of resources on the table.
- cbkeller 6y ago
  Well Fortran was, notably, one of the first languages to have proper source-to-source autodiff (TAPENADE) [1-3], so it’s probably not impossible, though my choice for a fully differentiable climate model would personally be Julia, like the CliMA folks at Caltech [4]. [1] https://doi.org/10.1145/2450153.2450158 https://doi.org/10.1145/2450153.2450158 [2] http://www-tapenade.inria.fr:8080/tapenade/index.jsp http://www-tapenade.inria.fr:8080/tapenade/index.jsp [3] http://www-sop.inria.fr/ecuador/tapenade/distrib/README.html http://www-sop.inria.fr/ecuador/tapenade/distrib/README.html [4] https://clima.caltech.edu/ https://clima.caltech.edu/
tianlong 6y ago
These considerations are valid also in another fields such as in computational quantum physics/chemistry. Major software are written in Fortan and in C++. I work in the ML community now, after many years of quantum chemistry and when I say that I know Fortran people usually laugh :).
m463 6y ago
Has anyone LOOKED at fortran recently? Some excerpts from https://en.wikipedia.org/wiki/Fortran https://en.wikipedia.org/wiki/Fortran Fortran 90: - Ability to operate on arrays (or array sections) as a whole, thus greatly simplifying math and engineering computations. - whole, partial and masked array assignment statements and array expressions, such as X(1:N)=R(1:N)*COS(A(1:N)) Fortran 2003: - Object-oriented programming support: type extension and inheritance, polymorphism, dynamic type allocation, and type-bound procedures, providing complete support for abstract data types Fortran 2008: - Sub-modules—additional structuring facilities for modules; supersedes ISO/IEC TR 19767:2005 - Coarray Fortran—a parallel execution model - The DO CONCURRENT construct—for loop iterations with no interdependencies - The BLOCK construct—can contain declarations of objects with construct scope Fortran 2018: - Further interoperability with C
anthk 6y ago
BLAS uses Fortran I think, and Lapack. Good luck calling that slow. Another clueless JS hipster, maybe.
- gnufx 6y ago
  The reference BLAS in Fortran is indeed slow. I'm not aware of any tuned version in Fortran. It might be possible to re-write the BLIS structure in Fortran and get reasonable performance on, say, Haswell, but not on SKX, if we talk x86.
  - anthk 6y ago
    >Tuned. Intel on HPCs.
TheRealKing 6y ago
For heavens sake, let's stop the discussion of Fortran array index starting at 1. In Fortran the starting index can be anything. A(-10:-5) is valid, A(-10:10) is valid, A(1:10) is valid, A(0:10) is valid. Choose what you want and do not complain about it again, please. No other language has this amazing capability.

119 points by JohannMac 6y ago

The tooling is stable so when you link to FORTRAN binaries the ABI tends not to bitrot. IMHO FORTRAN might get a borrow checker before C/C++ to be on parity with Rust for memory safety.

hilbert42 6y ago

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.
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.

enriquto 6y ago

Not only "climate models"... a large chunk of scipy is just a thin Python layer over decades-old Fortran code. That many physicists chose to use the real thing instead of the fisher-price interface speaks in favor of them.

wrnr 6y ago
Gonum wraps the same code, from what i could tell fortran seem to have a neat way to handle more specialised number systems like dual numbers and hyperbolic numbers.
- spacedome 6y ago
  You can do operator overloading in fortran to add a new number type, don't remember the details but I wrote a quaternion library once.
analog31 6y ago
Actually, as a user of the fisher-price interface, I'm glad that it can bind to C and FORTRAN libraries, so my numerics are based on the highest quality code.
- enriquto 6y ago
  I'm also a very happy user of the dumbed-down interfaces. But I find it strange when my fellow users are surprised or even horrified at the fact that some people still write and maintain Fortran and C code. Hell the Python interpreter they use is written in C! But apparently if you write in C you are some sort of old man yelling at clouds.
cozzyd 6y ago
It is sad indeed that so few new languages have a stable ABI like Fortran and C.

waynesonfire 6y ago

Something really strange happens when an industry sector is highly populated. Thinking, fortran vs javascript or freebsd vs linux. Seems like a sector with high population and low barrier to entry is prone to illusory superiority that lowers the quality of the system.

Hankenstein2 6y ago

I work at one of the labs mentioned and get paid for running not only the climate models but mesoscale models as well, which are also written in Fortran. The premise of the article is that Fortran, 70 years later is still an appropriate tool to use for crunching numbers which it absolutely is but it neglects one major problem. Like the COBOL issue that was all the rage 20 years ago, it is difficult to hire younger generation programmers that want to and are excited to develop in Fortran.

thelastestate 6y ago
My understanding is that they're mostly fortran programs linked together with unix scripts which are run on HPCs - could the models run in a more distributed way like high quality grid computing setup? Lastly, what's the best way to find and learn more about the models?
- cbkeller 6y ago
  Switching to any sort of commercial grid or cloud computing setup would be rather complicated by the fact that climate models are critically dependent on the fast, low-latency interconnects (e.g., infiniband) of a proper HPC system to achieve good performance at scale. This is usually coordinated with hand-written message passing via MPI directly in the relevant top-level Fortran (or C/++) program. There are some other (i.e, “embarrassingly parallel”) scientific computing problems where a higher-latency distributed setup would be fine, but in climate models, as in any finite-element model, each grid cell needs to be able to “talk to” its neighbors at each timestep, leading to quite a lot of inter-process communication.
- JBorrow 6y ago
  Difficult to run true HPC software like this as a 'grid'. High speed, low latency communication (with MPI) is required.
- milancurcic 6y ago
  Yes, they run in the cloud, see e.g. https://cloudrun.co https://cloudrun.co (disclaimer: my side-business), but others have done it as well, for a few years now. On dedicated, shared-memory nodes, it's no different from HPC performance-wise. It can be even better because cloud instances tend to have later generation CPUs, whereas large HPC systems are typically updated every ~5 years or so. But for distributed-memory parallel runs (multi-nodes), latency increases considerably on commodity clouds which kills parallel scaling for models. Fortunately, major providers (AWS, GCP, Azure) have recently started offering low-latency interconnects for some of their VMs, so this problem will soon go away as well.

cbkeller 6y ago

High performance scientific computing is very much still a FORTRAN, C, and C++ game. And of those, FORTRAN has some compelling advantages in terms of first-class built-in support for multidimensional arrays, and quite excellent compilers. And, as others have noted, until the `restrict` keyword in C99, there were optimizations in FORTRAN that were not even possible in C. I mostly used C for my (small-scale) HPC work in grad school because it’s what I knew best, but at several points I wished I had learned Fortran instead. Probably one of the only “higher level” languages that’s ever been used for serious petascale scientific computing is Julia (first with Celeste on the astro side, possibly soon with CliMA for climate modeling), which not coincidentally follows similar array indexing conventions as FORTRAN. And while that’s what I mostly use now, I don’t see Fortran going away any time soon. If anything, with cool new projects like LFortran [1] making it possible to use Fortran more interactively, it’s probably quite a good time to learn modern Fortran! [1] https://lfortran.org/ https://lfortran.org/

deleted 6y ago
[deleted]
yodelshady 6y ago
Open question: why are multi-dimensional arrays, and matrices specifically, so neglected in almost every other language? They map well to practically freakin' everything, for what seems like.. not that much effort on the language design side, but an enormous amount of tedious, duplicated effort on the user side.
- hntrader 6y ago
  This is a great question and I hope you get an answer to this. The number of woeful ad-hoc solutions I've seen to people handling matrix data in Java/C# for what should've been otherwise very basic analysis ... Something with pandas-like capability in a lower level language would be amazing.
  - krona 6y ago
    Something with pandas-like capability in a lower level language would be amazing. More like numpy than pandas but I've used x-tensor (c++) with great success in several projects: https://xtensor.readthedocs.io/en/latest/index.html https://xtensor.readthedocs.io/en/latest/index.html

pjmlp 6y ago

Why doing the examples in Fortran 90 in 2021 blog post, when 2018 is the most recent standard revison?

jcranmer 6y ago
I'm not an expert in Fortran, but my understanding is that Fortran 90 is basically the equivalent of C++11--it added a slew of major features (such as free format code and array notation) that makes it a pretty different language from pre-90 code. Even if newer language revisions add some more useful features, it's the core set from Fortran 90 that's worth differentiating, much as I might describe modern C++ code as C++11 even if the project requires C++14 or C++17.
- ch_123 6y ago
  This is absolutely correct - Fortran standards after 90/95 have mostly added extra features, rather than fundamental changes to how people write Fortran. Fortran 2003 added OO support, but I don’t believe that has seen widespread adoption.
  - ryl00 6y ago
    Fortran 2003 also added BIND(C) and ISO_C_BINDING, which are massively useful in standardizing the C interop.
    - madhadron 6y ago
      Oh, that's a nice thing. I still remember carefully appending underscores to names to thing to make C and FORTRAN talk in gcc/g77.
hatmatrix 6y ago
I don't think it would look different. There is a big difference between Fortran 77 and Fortran 90, but less between Fortran 90 and Fortran 2018, at least for this example.

CookieMon 6y ago

How is Fortran coming along with GPUs? (last I looked it was being done with proprietary compiler language extensions, but that was a while ago) Are modern supercomputers faster than a cluster of consumer-grade GPU cards?

sampo 6y ago
> Are modern supercomputers faster than a cluster of consumer-grade GPU cards? On the top500 list, #1 does 400,000 TFlop/s, #500 does 1000 TFlop/s. How much would the kind of GPU cluster you're thinking of do? https://www.top500.org/lists/top500/2020/11/ https://www.top500.org/lists/top500/2020/11/
ch_123 6y ago
> How is Fortran coming along with GPUs? (last I looked it was being done with proprietary compiler language extensions, but that was a while ago) There is support for CUDA in Fortran. In fact, Nvidia purchased one of the main Fortran compiler vendors (PGI) and is open sourcing their compiler as flang. CUDA is the predominant GPU programming model in the HPC space. There are open standards, but they are nowhere nearly as widely used. > Are modern supercomputers faster than a cluster of consumer-grade GPU cards? Fundamentally, supercomputers use the same processors and GPUs that you find in consumer hardware. The differences tend to lie in A) the sheer quantity of hardware used (think millions of cores for Top 10 systems), B) high bandwidth, low latency interconnects and C) some market segmentation by hardware vendors (e.g. Nvidia deliberately limits the double-float performance of consumer hardware)
- CookieMon 6y ago
  Wow, the PGI compiler becoming open-sourced is awesome.

sampo 6y ago

Hint for commenters: Since Fortran 90, it's spelled Fortran, not FORTRAN. By using the latter you signal that your experience on the topic is from 30 years ago. https://en.wikipedia.org/wiki/Fortran#Fortran_90 https://en.wikipedia.org/wiki/Fortran#Fortran_90

jcranmer 6y ago
But Fortran is case insensitive, so it should be no problem if you spell it Fortran or FORTRAN or fORtRaN.
shortlived 6y ago
Interesting... iOS will autocorrect to “FORTRAN”
fuzzfactor 6y ago
>it's spelled Fortran, not FORTRAN. By using the latter you signal that your experience on the topic is from 30 years ago. Excellent idea to help filter out those having the lesser number of decades experience.
- hilbert42 6y ago
  Correct, but as I mentioned above, one should use the original acronym form when referring to an old version that was specifically named that way.
hilbert42 6y ago
Right. Sometimes old habits die hard and I use FORTRAN when I mean Fortran but I don't do it intentionally nor do I do it out of ignorance. (I note that as I type this into Firefox, its speller still wants to capitalize the word! As I've discovered so do many other editors and word-processors.) In recent years I've adopted the following nomenclature and you'll note I've done so here in my earlier posts. That is to treat the name of each specific version as a proper name. As FORTRAN IV was originally called that including the Romanized numerals for the version number I use that out of respect for those who originally named it in the same way I'd always use say John and not john. Nowadays, when I refer to Fortran in its generic sense I use its new default name rather than its old acronym form.

colllectorof 6y ago

Engineers are horrified to learn that mathematical modeling is done in a language created in the 50s, but aren't bothered by the fact that the dominant computer interaction model used in the field right now dates back to pre-WW2 teleprinters. Someone is lacking in self- and historic awareness. What practical problems does Fortran cause when used for numerical computing?

enriquto 6y ago
Somebody should warn them about avoiding accidentally using Pythagoras theorem, that was introduced 2500 years ago.
- Trex_Egg 6y ago
  Funny
- amelius 6y ago
  Unlike computer software, mathematical theorems don't suffer from bit rot.
  - pron 6y ago
    Neither do languages, especially formal ones.
    - deleted 6y ago
      [deleted]
    - IshKebab 6y ago
      FORTRAN isn't a formal language though.
      - pron 6y ago
        Of course it is, just like all programming languages. If it weren't formal, a computer couldn't interpret it precisely. Formal means mechanical; a language whose calculus can be carried out by a machine.

dgellow 6y ago

I'm not familiar at all with the world of high performance scientific computing. Are C++, Rust, Nim, Zig, & co. even remotely considered as potential candidates in the future, or is it really only C and Fortran with no expectation to see much changes? Just curious.

Chemiseblanc 6y ago
C++ sees a fair amount of use and has some mature libraries written in it like the trilinos collection alongside being able to use existing C libraries. I think for other languages the limiting factor is the maturity of their linear algebra libraries and if someone has written bindings to use MPI
hpb42 6y ago
C++ is widely used for High Energy Physics. The ROOT framework [0], developed at CERN, is mostly C++. I'd be tempted to say that Rust could be used as well, but the equivalent of MPI and OpenMP for Rust is still not as fast as in C++/C/Fortran.[2] That's easy to understand: there are decades of investment in MPI/OpenMP for C/C++/Fortran, and Rust is not there yet. Also, in some cases where high throughput is needed, languages with garbage collector are not suited. In this scenario, deterministic execution time and deterministic latency are very important. Not directly related to HPC, but Discord migrated from Go to Rust for this reason[2]. [0] https://root.cern/ https://root.cern/ [1] https://github.com/trsupradeep/15618-project https://github.com/trsupradeep/15618-project [2] https://blog.discord.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f https://blog.discord.com/why-discord-is-switching-from-go-to...
- dgellow 6y ago
  Thanks, discord’s article is fascinating.
IshKebab 6y ago
I haven't read the article but in my experience FORTRAN is used because a lot of really complex numerical routines were written years ago by really smart people in FORTRAN and nobody really wants to rewrite them. There are exceptions - the basic LAPACK stuff has modern alternatives (e.g. Eigen for C++, nalgebra for Rust). But there are a ton of more specialist libraries, e.g. ARPACK that people probably aren't going to rewrite. That said, there's a FORTRAN to C transpiler that works pretty well. I used it when I needed ARPACK and didn't want to deal with FORTRAN.

hatmatrix 6y ago

C and C++ are definitely the competitors to Fortran; not Chapel or Python. In the life sciences, large amounts of Fortran code has been rewritten in C/C++. But they have orders of magnitude more funding than climate science and teams of professional programmers to maintain the code. Fortran is a domain-specific language for scientists, and excels at array arithmetic (for graph-based problems though, maybe look elsewhere). Even badly-written code can run reasonably fast, which is not the same for C/C++. There is also the decades of concerted hardware and compiler optimizations that make Fortran hard to beat on HPC systems. It's not as readable as Python, but it's more readable than C/C++ written by a professional programmer.

cozzyd 6y ago
There's a saying among physicists that you can write Fortran in any language.
- hatmatrix 6y ago
  I've seen it with my own eyes. It's not pretty, but usually works.

jessaustin 6y ago

TFA would seem more reliable if it didn't have such a needlessly obscurantist Fortran-python code comparison. Nothing about the two languages calls for different base case logic! That is, in order to prevent confusion, the "Python3" code should have been this: def fibonacci(n): if n < 2: return n else: return fibonacci(n-1) + fibonacci(n-2)

hyperrail 6y ago
From the other side, I thought the Fortran code had too much syntactic ceremony. I haven't written Fortran in a while, but I was pretty sure that for illustrative examples like this, you could dispense with the entire MODULE declaration, the use of END FUNCTION Fibonacci instead of just END, and the usually-optional :: separator between the variable's type and name. Something like this? Again, no recent experience: implicit none recursive function fibonacci(n) result (fib) integer n integer fib if (n < 2) then fib = n else fib = fibonacci(n - 1) + fibonacci(n - 2) endif end (The IMPLICIT NONE has to stay because of the now-regrettable Fortran convention that without it, the type of a variable is determined by the first character of the name (n would be integer because variables starting with m, n, i, etc. are integer, while fib would be floating point).)

complex_pi 6y ago

Fortran is hot at the moment :-) See "Resurrecting Fortran" (blog post by Ondřej Čertík https://news.ycombinator.com/item?id=26445438 https://news.ycombinator.com/item?id=26445438 https://ondrejcertik.com/blog/2021/03/resurrecting-fortran/ https://ondrejcertik.com/blog/2021/03/resurrecting-fortran/ ) about the promising Fortran "standard lib" and the Fortran community in general (see the related website https://fortran-lang.org/ https://fortran-lang.org/ ). The story here is interesting but lacks a bit about this wider context.

person_of_color 6y ago

Anyone doing gen-art in Fortran?

simplicio 6y ago

Another advantage to Fortran in academic settings, at least the older version of Fortran, is that there isn't much to the language. Someone already familiar with programming can pick it up in a day or two. So if your a Prof with a large code-base that you want to have a stream of Grad-students, undergrad research assistants, assoc. Profs etc. contribute to before they move on, having a language that doesn't require squandering half a semester on learning to code before you can start doing actual science is a big bonus.

spartee 6y ago

Author here - Thanks for reading!! Lots of great comments here. Happy Pi day!

JustSomeNobody 6y ago

Because there is absolutely nothing wrong with using Fortran for what Fortran is very good at.

airhead969 6y ago

Fortran will always be around because there's too much investment in it. A nuclear reactor simulator I ported from UNIX to Win32 in 1998 was several million lines of code written by nuclear engineers (not software engineers) and physicists. It's over 60 years old now.

dwheeler 6y ago

The actual title is, "Why are Climate models written in programming languages from 1950?". I think the assumption that "old is bad" is the cause of many, many, many foolish decisions. Useless code rewrites, company reorganizations that are not significant improvements, and many other bad ideas hinge on this Worship Of The New. Why are we using an alphabetic system originally developed c. 1800BC? It's old, we should switch to new writing systems every 10 years because they're new, right :-)? Older is not better. Newer is not better. Better is better. There's no point in switching something if the destination isn't better, and even if it's clearly better, it needs to be so much better that it's worth the switching cost.

madhadron 6y ago
And it's just a misunderstanding. I think it was Perlis who said, "We don't know what the programming language of the future will look like, but we know it will be called FORTRAN."
- gnufx 6y ago
  Hoare said "I don’t know what the language of the year 2000 will look like, but I know it will be called Fortran". He also said "ALGOL 60 is alive and well and living in Fortran 90", which is a decent compliment from him.
  - madhadron 6y ago
    Ah, thank you.
anthk 6y ago
This. The OS I use dates back to BSD 4.4, which is a rewrite and rehasing on some OS which is about 50 years old. The audio plug is over 100 years old, and modern TTY's date back to what, 80 years? If it works, it works. Also, damn Calculus is over 200 years old. Or maybe 2000, depending if you compare it to the method of exhaustion or not.

chris_va 6y ago

(disclaimer: I work in a Climate&Energy R&D Lab) I don't entirely agree with the overall assertion of this article. The author has some valid points, but I think it misses the forest for the trees. TLDR: I think Fortran tooling and HPC clusters are a self-reinforcing local maximum. They are heavily optimized for each other, but at the cost of innovation and extensibility. For example, we'll never get a fully differentiable climate model in Fortran. The tooling does not exist, and there are not enough Fortran developers to make a serious dent in the tooling progress made outside of the HPC world. The MPI stacks these codes rely on are not great for hardware outside of a supercomputer, and Fortran codes basically are built around full interconnect. I have many PFLOPs at my disposal that I cannot use because these codes are too brittle without being entirely rewritten. At the end of the day, everything is a Turing machine, so you can technically do whatever you want in Fortran or any other language (or mix and match), but strategically staying in Fortran leaves a lot of resources on the table.

cbkeller 6y ago
Well Fortran was, notably, one of the first languages to have proper source-to-source autodiff (TAPENADE) [1-3], so it’s probably not impossible, though my choice for a fully differentiable climate model would personally be Julia, like the CliMA folks at Caltech [4]. [1] https://doi.org/10.1145/2450153.2450158 https://doi.org/10.1145/2450153.2450158 [2] http://www-tapenade.inria.fr:8080/tapenade/index.jsp http://www-tapenade.inria.fr:8080/tapenade/index.jsp [3] http://www-sop.inria.fr/ecuador/tapenade/distrib/README.html http://www-sop.inria.fr/ecuador/tapenade/distrib/README.html [4] https://clima.caltech.edu/ https://clima.caltech.edu/

tianlong 6y ago

These considerations are valid also in another fields such as in computational quantum physics/chemistry. Major software are written in Fortan and in C++. I work in the ML community now, after many years of quantum chemistry and when I say that I know Fortran people usually laugh :).

m463 6y ago

Has anyone LOOKED at fortran recently? Some excerpts from https://en.wikipedia.org/wiki/Fortran https://en.wikipedia.org/wiki/Fortran Fortran 90: - Ability to operate on arrays (or array sections) as a whole, thus greatly simplifying math and engineering computations. - whole, partial and masked array assignment statements and array expressions, such as X(1:N)=R(1:N)*COS(A(1:N)) Fortran 2003: - Object-oriented programming support: type extension and inheritance, polymorphism, dynamic type allocation, and type-bound procedures, providing complete support for abstract data types Fortran 2008: - Sub-modules—additional structuring facilities for modules; supersedes ISO/IEC TR 19767:2005 - Coarray Fortran—a parallel execution model - The DO CONCURRENT construct—for loop iterations with no interdependencies - The BLOCK construct—can contain declarations of objects with construct scope Fortran 2018: - Further interoperability with C

anthk 6y ago

BLAS uses Fortran I think, and Lapack. Good luck calling that slow. Another clueless JS hipster, maybe.

gnufx 6y ago
The reference BLAS in Fortran is indeed slow. I'm not aware of any tuned version in Fortran. It might be possible to re-write the BLIS structure in Fortran and get reasonable performance on, say, Haswell, but not on SKX, if we talk x86.
- anthk 6y ago
  >Tuned. Intel on HPCs.

TheRealKing 6y ago

For heavens sake, let's stop the discussion of Fortran array index starting at 1. In Fortran the starting index can be anything. A(-10:-5) is valid, A(-10:10) is valid, A(1:10) is valid, A(0:10) is valid. Choose what you want and do not complain about it again, please. No other language has this amazing capability.