Is Fortran “A Dead Language”? (2022)
cpufun.substack.com
cpufun.substack.com
On the plus side, Fortran has more actively developed implementations than any other language. It is critical to some of the most important applications that exist. One can write code in the portable subset of Fortran and extract very high performance from very expensive HPC systems over many generations of processor and systems architecture.
On the down side, advancement of the language has become moribund -- the last major standard was in 2008 and the two revisions since then have been minor. The standards committee creates new features from whole cloth without prototyping them, and without fixing the bugs in the spec when bugs are discovered eventually by implementors. There has been no standard public test suite since F'77, so implementations vary. There are highly portable features that are not standard and there are standard features now that are not portable.
I'm working hard to try to improve this situation on the compiler side.
Secondarily, Fortran could benefit from modern educational materials, public test suites, effective responses to misinformation, and better discussion sites.
Respectfully, I'm pretty sceptical of this. Do you have a source?
I'd expect C to easily beat Fortran here. There's a C compiler (or several) for essentially every platform, as C is king for embedded work.
For me this is a measure of maturity. Changing a language every year is a sign of immaturity.
Pretty likely that’s the case with COBOL, definitely Algol, PL/1, Pascal, and Prolog.
Though uncommon or domain specific, not the case with APL (well J), Common Lisp, Forth, or Haskell.
I think there’s more new code being written in FORTRAN these days than in those last four combined.
It pains me to call CommonLisp obscure or uncommon because I used it heavily for a long time, but that’s the tough truth. It’s funny to think that one major criticism at the time was “its standard library is too massive” and now “its standard library is too small”.
I don’t remember anyone even thinking such a thing about Fortran, perhaps because standard library didn’t really mean anything for Fortran and because there have been tons of 3P Fortran libraries in the PD since before I was born.
WHAT'S WRONG WITH THIS? AN APOSTROPHE IS MISSING.On the other side... not sure how many newbies learn Pascal these days, though.
You also wouldn't call the newer invented languages like Esperanto dead, and yet there's more people who know and can speak Latin (using one of the modern pronunciations)...
Dead languages aren't those who aren't being spoken or used anymore, it's those that have no native speakers. It's not something that's in any way compatible with programming languages.
For a second there I thought we were still talking about Pascal! I'd wager it should be...
They had a major release to their most popular IDE just a few weeks ago[2].
A lot of these projects built with FP aren't as visible in the HN community, because they related to different hobbyist fields, aren't keystone components in the startup ecosystem etc. But they for sure exist.
[0] https://gitlab.com/freepascal.org/fpc/source/activity [1] https://github.com/crystal-lang/crystal/activity [2] https://forum.lazarus.freepascal.org/index.php/topic,65631.0...
Perl is seeing a strong decline and I think it will join the dead group in a few decades.
A shame - I much prefer its take on a versatile, unixy scripting language.
Much has been done to keep it alive - the comprehensive book Modern Perl, and the well-integrated Mojolicious web framework. But it doesn't seem to be enough. I'm the only one in my circles and age range who knows it, everyone else would reach for Python, shell or even JavaScript.
The rise of Go as a sysadmin/devops tools language has also probably hurt Perl quite a bit.
These days, (the more friendly) Linux desktop distributions are about as easy to install as Windows; about as easy to use as Windows; and about as maintainable by a novice user as Windows.
Unless you're referring to Android/Linux or ChromeOS/Linux, instead of GNU/Linux.
It's way better than in the 2000s when I started to use Linux.
If it ain't broke, don't fix it.
Yes it may take more effort to rewrite it natively now into whichever language the latex compiler is written in otherwise, the real braindead decision was not starting out that way. I mean shit, a modern equivalent would be of having to install python to use rustc or something.
It is everywhere. About the only case where you’d need that is on Windows but then if you are installing LaTeX on Windows getting Perl is a tiny bit of the complexity of the whole thing.
> A site must be up to host downloads for this prehistoric thing, and those binaries must be built, tested, and kept up to date by someone who might one day just vanish once they become bored of thanklessly maintaining a holy relic.
It’s not any more prehistoric than emacs, bash, or GCC; its latest version was published about a month ago. The CPAN is perfectly able to handle downloads. And it’s going to be in the repositories of all Linux distributions for the foreseeable future, considering how many tools depend on it. It is under active development; I don’t know where you got the idea that it was one guy in his basement doing it.
> Yes it may take more effort to rewrite it natively now into whichever language the latex compiler is written in otherwise, the real braindead decision was not starting out that way.
The real braindead decision is to jump on every language du jour just because. There is an optimum and I am sure at some point it will get rewritten in something else (see lualatex for example), but we cannot rewrite everything that works from the ground up every time a new shiny language shows up. Latex does not rust but I am sure at some point someone will find a clever pun and there’ll be a Show HN about it. In the meantime raging because a bit of software use some random language is not very productive or helpful.
> I mean shit, a modern equivalent would be of having to install python to use rustc or something.
From my experience rustc is not easier to install on Windows than Perl. On Linux it does not matter as everything is in the repos anyway.
(My guess is that people don't normally compile latex locally these days -- they do that on Overleaf -- and those who do use are old-school, hardcore users and they either use Linux or Mac)
I can't see why is ridiculous if it works
Perl like all the other languages that are heavily used aren't going to be going anywhere. They're used in legacy code. However, the original comment had a definition. Which says nobody would use it to start a new project. Talking about currently maintained projects doesn't really change the fact it doesn't seem anyone is using it for new projects.
> I think the meaningful definition of “dead language” is “nobody will begin a new code base in it any more, except as a hobby or research project”.
Pascal has its niceties, especially enabling one-pass compilation and pretty clear code. It's neither overcomplicated like Ada nor relatively unknown like Modula-3.
Given that humans don't have anything resembling well-defined knowledge I'm somewhat confused why this keeps coming up as something desirable.
COBOL and PL/I are still pretty alive for anyone working today on IBM and Unisys mainframes and microcomputers, regardless of bug fixes or new features.
Are they alive by gumby's definition of alive? Is anyone beginning new codebases in COBOL or PL/I, even on mainframes?
Brown field development moves much more consulting money per year than green field development.
There might be stuff written COBOL, except they're never gonna share it with you, cause its far too important to the fight over the $100 trillion stock markets.
I personally know and like Fortran in its modern form, at least within its little niche. But the ability to maintain these codes long term is really important and it's tough to see that being viable with the supply of professional-level developers withering to nothing.
Hell my sister (print sales) joined a new firm and she had to spend six weeks in an intense classroom style training program the company ran to get new staff prepared for the nuances of their product.
It seems straightforward to setup a Fortran internal bootcamp for experienced developers at these massive legacy institutions, worth the upfront investment...no?
Of course you could make the case for even more modern languages like Rust etc as well, but the national labs are still on the conservative side when making decisions for their big projects. C++ does hit a nice sweet spot in terms of performance, features, and longevity despite the warts.
If you go into such a bootcamp as a fresh grad, you basically pigeonhole yourself into working in that niche forever. You would have a massive setback when switching jobs compared to taking a bogstandard Java job or whatever.
You're also wrong about the setback and being stuck in that niche. Once you learn the first language, more likely than not you'll have opportunities to continue to grow and develop in the role and learn new things. Most people are pretty adaptable.
Numpy took inspiration from Fortran and MATLAB. Most scientific computing libraries use Lapack and BLAS libraries under the hood (which were written in Fortran).
Honestly, I think if Fortran had a few intuitive higher order abstractions/libraries - one wouldn’t need to mess around with C++. And now thinking more about it - it would be very cool to have a Numpy to Fortran transpiler.
Do you mean Python like easy syntax or do you mean Python like extensive std library?
Never used Fortran but really curious to understand whether Fortran has good standard library support to try my hand at it. I've been doing Go and Python mostly and willing to learn one more language now and I'm trying to decide if it should be Fortran!
Can you write a parser in it? Sure, but it's going to be painful dealing with strings. Can you write a web server? Yes, but you'd have to link to a C library that exposes the kernel TCP/IP interface to Fortran. And so, on.
So, essentially it would be like using C without a libc: it's doable, but it doesn't really make sense.
Nonetheless, Fortran has built-in support for N-dimensional arrays, with vectorised operations (including custom functions), so the experience is pretty similar to Numpy.
From the numpy website:
NumPy brings the computational power of languages like C and Fortran to Python, a language much easier to learn and use.There are libraries that may not be "standard" (that is, included in the standard) but are standardly available on Fortran. You need a matrix solver that will efficiently handle large, sparse matrices of complex variables, that will not degrade when faced with a stiff problem? Fortran has one of those. You can get it on pretty much any Fortran installation. It's solid, stable, and there's decades of experience with using it.
So, from that perspective, Fortran has a huge library. For numeric algorithms, virtually anything you want, it has.
Although I would say the "easy syntax" mostly applies to numerical code only, i.e. numpy code and the same computations in fortran would look very similar since fortran has similar syntax for vector-based computations, something that e.g. C does not have at all.
[1] https://doku.lrz.de/programming-with-fortran-10746212.html [2] https://doku.lrz.de/prace-course-advanced-fortran-topics-107... [3] https://www.intel.com/content/www/us/en/developer/articles/r...
If you do scientific computing, the fortran experience is much better than python's. You never feel out of place. Multi-dimensional arrays of floats are a native type, loops are fast, and the system is extremely stable.
What does python offer you? Lists, dictionaries, strings (none of which is of any use to scientific computing) and a plethora of slightly incompatible external libraries for dealing with matrices. Worse, there's no hope [0] that your algorithms based in numpy/scipy/numba/tensorflow/torch/jax will run unchanged in a decade, not to say in 50 years.
> What does python offer you? Lists, dictionaries, strings (none of which is of any use to scientific computing)
pandas/numpy/scipy/etc, so basically you get a blas/la pack equivalent, with a R/matlab feel.
> there's no hope that your algorithms [...] will run unchanged in a decade, not to say in 50 years.
Very few people care about that.
Did you work in HFT? I would be very surprised if they used Python for that, and almost equally surprised if they all dismissed Fortran as an option.
Besides the things you named, quants also use Excell (of course) but probably less known is K, which is an APL type language
Even that is disappearing. It was common practice even 10 years ago to use MKL as backend.
> Did you work in HFT?
Yes, I've done (and still do) HFT and mid freq since around 15 years.
> I would be very surprised if they used Python for that
Surprise!
Nobody would dare do any heavy computation in e.g. C++ or Fortran or Cobol. It's just too unpractical, and slow to develop.
You calibrate your models in Python/pandas/... , offline on historical data, and just use the prebuilt model to make the real-time prediction in C++, which doesn't involve much more than simple linear algebra.
I would estimate conservatively that 80% of quants use Python, in both HFT and mid freq. There should be some niche where they use matlab, R, kdb or stata, but that's definitely a small fraction.
Sorry I just saw this. And what do you think MKL does?
Python is very widely used for prototyping and there's nothing anyone can do about it. In production the algos would be implemented in Cpp though. I'm merely stating a fact, not here to argue about anything. Raw K is almost never used but there's a lot of Q, depending on the shop.
I never saw any Fortran in my time at Bloomberg in the 2010s but allegedly there was still a lot of it running in the nether regions.
Just as you haven't experienced Fortran, there are several areas in science that have not experienced C++/Python, and rely on Fortran.
Care to elaborate on why this wouldn't be the case?
As far as I can see, half of my desk is ex CNRS/CERN/CEA/... , the other half is the top brightest PhDs and engineers. When I look at weather forecast models, or biological DNA white papers, I don't see much difference in terms of scientific process or category of problem than what we see in quantitative finance.
It may be sad, but the truth is finance phagocytates an immense chunk of the scientific community,abd it provides. There are interesting and hard problems to solve, virtually unlimited compute resources, etc.
Most top quant HF have yearly double digit million dollar infrastructure bills, compute and storage clusters rivaling or surpassing academic ones, dedicated hardware manufacturers, etc.
It's just not what people consider as "science" :-)
My point is that branch of HPC developed somewhat independently of most of other science disciplines. It's also relatively newer, so it doesn't rely heavily on legacy code from the 70's/80's. Generally, newer disciplines (computational biology, modern ML, etc) don't use Fortran. Older stuff (physics, electromagnetics, most engineering, etc) are full of Fortran, and continue to be.
While it may be true that the absolute number of people involved is small compared to the wider tech industry, long-term code reproducibility is critically important for engineering-heavy industries with long-lived, high consequence physical assets. Think aerospace, nuclear, petrochemical, electrical, and other civil infrastructure. If something in the environment changes and you need to re-analyze the performance of that asset to ensure safety & reliability under the new conditions, the first thing you do is re-run the benchmark cases to verify the answers didn't change from the last time you ran it. If they did, it throws your entire basis for design into question unless you can conclusively resolve the inconsistency.
In the general population, probably. There is quite a large overlap with people doing HPC and scientific computing in general, however.
Their dynamic nature makes them much better at exploratory programming compared to Fortran though.
For people whose needs are "I want to write a weather forecasting simulator, it needs to simulate very efficiently, we're modelling immutable physical laws so this code will still be good in several decades" then absolutely.
OTOH for people whose needs are "I need to do some ad-hoc analysis on this CSV of experimental results, I gotta rush out a paper to not get scooped but nobody's going to build on this or use it again" or "I need to do a corporate data science project to forecast demand for this upcoming superhero movie based on social media buzz" - FORTRAN probably isn't the best choice.
Unless you happen to already be such a master of square pegs that you're comfortable and productive at fitting them into round holes :)
The main offering of python is bindings and easy glue to pretty much any data source/sink imaginable.
Disagree on this one. In my experience, the computational kernels of our newer scientific & engineering codes (Fortran or C++) are almost never invoked as standalone applications, and are instead embedded within much more complex workflows that are orchestrated with a Python API or Java application. The string handling, data containers, and support for standard file formats in these higher level languages are indispensable at this level, and add negligible overhead compared to the computational expense of the main solvers. Yes, these things are more ephemeral, but they are also more interchangeable. Confining them to a higher abstraction layer lets you more cleanly decouple this stuff from the essential numerical parts of the code.
The historical lack of support for these basic amenities in Fortran (and the C-family to a lesser extent) has resulted in the need to maintain innumerable ad-hoc I/O formats, home-rolled nonstandard parsers, and other bizarre, Rube Goldberg-like abuses of the language. Since the original developers of these legacy codes were scientists and engineers first, and developers second, these constructs inevitably wind up being tightly coupled to a larger, organization-spanning workflow whose input-output mapping has remained bitwise identical for three decades, and must continue to do so for just as many more.
Higher-level languages like Python have greatly alleviated this nightmare, at least on a go-forward basis.
Slicing: yes.
Broadcasting: I think only so, that you can operate on arrays by scalars, the scalar gets broadcasted.
a = 5
b = np.array([1, 2, 3])
a + b
>>> array([6, 7, 8])
This is very natural, and consistent with standard mathematical notation. It's an abuse of notation so common that is barely ever mentioned in elementary mathematics. For example, when you work with functions f:R→R, like f:x↦3x², it is common to denote constants by their value. Thus you write 7 instead of x↦7. Then you can write simply f+7, where f is a function and 7 is a value, and everybody understands what you mean. No need to write ridiculously correct stuff like f+(x↦7) .
Broadcasting with arrays is very natural if you interpret an array as a function of its indices. It is exactly the same thing as above!
I second that we should be using APL anyways.
Which mathematical notation? One of the first things a student of linear algebra gets taught is that you cant add scalars to vectors. The example you gave is not what is taught in most math classes, and seems weird to everyone unless you come from Bourbaki camp.
> Broadcasting with arrays is very natural if you interpret an array as a function of its indices. It is exactly the same thing as above!
But an array is just a contiguous data structure, not a function of its indicies.
I meant this. Very few people look at a number 7 and think of it as a constant function
When you do signal processing, you pretty much interpret 1d arrays as functions of time, 2d arrays as functions on the plane, etc. In that case, it is very natural.
If I have an array "A" that represents an image, I can change the britghtness and contrast of the image by doing an operation like "B = α*A + β". This notation requires broadcasting because β is a constant, not an array (or, equivalently, a function).
But you dont write it like this in linear algebra. You write
B = αA + b
B = α*A + β
B(t) = α*A(t) + β
What exactly does this mean?
Since you can sum scalars to functions, it is natural to sum scalars to vectors.
B = aA + b
[1 2] [3 5]
2 [ ] + 1 = [ ]
[3 4] [7 9] [1 2] [1 2]
2 [ ] + 1 = 3 [ ]
[3 4] [3 4]
---------
Proposal for integrating Mayan numerals into INTERCAL
Title: «The Mesoamerican rejuvenation of compiler language (MAYA-INTERCAL enhancement)»
Objective: To intricately weave the ancient Mayan numeral system into the rich tapestry of INTERCAL, further enriching its already delightful amalgamation of Daedalian syntax and tangled operations.
1. Background and rationale
As INTERCAL stands as a paragon of bleeding edge programming practices, it is only fitting that it embraces the Mayan numeral system, known for its base-20 vigesimal structure. This proposal promises to add another layer of intricate sophistication and enigmatic charm to INTERCAL, further challenging the brave souls daring enough to penetrate its nebulousness.
2. Mayan numeral representation
Symbolic encoding:
– Furry dot (*), representing the value of 1.
– Prostrated bar (_), representing the value of 5.
– Shell (O), representing zero.
Example: The Mayan number for 19 (3 prostrated bars and 4 furry dots) would be represented as ___** in MAYA-INTERCAL.
3. MAYA-INTERCAL – syntax extensions
New keywords:
– MAYANIFY to declare a Mayan numeral.
– TRANSMOGRIFY to convert between Mayan and standard INTERCAL numerals.
– CALCULON for performing calculations with Mayan numerals.
Syntax example:
PLEASE MAYANIFY .#1 AS ___** – declares a Mayan variable.
DO CALCULON .#1 WITH .#2 GIVING .#3 – performs an operational ritual with Mayan numerals.
PLEASE DO NOT GIVE UP
Operations in MAYA-INTERCAL will follow an intentionally intricate system:
– Addition involves a ritualistic dance around the base-20 system, where carrying over is not merely a matter of arithmetic, but a rite of passage.
– Subtraction will be termed as the 'Reverse Ritual', involving comparable, yet not exceeding, complexities.
5. Entering Mayan numerals Mayan numerals, being sacred, can only be entered and accepted under very certain celestial conditions and divinations, otherwise the program will sacrifice itself.
Syntax example:
PLEASE ABSTAIN FROM READING MAYAN INTO .#1 UNLESS MERCURY IS IN RETROGRADE AND JUPITER ALIGNS WITH MARS IN VIRGO
Printing is not just a linear process; it is a multi-dimensional ceremony of revelation where the numeral eventuates in a complex Mojibake art form, respecting the vertical stacking and also adding a horizontal narrative and exquisite ASCII art. If a programmer has recently been penalised with a sacrifice, the output might be partially obscured or altered, representing the displeasure of the MAYA-INTERCAL dieties.
6. Error messages
Error messages will be enigmatic, inspired by Mayan mythology and history.
Example: «The gods are displeased with your sacrifice at Line 10. Consult the oracle (compiler log) for penance.»
7. Documentation: the Codex of MAYA-INTERCAL
The documentation will be an epic saga, resembling ancient codices, filled with:
– Detailed explanations professed to be chimeric tales.
– Hieroglyphs and illustrations demonstrating concepts.
8. Community engagement: The Convocation of Coders
Ventilate the proposal at the Grand Convocation, where devotees of INTERCAL foregather, preferably in thematic attire, to deliberate over the addition of these ancient numerals.
9. Implementation and compiler augmentation
This involves:
– Solidifying the proposal by way of embossing it into clay tablets and baking them in an oven until medium rare.
– Consummating the compiler extensions to support Mayan numerals.
– Ensuring that the new features introduce delightful mannerisms and whimsical behaviours.
Although Fortran is good at arrays, it is terrible at any other kind of data structure. You don't get a standard set of useful data structures (e.g. associative map, k-D tree). Unless you like implementing such stuff, you have to look through a bunch of possibly-working half-implemented codes found using google.
For something focused on numerics, it's lacking in standard IEEE numerical things such as a function to check for nan (GNU extension?!). There aren't an easy ways to do SIMD, excepting hoping the compiler does it for you. There aren't even standard numerical constants, so you get the joy of defining your own PI and hoping it doesn't clash with someone else's.
Strings in Fortran are beyond awful, even with the new ability to reallocate string length.
Then we come to the compilers. The commercial ones may be ok. I know the free ones are very buggy.
The IEEE_ARITHMETIC module has been part of the Fortran standard since Fortran 2003, and includes, among others, the IEEE_IS_NAN() function.
(Supported in GFortran since version 5: https://gcc.gnu.org/gcc-5/changes.html)
Well, C does not have those, either... (I would not call using C "pretty awful experience" though.)
Some folks have attempted to port Fortran projects to CUDA fortran, but that only targets Nvidia GPUs. Then there was openmp 5, but barely any compiler to target AMD gpus.
New HPC projects are written in C++ exactly because it's much easier to target various GPUs in the same code base.
Happy to be convinced otherwise, but this is what I've observed
The thing is, compared to some of the scientific codes out there, GPU are quite recent. Sometimes, slapping OpenMP pragma on the code is not sufficient to take advantage of accelerators, and thus you would need a significant rewrite.
But rewriting a scientific code is a daunting task. Often you have a code where there have been two decades of PhD and Postdocs fine tuning the scientific code, and the numerical schemes in the code do not correspond to the original article anymore. Nobody knows anymore exactly how the code works, and rewriting the code would require that the rewrite matches all the features of the original code (and reproduces the same results). It is basically an impossible task, especially when the labs don't have the resources to hire software engineers.
In practice, nobody wants to rewrite scientific codes for GPU (and sometimes, the problem is fundamentally incompatible with GPU architecture). So as a compensation, they slap some OpenMP pragmas on some parts of the code, hope for the best, and anyways Nvidia clusters are more common than AMD (at least in the scientific world), so OpenMP barely compiling for AMD is not a problem.
This means that legacy scientific codes are pretty much stuck with the CPUs. And in the scientific world, Fortran for HPC CPUs is still the language of choice.
(Someone with a PhD degree here.)
Yet another reason why CUDA is winning.
Unless you're doing scientific computing, Fortran is effectively dead.
Thats kind of like saying,
unless you are doing systems programming C is effectively deadI think it's completely fair to say that Fortran is dead because only physicists use it. And there is no way to justify any similar statement for C.
And no, I don't think only physicists use Fortran. If you really think this then you probably dont quite understand the ecosystem of numerical computing. Besides if only Physicists use Fortran and is otherwise dead, I hardly think, for example, that AMD, Intel, and Nvidia would bother releasing optimizing compilers just for Fortran.
A lot of scientific software, as I can confirm especially in numerical fluid dynamics, is written in FORTRAN or at least uses some libraries written in FORTRAN.
The basis of numerical computing in form of the BLAS/LAPACK libraries is written in FORTRAN and has had a huge impact on everything in this part of computing.
If I am not mistaken even the python libraries depend on BLAS/LAPACK, although they might be using implementations written in C or the like.
Nevertheless, FORTRAN is still the work horse in a lot of computational scientific disciplines and should not be disregarded as being dead.
[1] https://sac.edu/AcademicProgs/Business/ComputerScience/Pages...
df_dx = (f(x+delta) - f(x))/delta
…or whatever after all- it just isn’t that different no matter what programming language you use. I’ve just looked at way too much quant code over my career.
My dad, for example used to write chemical models and started to program on mainframes in fortran. Every now and again he would ask for help porting his models (now in basic or whatever) to a new platform and it was always the same : tens of global variables all with names which were one letter and one digit and no logic to them[1].
[1] Typical conversation: “What’s this formula supposed to actually calculate dad?” “It’s the concentration. You could just use d2 instead.” “Dad you’ve got d0, d1, d3, d4 and d5 but no d2.” “Oh I must have removed that”. “Well how am I supposed to calculate it?” “Just use Newton Raphson” (It was always Newton Raphson.)
I hit a wall recently getting SciPy to work on a Windows Arm machine — because of lack of a Fortran compiler needed to build SciPy.
Still interesting to see that languages like Fortran (12th) and Pascal (13th) are ranked higher than the most popular languages for mobile app development (Swift for iOS, ranked 16th, and Kotlin for Android, ranked 17th) or a highly praised and adopted language for new projects like Rust (only 19th!).
If you want something more reasoned there's this: https://blog.nindalf.com/posts/stop-citing-tiobe/
Are you a non-technical manager? Then hire people who know the language your company has always used, or otherwise whatever languages your hiring pool is familiar with.
Are you a technical manager? Then you evaluate languages based on the intersection of hiring availability and technical merits.
Are you a student? Then use whatever language looks most interesting.
Are you an educator? Then use whatever language best expresses the concepts of the specific curriculum.
Are you an open source contributor? Then select a language to work in based on technical merits, personal taste, and community interaction.
"Popularity" is not one thing, it's dozens of things which all vary based on context.
I graduated in computer science from Purdue in 1981, my first job was working on a FORTRAN compiler and other development tools for commercial avionics embedded systems and then as an early adopter of Ada for same. But I don't know how much that domain overlaps with process control.
Helpful to understand any HPC requirements
Absoft: https://fortran-lang.discourse.group/t/absoft-ceases-operati...
Lahey: https://fortran-lang.discourse.group/t/lahey-computer-system...
Looking at the licenses that I have had, which are SGI († 2009), Pathscale († 2011), Absoft († 2022) and Intel - Intel is to shut down in 2042.
[1]: https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headline...
I had to get this compiling and running this for a University HPC cluster a few years ago, and good lord, it was hell. Manually patching things all over the place to get it running.
In my experience with data-science and engineering code.. well, the fiery gauntlet of getting a large old project to run in a new place might not be the language's fault, but be related to the goals of the folks who first set it up.
Not just most, but all. All weather models, all climate models. And I venture to guess: All ocean circulation models.
Can someone explain why Fortran remains popular within the scientific community and not elsewhere?
0: https://states.github.io/files/j2.pdf 1: https://survey.stackoverflow.co/2023/#section-admired-and-de...
It is quite interoperable (it’s easy to use anything that is callable from C).
It’s easy to archive some code and be sure that it’ll run in the foreseeable future.
Overall, it is a nice language to work with if you’re doing scientific computing. The rest of the world does not care much about its strengths.
I really don't know what the point of such posts are. It is only relevant for people who want to go into scientific computing, and even there you have some GPU rewrites going on. So not everyone is using it but physicist etc. do. Also the legacy code is huge, like with C++.
Fortran is still heavily used in computational chemistry, computational fluid dynamics, marine engineering, nuclear engineering, reservoir engineering, and numerous other engineering fields. Volcanologists use it to predict ash dispersal [2]. Biomedical companies use it for cardiac electrophysiology. Econometrists use it to do tax research [4]. Plasma physicists use it to design magnetic confinement fusion devices [5]. Astrophysicists use it for relativistic magnetohydrodynamics [6]. NASA uses it for all kinds of fluid dynamics-related purposes [7] (read jet engines and rockets), and so do they at CERFACS [8]. For all I know, some integrated circuit manufacturers probably use it use it [9]. It's also used in ham radio and probably some military agencies [10]. It's used in vehicle crash testing [11]. It's used in combustion simulation software [12], fire dynamics [13], hydrometallurgy (ore leaching) [14]. US Geological Survey uses it for ground-water flow modelling [15]. We could go on and on.
[1] https://news.ycombinator.com/item?id=38920486 [2] https://doi.org/10.1016/j.cageo.2008.08.008 [3] https://www.elem.bio/index.html [4] https://taxsim.nber.org/ [5] https://doi.org/10.1016/j.cpc.2021.107986 [6] https://doi.org/10.3390/fluids9010016 [7] https://fun3d.larc.nasa.gov/ [8] https://www.cerfacs.fr/avbp7x/ [9] https://en.wikipedia.org/wiki/SPICE [10] https://en.wikipedia.org/wiki/Numerical_Electromagnetics_Cod... [11] https://www.openradioss.org/ [12] https://en.wikipedia.org/wiki/CHEMKIN [13] https://en.wikipedia.org/wiki/Fire_Dynamics_Simulator [14] https://youtu.be/-dvG270QttE?si=AO-ky0fGwkIEmXDx [15] https://www.usgs.gov/mission-areas/water-resources/science/m...
What was the fun part ? CHIP8 or Fortran ? :-)
365 java
324 javascript
299 python
69 c#
59 c++
59 php
5 delphi
0 fortran
Where are Go and Scala
15 scala
9 golangFor example, I'm using a code that has been started in 1981. It is still very relevant and performant. Of course I wish I could use C++ or even Rust, but the fact is that (high performance) numerical computing is first class citizen in Fortran, which is not the case in C++ or Rust. I wish however that the tooling around Fortran wasn't stuck in the nineties.
> Fortran is harder to compete with. It has a dedicated following who [...] care little for programming languages or the finer points of computer science. They simply want to get their work done.
For example, in certain hipster areas of the programming web, there's plenty of interest in all of the flavours of Algol.