The State of Fortran(arxiv.org)
arxiv.org
The State of Fortran
https://arxiv.org/abs/2203.15110
112 comments
For what it is worth - I write Fortran professionally (in some of the use cases you describe) and I doubt its usefulness.
The way I see it, Fortran exists today because of inertia, not because it still has technical superiority.
These mountains of Fortran code represent decades of investment and undocumented "features" that you could never code around during a rewrite.
And so today, new code is bolted on, with a prayer that nothing breaks, may god have mercy on your soul.
The way I see it, Fortran exists today because of inertia, not because it still has technical superiority.
These mountains of Fortran code represent decades of investment and undocumented "features" that you could never code around during a rewrite.
And so today, new code is bolted on, with a prayer that nothing breaks, may god have mercy on your soul.
Man, why is inertia considered a bad thing? "new code is bolted on, with a prayer that nothing breaks" is literally all of software development. How many times do things break because some fool decided we need to use js framework 2022.04.07 when 2022.03.05 worked fine but new, shiny etc thus break. "Old" does not mean broken automatically, people seriously need to excise this assumption in software development because it simply isn't true.
HPC administrator, researcher and scientific software developer here.
Inertia is not a bad thing, but a long living code evolves in strange ways, because of us, humans. First of all, programming languages and software design has a symbiotic relationship. They feed each other. Support for required patterns and new technology is added to languages, and designs are made in confines of language capabilities.
Moreover, technology changes with every generation. Hardware change, capabilities change, requirements change, designs and languages change. More importantly mindset change. So you're bolting modern designs over "vintage" designs. Inevitable shims get coded (sometimes implicitly), and thing get complicated, even with best documented designs and developers with well intentions. The code pushed down solidifies, knowledge fades, and documentation get lost unless it's bundled with the code repository.
As a result, legacy code becomes something of a monster, where developers don't want to see, touch, or work with.
My research was coded with C++11 in the beginning. If I want to modernize with C++14 or add new parts with C++14, these parts will probably look so different that it'll look like two different languages glued together with black magic. It's the same thing with long living FORTRAN code. Only with longer legacy.
The culture and dynamics around scientific and academic programming is different from both FOSS and commercial software. This needs to be taken into account.
Inertia is not a bad thing, but a long living code evolves in strange ways, because of us, humans. First of all, programming languages and software design has a symbiotic relationship. They feed each other. Support for required patterns and new technology is added to languages, and designs are made in confines of language capabilities.
Moreover, technology changes with every generation. Hardware change, capabilities change, requirements change, designs and languages change. More importantly mindset change. So you're bolting modern designs over "vintage" designs. Inevitable shims get coded (sometimes implicitly), and thing get complicated, even with best documented designs and developers with well intentions. The code pushed down solidifies, knowledge fades, and documentation get lost unless it's bundled with the code repository.
As a result, legacy code becomes something of a monster, where developers don't want to see, touch, or work with.
My research was coded with C++11 in the beginning. If I want to modernize with C++14 or add new parts with C++14, these parts will probably look so different that it'll look like two different languages glued together with black magic. It's the same thing with long living FORTRAN code. Only with longer legacy.
The culture and dynamics around scientific and academic programming is different from both FOSS and commercial software. This needs to be taken into account.
> The culture and dynamics around scientific and academic programming is different from both FOSS and commercial software. This needs to be taken into account.
I'm currently teaching modern scientific Python programming, if that's a thing.
You raise an excellent point, the software development life cycle is quite different in academia. Do you have resources in mind on that topic?
I was thinking of dividing academic code in 3 "Ps":
- Playground: throw-away scripts for data analysis, fast moving code where any rigidity slows the process. Internal use by a single researcher usually.
- Prototype: code that serves as a foundation to the above, or is reused frequently, but is otherwise not shared outside a research group.
- Product: code, often open source, that is shared with the community.
Most tutorial about "good coding practices" do not make distinctions between these three stages.
For Python, there are practices that work at any level: auto-formatting code and sorting imports, gradual typing. But things like tests, API documentation, dependency management only apply to steps 2 and/or 3.
I'm currently teaching modern scientific Python programming, if that's a thing.
You raise an excellent point, the software development life cycle is quite different in academia. Do you have resources in mind on that topic?
I was thinking of dividing academic code in 3 "Ps":
- Playground: throw-away scripts for data analysis, fast moving code where any rigidity slows the process. Internal use by a single researcher usually.
- Prototype: code that serves as a foundation to the above, or is reused frequently, but is otherwise not shared outside a research group.
- Product: code, often open source, that is shared with the community.
Most tutorial about "good coding practices" do not make distinctions between these three stages.
For Python, there are practices that work at any level: auto-formatting code and sorting imports, gradual typing. But things like tests, API documentation, dependency management only apply to steps 2 and/or 3.
Not only are software development life cycles different, but also the attitude to development. Which is not a surprise when in most cases, the output is not the software (or system), but research or learning; the code is merely a side effect.
With the increasing expectation that academic research results should be reproducible, there's really no such thing as throwaway "playground" or "prototype" code. Everything is potentially a "product".
Maybe add a fourth category.
- Petrified: code that's set in stone and everyone's to scared to touch in because "it works, but God knows how".
- Petrified: code that's set in stone and everyone's to scared to touch in because "it works, but God knows how".
Stage 3 does not always happen. There are a few remarkable counterexamples, but most research software does not usually finish taking the form a product.
In my experience, what happens is that some prototype works quite well and gets used in the next project. But the next project is building a new prototype, not improving the previous one. After a few projects, the person who wrote that first prototype already left the department, but there are people who depend on it to get results. If enough time passes, you will have some piece of legacy code that very few people can understand.
The problem with academia is that, while the prototype is an excellent topic for an article, the real product, a maintained (and maintainable) software project, is not. And getting funding in academia to do something of no academic interest (ie. that cannot be turned into a paper) is very difficult. If the software is of no interest to some industrial partner willing to spend money, that code will just keep moving between the USB drives of PhD students, probably branching into slightly different versions, until someone is brave enough to start working in a new prototype and the cycle starts again.
In my experience, what happens is that some prototype works quite well and gets used in the next project. But the next project is building a new prototype, not improving the previous one. After a few projects, the person who wrote that first prototype already left the department, but there are people who depend on it to get results. If enough time passes, you will have some piece of legacy code that very few people can understand.
The problem with academia is that, while the prototype is an excellent topic for an article, the real product, a maintained (and maintainable) software project, is not. And getting funding in academia to do something of no academic interest (ie. that cannot be turned into a paper) is very difficult. If the software is of no interest to some industrial partner willing to spend money, that code will just keep moving between the USB drives of PhD students, probably branching into slightly different versions, until someone is brave enough to start working in a new prototype and the cycle starts again.
Very perceptive comment, especially the last paragraph.
May be you don't realize it but still, the hidden hypothesis in your argument is once again "new/current is better." You say "mindset[s] change," again, that just comes with developing software in general. Your mindset changes when you make a web app, a system tool (like a driver), or scientific code. I have a different mindset when I knead the 30 some odd year old PIC code I have to manipulate every now and then than the few times I played around in js for personal projects and it's a different mindset when I write 6502 asm for another. The thing is you say a "different mindset" that is different from what is familiar to someone new to a codebase is an argument for why "inertia is an issue." There is an obvious and different solution to "rewrite the code" and it is "re-learn the code/old design." The only reason you opt for "rewrite the code" here I can imagine is some hidden bias towards a modern mindset.
I understand how code bases change and warp but it really is a push and pull for when you should abandon something vs. keeping it around. Moreover, the other alternative, learning to actually use old code and understand it in the mindset it was developed avoids the frankenstein-ization you refer to becase if people actually understood the old code, they can add to it in a way that meshes well with the existing code rather than it being a bolt-on. That said, I can understand if you inherit something that already has the bolt-ons such that you're not really responsible for that, and that can be harry, but really I don't really feel like that is something unique to computational science in the abstract. Bolt-ons are common across CS I feel like.
The main thing I am railing against and have been doing for a long time is the tendency for developers to have more on an emphasis on writing code as opposed to reading code that already works. In particular, taking time to understand so-called legacy code, learning to think in the way it was written, then modifying said code in a way idiosyncratic to it. Unironically, we focus way too much on creativity in CS. That sounds a bit funny but the fact it does already demonstrates the reality of that mindset's (ironically) strangehold on software in general. It's really funny because creativity is actually not that important for the majority of users of computers but is very much valued by developers in general because they develop computers for a living. On the other hand, something that works and is stable is actually something people don't even know they want but even better (or worse), they rely on or at least grow accustomed to given they bitch and moan once the familiar is broken often to fill some need of some developer to chase the new and shiny.
This is a long comment, but there is one last thing I'll touch on: one of the places where I do agree somewhat is new technology. For example, for people in modeling laser-plasmas (where I hail), people have still not really adopted GPUs even though that's all the rage (and has been for years already actually), because the main tools (PIC and MHD) do not map well to GPUs and the algorithms were developed with a large memory space accessible across a node assumed. There are efforts being made now but it's still considered hot shit for the most part. So, there is one place I'll grant you that it does require some willingness to "write more" so to speak, to be able to take advantage of new technologies. That said, "writing more" in this case still requires rather deep knowledge of the old codes and particularly why they made the choices they did in order to save yourself a few years of recreating the same mistakes they did (which btw, is literally what I see whenever people do attempt that sort of thing today).
I understand how code bases change and warp but it really is a push and pull for when you should abandon something vs. keeping it around. Moreover, the other alternative, learning to actually use old code and understand it in the mindset it was developed avoids the frankenstein-ization you refer to becase if people actually understood the old code, they can add to it in a way that meshes well with the existing code rather than it being a bolt-on. That said, I can understand if you inherit something that already has the bolt-ons such that you're not really responsible for that, and that can be harry, but really I don't really feel like that is something unique to computational science in the abstract. Bolt-ons are common across CS I feel like.
The main thing I am railing against and have been doing for a long time is the tendency for developers to have more on an emphasis on writing code as opposed to reading code that already works. In particular, taking time to understand so-called legacy code, learning to think in the way it was written, then modifying said code in a way idiosyncratic to it. Unironically, we focus way too much on creativity in CS. That sounds a bit funny but the fact it does already demonstrates the reality of that mindset's (ironically) strangehold on software in general. It's really funny because creativity is actually not that important for the majority of users of computers but is very much valued by developers in general because they develop computers for a living. On the other hand, something that works and is stable is actually something people don't even know they want but even better (or worse), they rely on or at least grow accustomed to given they bitch and moan once the familiar is broken often to fill some need of some developer to chase the new and shiny.
This is a long comment, but there is one last thing I'll touch on: one of the places where I do agree somewhat is new technology. For example, for people in modeling laser-plasmas (where I hail), people have still not really adopted GPUs even though that's all the rage (and has been for years already actually), because the main tools (PIC and MHD) do not map well to GPUs and the algorithms were developed with a large memory space accessible across a node assumed. There are efforts being made now but it's still considered hot shit for the most part. So, there is one place I'll grant you that it does require some willingness to "write more" so to speak, to be able to take advantage of new technologies. That said, "writing more" in this case still requires rather deep knowledge of the old codes and particularly why they made the choices they did in order to save yourself a few years of recreating the same mistakes they did (which btw, is literally what I see whenever people do attempt that sort of thing today).
I strongly suspect there is an preference-oscillation in coding languages that is similar to the one found in broader culture between serif and sans-serif fonts. Can't fix on what it would be though?
[deleted]
""Old" does not mean broken automatically, people seriously need to excise this assumption in software development because it simply isn't true."
My first language was Fortran. Whilst I've some lingering affection for the language and that I still use it occasionally I also use other languages, Lisp for instance. It's significantly different to Fortran so I reckon my comments below come from having a wider experience than just Fortran alone.
First, there are things about Fortran that I don't like and have never liked the main culprit being the obtuse formatting and I/O (I'd have altered it if I could!). I'm not alone, one of the reasons Kemeny and Kurtz invented BASIC was that with BASIC all you have to do to print is to use a simple 'Print' statement. I also agree that Fortran hasn't fully kept up with the times but that's understandable given its large and significant role in science and engineering (I shouldn't need to explain that). At least it's lost some of its more egregious points—for instance, the infamous 'GOTO' instruction has long been kaput (and so on).
However, criticizing Fortran isn't the thrust of my argument here, which is the ongoing need to use existing Fortran programs without the need to change them. There are many, many thousands of programs—mathematical and scientific subroutines, etc.—that have been developed over the past 70 or so years which have been shown to be debugged and highly reliable by the fact that they have been and are still used repeatedly to good effect in critical industries such as nuclear, space and civil engineering just to mention a few.
Translating and or rewriting these routines into more modern languages risks introducing errors and bugs, and whilst modern programmers would likely find this ascetically pleasing that ought to be their secondary consideration—the primary one of course being the correct operation of the program they're working on. Even if all that coding were translated successfully, we'd likely still have issues with different compilers interpreting the translated code in subtly different ways to the original Fortran ones, [as I mention below, authentication of the translated code and similarly the new compilers to meet necessary standards alone would be a nightmare].
In short, we cannot guarantee the translated routines will do exactly the same thing or behave in exactly the same way as they did under a native Fortran compiler—at least not without one hell of an effort!
As mentioned, the key issue for keeping this huge library of Fortran routines operational is that it is huge—truly vast (nearly 70 years is tied up in developing Fortran code/libraries across a multitude of disparate industries and endeavors). Moreover, much of it was programmed by scientists and engineers who had a different attitude to today's programmers in that their primary work involved working and rearranging atoms which is much harder than just recompiling the source upon discovery of an error.
In short, engineers and scientist were used to designing hardware that worked properly and reliably the first time—bridges falling down and nuclear reactors melting down the moment they are commissioned would have serious consequences that today's programmers will never experience; often, the first they know of a failure mode in their code is when it comes in from the field after it was supposedly deemed to work. Thus, this 'work-first-time' exactness attitude spilled over into early Fortran programs and has been the mainstay for much of the code written in the language since (it's a significant reason why so many of these programs have been so reliable). Remember, John Backus, Fortran's chief instigator, was trained as an engineer.
Ideally, it would be nice to see new intelligent compilers that could accurately compile all of Fortran's variants as well as other languages, Algol, COBOL, Ada, PL/I, etc. including C etc. in one package as that would allow easy reuse of old 'solid' code. Of course, this will never happen for a multitude of reasons, the first of which is that it would take years and years to fully standardize and authenticate any such compiler to full ANSI/ISO standards comparable to past Fortran ones (especially so when multiple languages are involved). Then there's the problem of who would do the programming (I'd reckon most of today's programmers would hate such work—they'd see it as much worse than writing 'hated' hardware drivers not to mention the need for them to maintain standards and endure rigid discipline across the length of the project—and that could be for quite some years.)
That brings us back to where we started. As noobermin said, old software isn't broken as is so often assumed, moreover for reasons stated, I contend that history has demonstrated that it's often much more reliable than much of today's new code.
For these reasons, I reckon Fortran is going to be around for much longer than many of us care to imagine. History has shown it has staying power whether we like it or not.
My first language was Fortran. Whilst I've some lingering affection for the language and that I still use it occasionally I also use other languages, Lisp for instance. It's significantly different to Fortran so I reckon my comments below come from having a wider experience than just Fortran alone.
First, there are things about Fortran that I don't like and have never liked the main culprit being the obtuse formatting and I/O (I'd have altered it if I could!). I'm not alone, one of the reasons Kemeny and Kurtz invented BASIC was that with BASIC all you have to do to print is to use a simple 'Print' statement. I also agree that Fortran hasn't fully kept up with the times but that's understandable given its large and significant role in science and engineering (I shouldn't need to explain that). At least it's lost some of its more egregious points—for instance, the infamous 'GOTO' instruction has long been kaput (and so on).
However, criticizing Fortran isn't the thrust of my argument here, which is the ongoing need to use existing Fortran programs without the need to change them. There are many, many thousands of programs—mathematical and scientific subroutines, etc.—that have been developed over the past 70 or so years which have been shown to be debugged and highly reliable by the fact that they have been and are still used repeatedly to good effect in critical industries such as nuclear, space and civil engineering just to mention a few.
Translating and or rewriting these routines into more modern languages risks introducing errors and bugs, and whilst modern programmers would likely find this ascetically pleasing that ought to be their secondary consideration—the primary one of course being the correct operation of the program they're working on. Even if all that coding were translated successfully, we'd likely still have issues with different compilers interpreting the translated code in subtly different ways to the original Fortran ones, [as I mention below, authentication of the translated code and similarly the new compilers to meet necessary standards alone would be a nightmare].
In short, we cannot guarantee the translated routines will do exactly the same thing or behave in exactly the same way as they did under a native Fortran compiler—at least not without one hell of an effort!
As mentioned, the key issue for keeping this huge library of Fortran routines operational is that it is huge—truly vast (nearly 70 years is tied up in developing Fortran code/libraries across a multitude of disparate industries and endeavors). Moreover, much of it was programmed by scientists and engineers who had a different attitude to today's programmers in that their primary work involved working and rearranging atoms which is much harder than just recompiling the source upon discovery of an error.
In short, engineers and scientist were used to designing hardware that worked properly and reliably the first time—bridges falling down and nuclear reactors melting down the moment they are commissioned would have serious consequences that today's programmers will never experience; often, the first they know of a failure mode in their code is when it comes in from the field after it was supposedly deemed to work. Thus, this 'work-first-time' exactness attitude spilled over into early Fortran programs and has been the mainstay for much of the code written in the language since (it's a significant reason why so many of these programs have been so reliable). Remember, John Backus, Fortran's chief instigator, was trained as an engineer.
Ideally, it would be nice to see new intelligent compilers that could accurately compile all of Fortran's variants as well as other languages, Algol, COBOL, Ada, PL/I, etc. including C etc. in one package as that would allow easy reuse of old 'solid' code. Of course, this will never happen for a multitude of reasons, the first of which is that it would take years and years to fully standardize and authenticate any such compiler to full ANSI/ISO standards comparable to past Fortran ones (especially so when multiple languages are involved). Then there's the problem of who would do the programming (I'd reckon most of today's programmers would hate such work—they'd see it as much worse than writing 'hated' hardware drivers not to mention the need for them to maintain standards and endure rigid discipline across the length of the project—and that could be for quite some years.)
That brings us back to where we started. As noobermin said, old software isn't broken as is so often assumed, moreover for reasons stated, I contend that history has demonstrated that it's often much more reliable than much of today's new code.
For these reasons, I reckon Fortran is going to be around for much longer than many of us care to imagine. History has shown it has staying power whether we like it or not.
The key advantage of fortran is that it doesn't allow pointer aliasing, which allows the compiler to vectorize more. Couple that with the typical fortran use cases and compiler vendors competing on performance by vectorizing more and more.
What you end up with is a language with a reputation for being faster for computation
What you end up with is a language with a reputation for being faster for computation
When C99 introduced the restrict keyword this argument fell apart.
But I can assure you, the vast majority of legacy Fortran is not vectorizable. At least not without a bit of refactoring.
Oh and did I mention, most of this legacy code was hand optimized for memory utilization. You see, back in the day 8k of memory was cutting edge HPC and about half that went to the OS and compiler. Well we all know, everything is a balancing act between time and space - the old timers traded time for space just to be able to do the computation at all on the hardware they had.
But I can assure you, the vast majority of legacy Fortran is not vectorizable. At least not without a bit of refactoring.
Oh and did I mention, most of this legacy code was hand optimized for memory utilization. You see, back in the day 8k of memory was cutting edge HPC and about half that went to the OS and compiler. Well we all know, everything is a balancing act between time and space - the old timers traded time for space just to be able to do the computation at all on the hardware they had.
> When C99 introduced the restrict keyword this argument fell apart.
1) Nobody puts "restrict" everywhere, and in C it can be very dangerous to do so unless you're exceedingly careful.
2) The fact that few codebases use it means it's riddled with compiler bugs even if you are exceedingly careful. Just look at how many times Rust has had to disable noalias due to LLVM bugs and regressions.
1) Nobody puts "restrict" everywhere, and in C it can be very dangerous to do so unless you're exceedingly careful.
2) The fact that few codebases use it means it's riddled with compiler bugs even if you are exceedingly careful. Just look at how many times Rust has had to disable noalias due to LLVM bugs and regressions.
Restrict is used where it matters.
Just because Fortran does the equivalent of implicitly using restrict everywhere does not mean the compiler actually statically checks for abuse. You can just as easily write bad pointer aliasing code in Fortran and depending on what optimization level you built with you may or may not experience memory corruption and/or segmentation fault at run time.
Just because Fortran does the equivalent of implicitly using restrict everywhere does not mean the compiler actually statically checks for abuse. You can just as easily write bad pointer aliasing code in Fortran and depending on what optimization level you built with you may or may not experience memory corruption and/or segmentation fault at run time.
AIUI, the only language in common use that has comprehensive static checks for their equivalent to 'restrict' is Rust. Not coincidentally, there's quite a bit of interest in Rust adoption for numerics-heavy and scientific codes, the traditional preserve of FORTRAN.
No it didn't, it only introduced yet another source of UB, when C "experts" forget to use it the way ISO C rightfully expects.
You seem to be operating under the assumption that the Fortran compiler will catch pointer aliasing. In fact major implementations of Fortran do not (for technical reasons).
So the standard just says "don't do it, LOL" but then you are able to write Fortran violating this. Which is how you end up with bugs that go away when you switch optimization levels.
So the standard just says "don't do it, LOL" but then you are able to write Fortran violating this. Which is how you end up with bugs that go away when you switch optimization levels.
You seem to be operating under the assumption that the C developers know how to use restrict, when in practice they don't, so it hasn't made the argument fell apart.
In fact, only C++ is able to confortably beat Fortran, despite not having official support for restrict, because of the stronger type system and compile type metaprogramming that offer optimization opportunities out of reach to C compilers.
Usually HPC places like CERN and Fermilab don't migrate their aginging Fortran code to C, rather C++.
In fact, only C++ is able to confortably beat Fortran, despite not having official support for restrict, because of the stronger type system and compile type metaprogramming that offer optimization opportunities out of reach to C compilers.
Usually HPC places like CERN and Fermilab don't migrate their aginging Fortran code to C, rather C++.
One of the people in my team has a PHD in weather forecast modelling and it was only a few hours ago we were talking about the Met Office having a decade(s ?) old Fotran core with lots of stuff bolted on.
Was the conclusion that decades old Fortran existing good or bad, likewise the bolt-ons? Ideally, if given a chance, what's the consensus of what you'd all like to do?
When we cannot re-make the things we made before is a sign of a slow decline.
It's really not. It is simply very expensive to build up experimental validation of simulation code rewritten in a new language, and much more expensive than the aesthetic value given by programmers who want new things. There's nothing magic about the old things, there's just an existing ecosystem which works which would involve a whole lot of effort to recreate and most people think they have better things to do.
QED. (What you're saying makes sense, I don't understand why anyone would disagree after considering the facts.)
More likely, a rewrite doesn't look good on a quarterly spreadsheet and "shockingly" code designed by Johnny Two-Shoes in the 60s that uses COOMON blocks both for internal storage as well as an API is incredibly difficult to test and thus incrementally modify. Bonus points for next to no documentation.
College software engineering textbooks that explain why global memory is generally a terrible design choice were written off the lessons learned from legacy Fortran.
College software engineering textbooks that explain why global memory is generally a terrible design choice were written off the lessons learned from legacy Fortran.
That's not to say the code quality is any good, only that it still runs and everyone has their reasons to avoid a rewrite.
True, the fact that it is still running says something, but not overmuch about whether it would be pleasant to maintain, extend or otherwise modify.
True, the fact that it is still running says something, but not overmuch about whether it would be pleasant to maintain, extend or otherwise modify.
But does “code quality” matter if all you need is a black box calculation that spits out the right answer every time, and has done so for the past 50 years?
Put all the damn goto statements in there you want, as long as I don’t have to look at at, great!
Put all the damn goto statements in there you want, as long as I don’t have to look at at, great!
If your code is performance critical, it absolutely matters. Most Fortran code is FORTRAN 77, and 2-20x slower than it could be because it was written for processors without vectorization, out of order execution, modern branch predictors, or any of the other hardware advances of the past 30 years. Modern compilers can mitigate this slightly, but the algorithms that old FORTRAN code use are fundamentally inefficient on modern hardware.
"Most Fortran code is FORTRAN 77"
Just curious, how do you know that? I would have thought many establishments would have moved on by now. That said, I've a few of my personal programs that still run on IV - no need to change them as they still work fine (but then they're not running under the auspices of some institution where updating has relevance).
I suppose a more relevant question would be what is the breakdown type of institution still using 77 - educational, research, government, commercial etc. (I know airline bookings and traffic systems used a lot of 77 until recently). I note from another poster CERN is using 95.
I'd reckon legacy systems would be more likely to be found in govt. and commercial and updated more likely in research. (I'd expect there'd be a large disparity between the different types of institutions.)
Just curious, how do you know that? I would have thought many establishments would have moved on by now. That said, I've a few of my personal programs that still run on IV - no need to change them as they still work fine (but then they're not running under the auspices of some institution where updating has relevance).
I suppose a more relevant question would be what is the breakdown type of institution still using 77 - educational, research, government, commercial etc. (I know airline bookings and traffic systems used a lot of 77 until recently). I note from another poster CERN is using 95.
I'd reckon legacy systems would be more likely to be found in govt. and commercial and updated more likely in research. (I'd expect there'd be a large disparity between the different types of institutions.)
I haven't done a survey, but from what I've seen, most establishments have moved on. They moved on to C++, python, and julia. Fortran is still fast, but it no longer is unambiguously the fastest, so you need a really specific reason to write code in a less expressive language. (There's a reason the Fortran people are writing their standard library in Python)
If you have not done a survey, then please do not make generic claims in a public forum about a whole ecosystem based on your limited personal observations. I understand you like Julia very much and that you are possibly paid by JuliaComputing to bash other languages in online forums, specifically Fortran here, but please keep your discussions factual.
For a non-exhaustive survey (an exhaustive one would be very difficult because there's a lot of software, and methodology is complicated):
100% of Fortran in scipy is 77 https://github.com/scipy/scipy/search?l=fortran&p=1
50% of Fortran in numpy is 77 https://github.com/numpy/numpy/search?l=fortran&p=1
ARPACK, ATLAS, LAPACK, ODEPACK, SLATEC, UMFPACK are all notable Fortran libraries that are still fortran77.
A search of github suggest that by repository, there are roughly, 150 f77, 450 f90, 180 f95, and less than 230 for fortran 2003, 2008 and 2018 combined (fortran 2018 is especially dire there are only 6 repos with over 10 stars). however, it's worth noting that github is a site is biased towards newer versions since it only became a relatively dominant platform in the past 10 years or so.
All in all, I think my initial statement is probably wrong by 1 version. The majority of Fortran appears to be f90 or older, and only about 1/5th of fortran code was written on a version of the language from this millennium.
While I do work for JuliaComputing, my posts on HackerNews in no way reflect the views of the company. I'm not sure why you think paying software engineers to bash languages would be an efficient use of resources.
50% of Fortran in numpy is 77 https://github.com/numpy/numpy/search?l=fortran&p=1
ARPACK, ATLAS, LAPACK, ODEPACK, SLATEC, UMFPACK are all notable Fortran libraries that are still fortran77.
A search of github suggest that by repository, there are roughly, 150 f77, 450 f90, 180 f95, and less than 230 for fortran 2003, 2008 and 2018 combined (fortran 2018 is especially dire there are only 6 repos with over 10 stars). however, it's worth noting that github is a site is biased towards newer versions since it only became a relatively dominant platform in the past 10 years or so.
All in all, I think my initial statement is probably wrong by 1 version. The majority of Fortran appears to be f90 or older, and only about 1/5th of fortran code was written on a version of the language from this millennium.
While I do work for JuliaComputing, my posts on HackerNews in no way reflect the views of the company. I'm not sure why you think paying software engineers to bash languages would be an efficient use of resources.
The statement "I do work for JuliaComputing" (which I predicted solely based on your writing style, generic to all JuliaComputing payees) fully explains the nature of your comments and arguments.
Regarding your argument: Counting GitHub repositories is the silliest way of gauging a language growth or decline. The C++ language has nearly 7000 C++11 repositories, only 1600 C++14, far fewer C++20 repositories. According to your flawed logic, C++ is now on life support. A thorough knowledge of a topic is essential before commenting on it or criticizing it as an expert in a public forum. Learn about the minor and major standard releases.
Right, thanks. That makes sense, especially julia. Trouble is I keep falling over Fortran in many unexpected places. What I've not thought to do in any rigorous way until now is to ask about the history of these Fortrans.
> vectorization, out of order execution, modern branch predictors
Two out of three of those are controversial because of Spectre. https://en.wikipedia.org/wiki/Spectre_(security_vulnerabilit...
Two out of three of those are controversial because of Spectre. https://en.wikipedia.org/wiki/Spectre_(security_vulnerabilit...
They might be "controversial", but they still are absolutely necessary. Modern CPUs typically execute around 3 operations per clock cycle. Without OOO and speculative execution, that drops to .3 (roughly). There's a reason no one is making cpus without them for anything even performance adjacent. Also, just because Fortran code was written without knowing about them, doesn't mean they don't still happen, the only difference is that the algorithms are bad.
When I was at CERN, the surviving Fortran code that I related to, was decent Fortran 95.
Fortran has certainly been very important but now people are building climate models faster in Julia and with better performance. Fortran used to be the only option for high performance numerical computing but that is no longer the case. For instance preliminary performance tests of BLAS rebuilt for Julia shows higher performance than the Fortran variants which have been tuned for decades.
Part of the reason Julia can do this is due to support for parametrized types and JIT compilation which I can make it possible to in-line a lot of code which you cannot inline with AOT compilation.
Part of the reason Julia can do this is due to support for parametrized types and JIT compilation which I can make it possible to in-line a lot of code which you cannot inline with AOT compilation.
Glad to see Julia is catching up. D language has beaten Fortran based BLAS library in the performance metrics for more than five years now [1].
[1] Numeric age for D: Mir GLAS is faster than OpenBLAS and Eigen:
http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/...
[1] Numeric age for D: Mir GLAS is faster than OpenBLAS and Eigen:
http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/...
For what it’s worth the nuclear power plant I worked at ran mostly on LabView. We compiled the code on PCs onto dedicated LabView boxes. No Fortran was ever used.
Now, as someone with experience with labview that is a horrifying thought...
I'd absolutely agree, it's truly worrying.
I say that as someone who has worked in nuclear safeguards.
I say that as someone who has worked in nuclear safeguards.
Agreed, we ran a small nuclear system 2KW. All the equipment was experimental. I can see the issues with Lavbiew on PCs plus hardware sucks, but there dedicated systems are actually really good and stable.
Yeah, right. As you'd know, the size of your system is immaterial when it comes to this stuff, the basic rules are essentially the same in that they all come under the treaty (it's highly unlikely your country isn't a signatory-there being very few that aren't).
In essence, that means the simplest approach is to use dedicated and or standardized systems (i.e.: in measurement/accounting) wherever possible then there's little or no argument when the inspectorate arrives. (From my comment you'll know my background.)
In essence, that means the simplest approach is to use dedicated and or standardized systems (i.e.: in measurement/accounting) wherever possible then there's little or no argument when the inspectorate arrives. (From my comment you'll know my background.)
> the nuclear power plant I worked at ran mostly on LabView
Jesus wept!
-Signed, a physicist with 20 years LabView and Fortran experience.
Jesus wept!
-Signed, a physicist with 20 years LabView and Fortran experience.
I know that modern Fortran is a thing but from my limited experience, it is being phased out. I work for an aeronautics company that has a lot of Fortran code: flight models, material calculations, etc... Some of it is maintained but I didn't see any new Fortran project, and most of the legacy Fortran code have been replaced by C++, Java, etc... as well as more specific tools like SCADE (which generates C code).
Same thing for ADA.
Same thing for ADA.
Modern Fortran is beautiful and I love coding in it.
However, my understanding is that its main focus is on array computations. Now with hierarchical data structures and graphs becoming ever pervasive, I wonder if Fortran will ever try to compete in this space (when these higher-order concepts are integrated into domains of Fortran's past dominance in numerical simulation).
However, my understanding is that its main focus is on array computations. Now with hierarchical data structures and graphs becoming ever pervasive, I wonder if Fortran will ever try to compete in this space (when these higher-order concepts are integrated into domains of Fortran's past dominance in numerical simulation).
Hierarchical data structures are bad for CPU caches, see, for example, references in [1] how various data-oriented programming techniques try to avoid them.
From that point of view Fortran may be even more relevant for high-performance computing now than even 10 years ago.
[1] https://en.m.wikipedia.org/wiki/Data-oriented_design
From that point of view Fortran may be even more relevant for high-performance computing now than even 10 years ago.
[1] https://en.m.wikipedia.org/wiki/Data-oriented_design
B-Trees are very much not bad for CPU caches,neither are tries. Generalizations like this are harmful.
Fortran is the ideal language for data-oriented programming. Ultimately that’s where performance is. I don’t see it trying to compete by creating a kind of graph-oriented language (besides pointers and somewhat barebones generics). You probably want a fancy higher-level language for this anyway.
It is evolving towards a great language for parallel HPC, integrating neatly both shared-memory and distributed computing in a very nice framework. Much better than the usual hodgepodge of OpenMP and MPI (or whatever API du jour NVIDIA or Intel happen to be pushing).
It is evolving towards a great language for parallel HPC, integrating neatly both shared-memory and distributed computing in a very nice framework. Much better than the usual hodgepodge of OpenMP and MPI (or whatever API du jour NVIDIA or Intel happen to be pushing).
Honestly, it really shouldn't, at least IMO. Where may be once it was used for other things, today it's essentially a DSL of some sort for the numerical computations you specify. It doesn't need to be used for a game engine (game engines can go ahead and call fortran code as they might).
As a comparison, I have to program in Fortran in my day job, and I really hate it. On the negative side, text handling is really horrible (even with the new variable length strings), there are very few good libraries outside of numerics, a lack of type-safe generic data structures (like C++'s STL), buggy compilers (my code has some horrific pointer hopping to work around gfortan's bugs), the C-Fortran interface is horrible to use and there's little good documentation on the language. The positive things are the multidimensional arrays and slicing, and the modules.
Graphs can certainly be modelled as matrices over different kinds of scalars. But I'm not sure how relevant this is to your use case.
What kind of editor support does Fortran have? I think a language is more than just a language as such, and the surrounding environment is at least as important if not more. I've used things like Mathematica, RStudio and Matlab, as well as Java IDEs, and these make all the difference.
We maintain a commercial, Fortran-specific IDE, Simply Fortran, that ships with the GNU Fortran compiler (at least on Windows and macOS): https://simplyfortran.com
It has many of the usual IDE expectations built in like autocomplete, project management, debugging, Git integration, etc. Our Windows distribution adds a few niceties like a Fortran-oriented (though basic) GUI library, a Windows-native coarray implementation (that doesn't use MPI), Windows-native OpenMP and threading, and a binary package manager for pre-built libraries.
We're decidedly a small player in a niche market, but I like to think Simply Fortran makes life easier for Fortran developers. Sorry for the self-promotion!
It has many of the usual IDE expectations built in like autocomplete, project management, debugging, Git integration, etc. Our Windows distribution adds a few niceties like a Fortran-oriented (though basic) GUI library, a Windows-native coarray implementation (that doesn't use MPI), Windows-native OpenMP and threading, and a binary package manager for pre-built libraries.
We're decidedly a small player in a niche market, but I like to think Simply Fortran makes life easier for Fortran developers. Sorry for the self-promotion!
This looks awesome!
Am.. am I about to teach myself Fortran?
Am.. am I about to teach myself Fortran?
Last I checked, you had to write out your program on paper, using the special Fortran coding forms. Then you just gave the written out forms to someone who would type out your codes at a keypunch and give you a deck of freshly punched cards, or you could take care of it yourself.
For anyone who wants to experience the first part of this process, here is a FORTRAN Coding Form (in caps because that's how it was spelled back then):
https://upload.wikimedia.org/wikipedia/commons/1/18/FortranC...
Print that in color on 8½x14" (legal size) paper and get to work!
Of course there were a few other steps in the programming process back then.
1. A Systems Analyst took business requirements and turned them into an overview diagram of the system structure.
2. A Programmer took those diagrams and drew detailed flowcharts. These included every "if" statement, every loop, every detail. They were in effect code, but in a diagram form. Don't forget your IBM Flowcharting Template! https://ids.si.edu/ids/deliveryService?id=NMAH-AHB2012q05389
3. A Coder read the programmer's flowcharts and wrote out the equivalent FORTRAN code on multiple pages of Coding Forms.
4. A Keypunch Operator read the Coder's forms and punched them onto cards, one card for each line of a Coding Form.
5. Finally we get to the High Priest of this operation. A Computer Operator - the only person allowed to touch the Computer! - ran your deck of cards through the machine and blessed you with a printout. Which was usually a core dump.
https://upload.wikimedia.org/wikipedia/commons/1/18/FortranC...
Print that in color on 8½x14" (legal size) paper and get to work!
Of course there were a few other steps in the programming process back then.
1. A Systems Analyst took business requirements and turned them into an overview diagram of the system structure.
2. A Programmer took those diagrams and drew detailed flowcharts. These included every "if" statement, every loop, every detail. They were in effect code, but in a diagram form. Don't forget your IBM Flowcharting Template! https://ids.si.edu/ids/deliveryService?id=NMAH-AHB2012q05389
3. A Coder read the programmer's flowcharts and wrote out the equivalent FORTRAN code on multiple pages of Coding Forms.
4. A Keypunch Operator read the Coder's forms and punched them onto cards, one card for each line of a Coding Form.
5. Finally we get to the High Priest of this operation. A Computer Operator - the only person allowed to touch the Computer! - ran your deck of cards through the machine and blessed you with a printout. Which was usually a core dump.
thx for this!
I learned Fortran with punch cards and a teletype. We would hand a program deck (a stack of cards) to the machine operator and in a few minutes our printed output and the program deck would appear in an alphabetized set of bins. The physical stack of cards was the only storage medium for the code.
Check your debug output, modify (or insert) a few cards and repeat.
Don't forget the JCL (job control language) on the first card. That is how you tell the mainframe what resources your code needs and how to run it. If you get that wrong nothing happens.
We were taught to draw a diagonal line across the top edge of the deck of cards so you could quickly put the deck back together correctly if it was dropped.
Check your debug output, modify (or insert) a few cards and repeat.
Don't forget the JCL (job control language) on the first card. That is how you tell the mainframe what resources your code needs and how to run it. If you get that wrong nothing happens.
We were taught to draw a diagonal line across the top edge of the deck of cards so you could quickly put the deck back together correctly if it was dropped.
It is entirely possible this person is telling the truth that this was the state of things the last time they checked. :)
Fortran was absolutely run on punch cards, which also informs some of the strangeness of its formatting, especially pre-fortran-90.
Fortran was absolutely run on punch cards, which also informs some of the strangeness of its formatting, especially pre-fortran-90.
I programmed FORTRAN on punch cards and on paper tape using a teletype, over an acoustically coupled modem, timesharing to a Univac 1103. Those were the days.
These two training videos from the Bell Labs Computing Centre are a very interesting insight into what it was like.
Part 1 https://www.youtube.com/watch?v=HMYiktO0D64
Part 2 https://www.youtube.com/watch?v=V9aVOIuKVUc
Part 1 https://www.youtube.com/watch?v=HMYiktO0D64
Part 2 https://www.youtube.com/watch?v=V9aVOIuKVUc
So... this is what Hell looks like...
Good timing for your question as there is a poll going on at the moment about editors used with Fortran, on the Fortran Lang community Discourse here: https://fortran-lang.discourse.group/t/code-editors-ides-use...
But the quick answer is that people programming in Fortran use the usual editors - Visual Studio Code, Emacs, Vim, CLion, etc.
But the quick answer is that people programming in Fortran use the usual editors - Visual Studio Code, Emacs, Vim, CLion, etc.
CLion supports Fortran via a plugin. I've used it a bit and it's fine.
https://www.jetbrains.com/help/clion/fortran-support.html
https://www.jetbrains.com/help/clion/fortran-support.html
I tend to use TextMate on Mac or SublimeText on other platforms. Fortran also is usually very close to C, and most standard debuggers like ten or lldb (even when LLVM had no Fortran front-end) can be used without problems. It’s a bit barebones compared to recent IDEs, sure. What I would like in particular is better refactoring and static analysis tools (though the lack of the latter is mitigated by the strong type system and some very good compilers like NAG). There is no real equivalent to RStudio or Matlab.
But... Matlab was originally written in FORTRAN ("easy access to... LINPACK and EISPACK..."). Written by Cleve Moler, distributed by Jim Kweeder. May 25, 1982. 7852 lines of FORTRAN 66 (for the version I have).
"With proper use of overlays, it is possible run the system on a minicomputer with only 32K bytes of memory." -- Cleve Moler
Fred Weigel
"With proper use of overlays, it is possible run the system on a minicomputer with only 32K bytes of memory." -- Cleve Moler
Fred Weigel
Sure, a lot of Matlab is in Fortran (and a lot of other software as well, though you would not know from the outside), but you don’t write in Fortran when using Matlab.
But, back in the day, if you wanted to add functions to MATLAB, you would add them in FORTRAN 66, and rebuild the MATLAB interpreter.
Microsoft BASIC-80 (around the same time) was written in assembler. You also don't write in assembler when using BASIC-80. But, BASIC-80 would be extended by assembler, in the same way that MATLAB would be extended by FORTRAN.
Microsoft BASIC-80 (around the same time) was written in assembler. You also don't write in assembler when using BASIC-80. But, BASIC-80 would be extended by assembler, in the same way that MATLAB would be extended by FORTRAN.
The tooling around Fortran is very similar to C. The debuggers are the same, you can typically use ctags of some sort for navigating between subroutines etc. across all files, and then you can add in a compiler-editor integration that checks for syntax errors at every save.
There are also a couple of Fortran REPLs out there, the most promising is probably LFortran which is only in alpha stage of development but has Jupyter integration and will be the next cool thing I think.
There are also a couple of Fortran REPLs out there, the most promising is probably LFortran which is only in alpha stage of development but has Jupyter integration and will be the next cool thing I think.
The Intel oneapi hpc toolkit (now free for commercial use too) has plugins for Visual Studio that are updated regularly. Full support in vs2019, about 90% works in vs2022. Of course you miss out on some of the most modern features like predictions that you get with copilot or the variant that Microsoft ships for C#, but it still has autocomplete, type hints, etc and a full featured debugger. There are also language server plugins available for vscode.
There have been Visual Studio plugins for commercial compilers since ages.
The fact that “The State of Fortran” is a paper on arXiv instead of a blog post actually says a lot about the state of Fortran.
What do you mean? It’s a paper written by several people on the standard committee of who contributed to the draft standard, on which blog would they put it?
Traditionally, these things were published in ACM SIGPLAN Fortran Forum (or on NAG’s servers for historical reasons). Arxiv is really natural, given the direction scientific and technical publishing is taking. This is a heavy duty language used by scientists and people like mechanical and nuclear engineers. Not the latest JavaScript framework or full stack doodad from Google.
Traditionally, these things were published in ACM SIGPLAN Fortran Forum (or on NAG’s servers for historical reasons). Arxiv is really natural, given the direction scientific and technical publishing is taking. This is a heavy duty language used by scientists and people like mechanical and nuclear engineers. Not the latest JavaScript framework or full stack doodad from Google.
This only speaks to the academic nature of Fortran, and there's nothing wrong about it.
The paper is published and available in early access in IEEE CiSE: https://ieeexplore.ieee.org/document/9736688
Oh yeah, a blog. Really keeping up with the times there compared to a paper.
I read that as "with all the good and bad that implies". That others didn't... well that's Fortran for you. Or maybe just hackernews.
I didn't even consider it in a good light because it was posted on this site, yes. If it was made positively, I apologize to the OP.
Yeah, I didn't mean it pejoratively, just that it's an indicator that the Fortran community is a very different scene from what you might find around other programming languages that are typically discussed here.
What value does your suggestion have here? I think you might be placing way too much value on a blog post.
Indeed, it isn't something that is only cool for a month or to be embraced by magpie developers.
Very interesting paper! It's cool to see that Fortran is still evolving. I've been considering learning it (when I have the time) because of its use for numerical computations and parallel processing. I feel like there's been a big push towards general-purpose languages like C++. However, I'd love to get a better feel for what it's like to program in a language specifically designed for your use case. The closest I've experienced is MatLab, but I feel like MatLab is designed more for scientists and engineers who need to perform some calculations but don't want to actually learn how to program, not for professional programmers working on scientific computation.
I don't think there's much in Fortran that's still unique or "specifically designed" for numerics compute. General purpose languages reached parity with Fortran a long time ago. And "general purpose" typically wins anyway because it has the larger and more diverse ecosystem.
Most of them did not reach parity, at least not in performance. The fast languages are C, C++, Fortran, and Julia. Those are the only ones used for teraflop computing. Fortran is a great tool for scientific computing, but for new projects, where you are not extending an existing code base, Julia will be much more fun in every way.
I don't think Julia belongs into the same list as C++, C and Fortran. It is true that for some algorithms it is almost the same speed as C++ out of the box, but for many others it is still factors of 10s or 100s of. Also it often requires significant tweaking to get to it's best performance (e.g. don't use abstract types), so it is almost like saying Python is the a fast language, because you can use Cython or Pythran. I really wish Julia fans would stop overstating the language capabilities, it really does a disservice to an otherwise great language.
I was talking about reality: https://www.hpcwire.com/off-the-wire/julia-joins-petaflop-cl...
Nothing overstated; just the circumstance in the real world that these four languages are the only ones used in the most demanding HPC.
C and Fortran are also not as fast as they could be if you use them incorrectly. Using concrete types is not “significant tweaking”.
Nothing overstated; just the circumstance in the real world that these four languages are the only ones used in the most demanding HPC.
C and Fortran are also not as fast as they could be if you use them incorrectly. Using concrete types is not “significant tweaking”.
this is just false. you can not find reasonably well written Julia code that runs 10x slower than equivalent fortran.
https://jochenschroeder.com/blog/articles/DSP_with_Python2/
There the "naive" Julia code, simply implementing the code like I would in Fortran is a factor of 10 or 15 slower than the optimised cython version (which would be the same as a regular C version), the optimised Julia version is still a factor of 5 slower than the cython and pythran version. Can you show me how to optimise it so that Julia performs on par with pythran or cython?
There the "naive" Julia code, simply implementing the code like I would in Fortran is a factor of 10 or 15 slower than the optimised cython version (which would be the same as a regular C version), the optimised Julia version is still a factor of 5 slower than the cython and pythran version. Can you show me how to optimise it so that Julia performs on par with pythran or cython?
The naive Julia code made a few pretty fundamental mistakes (Complex vs Complex{Float64}, and row vs column major). The following is non-optimized Julia code that is roughly 6x faster (and much simpler) than the "optimized" code in the blogpost. Some further optimizations would give another 2-4x over this (like using StaticArrays), but I'll leave that as an exercise for the reader.
apply_filter(x, y) = vec(y)' \* vec(x)
function cma!(wxy, E, mu, R, os, ntaps)
L, pols = size(E)
N = (L ÷ os ÷ ntaps - 1) \* ntaps # ÷ or div are integer division
err = similar(E) # allocate array without initializing its values
@inbounds for k in axes(E, 2) # avoid assuming 1-based arrays. Just need a single inbounds macro call
@views for i in 1:N # everything in this block is a view
X = E[i*os-1:i*os+ntaps-2, :]
Xest = apply_filter(X, wxy[:,:, k])
err[i,k] = (R - abs2(Xest)) \* Xest # abs2 avoids needless extra work
wxy[:,:,k] .+= (mu \* conj(err[i,k])) .\* X # remember the dots!
end
end
return wxy, err # note order of returns, seems more idiomatic
endDepends on your needs. Sometimes you just need a hammer. Michael Wirth had a few comments about Julia recently: https://craftofcoding.wordpress.com/2022/03/14/why-i-have-gi...
Seems highly subjective and not in line with the experiences a lot of the rest of us have. Stuff just suddenly breaking in old code with new compiler?!
No, that is not a common thing post Julia v1.0.
A lot of newer libraries are not well documented in Julia, but the core stuff is much better documented than Python IMHO. So his view on Julia documentation lacks nuance. It is both good and bad depending on what you look at.
The post talks about the complexity if importing stuff with using and include. Yes, if you start from scratch it is more complex, but the benefit is that it scales better. I have helped compete beginners with Julia who had totally given up on Python due to the complexity of package management, modules and environments. Julia has a beautiful solution to this which is far easier to get right and manage.
A novice will find it easier to import packages they want to use with Julia compared to Python. But very often people evaluating this stuff are experienced Python developers and they don’t see the Python hassle easily. If you take somebody who is a beginner in both languages then experienced will be quite different.
The “multi paradigm” comment makes zero sense. Sure Julia is multi paradigm but it is far more streamlined than the common OOP-functional mess you see in other mainstream languages today such as Python , Java, C#, Swift.
In Julia it is all functions. You don’t distinguish between free functions and methods. For a beginner this is much easier to deal with.
No, that is not a common thing post Julia v1.0.
A lot of newer libraries are not well documented in Julia, but the core stuff is much better documented than Python IMHO. So his view on Julia documentation lacks nuance. It is both good and bad depending on what you look at.
The post talks about the complexity if importing stuff with using and include. Yes, if you start from scratch it is more complex, but the benefit is that it scales better. I have helped compete beginners with Julia who had totally given up on Python due to the complexity of package management, modules and environments. Julia has a beautiful solution to this which is far easier to get right and manage.
A novice will find it easier to import packages they want to use with Julia compared to Python. But very often people evaluating this stuff are experienced Python developers and they don’t see the Python hassle easily. If you take somebody who is a beginner in both languages then experienced will be quite different.
The “multi paradigm” comment makes zero sense. Sure Julia is multi paradigm but it is far more streamlined than the common OOP-functional mess you see in other mainstream languages today such as Python , Java, C#, Swift.
In Julia it is all functions. You don’t distinguish between free functions and methods. For a beginner this is much easier to deal with.
These comments seem out of date. There hasn’t been an issue, really, with breaking code for quite a while, since 1.0. They also show a lack of understanding in some respects, for example complaining about the hello world memory usage. Running a Julia program in the usual way loads the runtime.
For another take, Jack Dongarra was just awarded 2021 ACM Turing prize. He’s the creative force behind LINPACK and BLAS, and says that Julia is a good candidate for the “next computing paradigm”: https://www.zdnet.com/article/jack-dongarra-who-made-superco...
For another take, Jack Dongarra was just awarded 2021 ACM Turing prize. He’s the creative force behind LINPACK and BLAS, and says that Julia is a good candidate for the “next computing paradigm”: https://www.zdnet.com/article/jack-dongarra-who-made-superco...
Some of the comments (in the original link in your parent comment) are pretty weird:
> I sometimes wish [Julia] had just appeared one day as version 1, and made periodic updates every year or three.
> Its “multi-paradigm” nature. Yeah, I know other languages have this too, but it does tend to bloat a language.
And some are just funny:
> The language is not stable, and by that I mean it seems to have a lot of bugs [links to github issues with label:bug]. You can’t really call something that has bugs stable.
> I sometimes wish [Julia] had just appeared one day as version 1, and made periodic updates every year or three.
> Its “multi-paradigm” nature. Yeah, I know other languages have this too, but it does tend to bloat a language.
And some are just funny:
> The language is not stable, and by that I mean it seems to have a lot of bugs [links to github issues with label:bug]. You can’t really call something that has bugs stable.
Yeah. Of course there are bugs, but none of them are serious. Julia is still a young language, but it’s rock solid and used in high stakes, high performance computing in industry, government, and academia. Like I said, there are only four high-level languages that can perform at this level. Julia is certainly the most advanced and interesting of these, and, yes, it’s just a lot of fun to use.
If only Julia didn't index arrays starting from 1, rather than the more natural 0.
Sadly, Fortran made the same mistake, which prevented it from seeing any significant adoption in science or engineering.
The strengths of Matlab is that it's a domain-specific glue language with a domain-specific interactive environment. It's great if the benefits to you are worth the specificity and investment. Otherwise, something like Python might suit your needs better.
Either way, there's still often at least some native code you have to write and wrap. That's where a professional programmer might get involved. But probably more often than not, it's the engineers and scientists themselves.
Either way, there's still often at least some native code you have to write and wrap. That's where a professional programmer might get involved. But probably more often than not, it's the engineers and scientists themselves.
Are things like higher order functions and closures relevant features for Fortran programmers? This is an open-ended question.
[edit] Just to be clear, I don't think Fortran has these.
[edit] Just to be clear, I don't think Fortran has these.
It's limited. You can pass functions as arguments to other functions. You can't return a function as a function result.
I was asking whether these are worth having in a future version.
Oops, I missed that. I would enjoy this feature but I think it's unlikely to be considered by the committee. As far as I'm aware it hasn't been discussed.
Specifically, Fortran's type system isn't nearly advanced enough to usefully support this type of feature well. Higher order functions are really useful, and if you want them, you should use a different language.
Technically, all programming languages are constrained by what a machine can do (the cpu architecture), to me all programming languages are transpilers, just chose the language that fit best your usecase, and that will allow you to write correct code easly, but always keep in mind that regardless of the language you’re using, you’re still constrained by same machine architecture,
I've always liked Fortran - one big project I wrote in Fortran 77 was an Intel 8080 simulator that was used for teaching at the Polytechnic I worked for. The original code was on a Dec10, but I ported it to a VAX and an IBM 4381 in a couple of days.
It's an easy language to get to grips with, but the users somewhat less so. At one point doing consultancy, I came across people declaring variables like I1,I2,I3,I4 to IN where N was a large number.
I asked "why?" and they said "we might need them" - Fortran programmers will see at least two reasons why this is daft.
It's an easy language to get to grips with, but the users somewhat less so. At one point doing consultancy, I came across people declaring variables like I1,I2,I3,I4 to IN where N was a large number.
I asked "why?" and they said "we might need them" - Fortran programmers will see at least two reasons why this is daft.
OpenWatcom Fortran: http://www.openwatcom.org/
Generics are necessary to bring performant data structures to Fortran, and yet they are nowhere near Go's generics.
For the usual naysayers doubting Fortran's place in a modern world: whenever you are reading or watching a weather forecast, that's decades of Fortran staring at you. Whenever you drive past a nuclear power plant, or an airbase with 'igloos', remember that nuclear safety codes run on Fortran.
[0] https://github.com/j3-fortran/generics