Not only it is doing quite alright, latest versions 2003 onwards (latest is 2023), are quite confortable to use, offering almost a Python like experience, with a performance experience of 60+ years in compiler optmizations.
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.
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 :)
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.
The main offering of python is bindings and easy glue to pretty much any data source/sink imaginable.
Their dynamic nature makes them much better at exploratory programming compared to Fortran though.
> 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.
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.
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.
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.
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.)
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!
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.
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.
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.
---------
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.
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.
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]
I meant this. Very few people look at a number 7 and think of it as a constant function
[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...