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.
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!
If you do anything related to numerical computations (which is a pretty huge field) learning Fortran wont be a waste of time. If you are doing anything else your time might be better spent elsewhere
Can I request some more insights about it? If I want to be doing something else, why isn't Fortran a good fit? Lack of extensive stdlib like Python and Go?
Mine was not a statement about its stdlib or if Fortran can do something else well. Great majority of people in Fortran community are focused on numerical methods.
Basically the only "stdlib" that Fortran gives you are some mathematical functions, super basic string and file operations and that's it. There are no APIs for networking, sockets, IPC, threads, etc. that pretty much al modern languages come with.
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.
It's a use the right tool for the job thing. Fortran is very fast, used primarily for scientific computing in various fields - not a lot of people are writing general purpose code in Fortran. Of course you can do it, but it's not a great experience and you'd spend a lot more time doing work you'd rather already have tools for.
Unfortunately it's pretty much the opposite: Fortran doesn't have standard library, just a small set of "intrinsic" functions that a compiler must implement.
Nonetheless, Fortran has built-in support for N-dimensional arrays, with vectorised operations (including custom functions), so the experience is pretty similar to Numpy.
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.
I think they mean "python like easy syntax", fortran certainly does not have a std library that contains e.g. a HTTP client or SMTP server (to my knowledge).
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.
Do people actually use modern versions of Fortran though? I learned it in university in 2004, and we used Fortran 90 because F95 was considered “too new”, and one still encountered a lot of Fortran 77.
They do. Some national HPC centers offer Fortran courses including elements of Fortran 2018 [1,2], including the latest features. (Disclaimer: I work at one.) The Intel Fortran compiler already includes some Fortran 2023 features [3].
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.
I have no idea why you're getting down-voted.
I've worked in finance/algo-trading for 15+ years. Went through shops like Goldman Sachs, Morgan Stanley, UBS, HSBC. Quants everywhere use CPP and Python, sometimes R.
I've never seen Fortran used anywhere.
> If they use Numpy in Python they surely use Fortran under the hood.
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.
I still work in HFT yes. A sibling comment lays it out better than I could, and I'm surprised that so many people here insist on Fortran's popularity when it's clearly absent from whole industries where you guys would expect to see it.
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.
Live trading systems are in C++ or Java, but like others have said Python is used for day-to-day research, sometimes R if the particular quant likes it.
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 financo/algo-trading is math heavy, it does not fall into the category of scientific computing.
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.
I'm not disputing that there is seriously heavy math involved - many of my fellow PhDs in physics/engineering went to finance.
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.
Julia (and MATLAB) have large, heavy runtimes making them non-ideal for applications where size and startup speed matter, eg. libraries, edge computing.
Their dynamic nature makes them much better at exploratory programming compared to Fortran though.
Julia might get there in confort, but still a lot of catch up to do with a compiled language designed for scientic computing, which also had to win the hearts of Assembly programmers in speed and code size, as the first high level language with an optimizing compiler (there were some failed attempts before FORTRAN).
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 :)
It depends on what you mean by "scientific computing". I can't imagine doing scientific computing in the sense I do (using computing to analyze scientific data) without strings, lists, dictionaries, and (not that you mentioned them) data frames, which means R and Python are far better tools for doing my kind of scientific computing (yes, I know that R, and maybe Python, use libraries like BLAS underneath and those were written in Fortran).
Okay, but this mentions exactly my own field of computational biology. I don't think many computational biologists are using Fortran (except indirectly through libraries like BLAS) in the 21st century.
> Lists, dictionaries, strings (none of which is of any use to scientific computing)
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.
When you say 'python like' experience, does it support slicing and broadcasting like in Numpy or MATLAB? I'm preparing to learn Fortran as a complete beginner. I'm curious about the ergonomics of the language.
not sure if it's different from what you are saying, but the elemental specifier[0] makes functions broadcastable, such functions operate on each element of its input separately.
I think broadcasting in numpy is over rated. Its rules are complicated and ironically non-mathematical. Why should this be obvious?
a = 5
b = np.array([1, 2, 3])
a + b
>>> array([6, 7, 8])
Looking through the documentation you get the feeling you are learning a whole new language whose syntax could change under your feet. They would have done better to use something like APL :)
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!
> This is very natural, and consistent with standard mathematical notation.
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 don't understand what you mean. Precisely the Bourbaki camp would be the only people who would avoid the broadcasting notation that is commonly used in math.
Our positions diverge because you take the extra-formal specification in mathematics as basis, and then say, "nah thats too formal", broadcasting is more natural. On the other hand I take elementary to undergrad mathematics as basis and say that rules about adding (using a standard '+' symbol) a scalar to a vector in numpy via broadcasting is confusing.
Julia requires you to explicitly specify if you want to use broadcasting (i.e. `[2, 4, 8] + 3` fails so you need to do `[2, 4, 8] .+ 3`). When I first came across this I thought it was unnecessary but the more I use it the more I like it because I think it improved my mental model of broadcasting. With numpy it was mostly trial and error.
> 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).
I'm not talking about matrices as in linear algebra, I'm talking about functions. If you interpret a vector or a matrix as a function of its indices, then
B = α*A + β
means just
B(t) = α*A(t) + β
for all relevant t. This broadcasting is used everywhere in signal and image processing, and it would be extremely unnatural if your language forced you to write some monstrosity that modified the constant β so that it has the same type as A.
Perhaps this is really a personal preference, but in maths I really dislike ambiguity. There are is just way better notation for this. For example Einstein notation or Rici calculus? Besides being succint, it is explicit and well understood. Even just using plain i,j indicies is not too cumbersome. But for a b scalars and A a matrix
For "broadcasting" an array along a particular axis, you'll need to use the function "spread(source,dim,ncopies)". But mixed array/scalar expressions are indeed supported.
Indeed, just like the rumours about the premature death of INTERCAL have been grossly overstated. For the INTERCAL freemasons have been tirelessly working in the midst of countless nights in the Lodge to complete the proposal to add support for Mayan numerals to INTERCAL.
---------
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
4. Numeric operations
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
6. Printing Mayan numerals
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.
As someone who has to use Fortran for their job fairly frequently, I say Fortran is a pretty awful experience compared to Python.
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.
So it does not provide good development experience as with Python, as said in that comment. Seems consistent to me? Nobody's comparing Fortran with C here.
As someone who has been using about a dozen programming languages over more than two decades, I completely disagree with your experience, some of which appear to be due to incomplete knowledge of the Fortran programming language, including your statement "lacking in standard IEEE numerical things such as a function to check for nan". Everyone talks about C and C++, but we all know in our hearts how terrible the syntax of these languages is.
Ha ha yes, though I haven’t written a line of FORTRAN (nor fortran) in decades.
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.
In French, the person who does the sodomizing of is called "enculeur de mouches". It is a relatively common expression, as is the action of "enculer les mouches".
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)...
It is the official language of the Vatican. That isnt nothing and probably saves latin from formal dead status imho. And lots of military organizations use it for mottos. So someone is out there creating new sentences with it on a semi-regular basis.
Last I checked there were no people being born in Vatican nor had Latin as their first language, citizenship is only given based on the office you hold. It's pretty close to nothing, it's a corporate HQ with a language requirement.
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.
Latin has no first-language speakers, so that makes it a dead language by definition. That's different from being an extinct language, which means that it would have no first- or second-language speakers.
Classical languages like Latin are a bit of a special case - for instance new works and translations /imto/ Latin are still occasionally published (Hobbitus Ille for instance is stocked in certain bookstores here)
Looking at the activity on the Free Pascal compiler[0] compared to some other, non-dead languages like Crystal[1], I would say Pascal isn't dead.
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.
The Castle Game engine is not mentioned often, but it looks pretty mature from the screenshots and has been in active development for many years. Most recent news update was a few weeks ago. I have not gotten around to try it yet. Only started playing around with FreePascal a bit last year after not having used Pascal at all for some 25 years.
> 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.
I think Perl is pretty much dead, who is starting a new project in Perl? I haven't seen a Perl project in years. It's just still heavily used in legacy applications too big to rewrite.
Actually, I would say it is almost entirely for lack of trying the Linux Desktop thing.
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.
Yea, everytime I install linux on a new laptop there is something that doesn't work without a bunch of work and sometimes something that just doesn't work at all.
It's way better than in the 2000s when I started to use Linux.
Why is it ridiculous? The goal of a computer program is to solve a problem. The Perl script solves the problem. It handles all of the weird edge cases a re-write would rediscover. Re-writing it would take engineer time away from other priorities. And a re-write in a new language offers no guarantee that Microsoft wouldn't find themselves in the exact same situation 10 years hence if the language they chose for the re-write falls out of favor.
Because it's an external dependency that must be installed manually in certain cases? 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.
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.
> Because it's an external dependency that must be installed manually in certain cases?
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.
Well, I guess it won't be too long before someone completely rewrites that thing in another language. Or hope.
(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)
Latex or Postgresql. If I'm not wrong, Psql is a Perl script, and many pg_X commands (pg_ctlcluster, pg_conftool, pg_upgradecluster... etc) also are Perl.
There is a huge amount of perl on your average Linux system, and it's integral to the GNU Autotools suite which is still widely used in many critical system components. I have trouble imagining it going anywhere at this point.
You seem to be confusing "new projects" with "maintained projects".
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”.
Are new programmers learning perl? That's probably the real question. I think the answer is no. So it'll be dead as soon as all the people coding in it today retire.
Pascal is definitely somewhat alive, but way far from its heyday on DOS and Macintosh. For dead languages in the class, Modula-2 is mostly dead and Modula-3 is definitely dead. Forte TOOL is dead.
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.
GNU Modula-2 just joined the set of official GCC supported languages on a full install, and is now listed on the set of languages that matter on Compiler Explorer.
While Prolog is niche it's still alive and kicking IMO. The go-to example for a 'modern' project is TerminusDB. I'm currently using Prolog for a greenfield expert system project at $work. There's been a bit of a Datalog resurgence as well, you can see it in the Biscuit authz system for example. As a fundamental pillar of logic programming, I don't think it will ever die (akin to Lisp and functional programming). Pure speculation here but I think we might see more interest towards symbolic AI in the coming years coupled with LLMs to ground answers against well-defined knowledge bases, as a sort of anti-hallucination measure.
Yeah for 'a dead language' there would only be ALGOL, PL/1, and not much else. Excluding really niche languages that never made it out the research lab in the first place.
Embarcadero is still in business selling Delphi licenses, a new version was released last quarter, and there are enough companies in Europe, to at least have them in two German conferences, alongside Windows and .NET developers.
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.
> 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?
The issue with COBOL (opinion) is that its used in "business, finance, and administrative systems for companies and governments" (development sponsored by the DoD) which all tend to be high money, secrecy, and competition. Plus, back in 2012, 60% of all companies surveyed still had COBOL in the back somewhere (2017: 43% of banking systems still used COBOL with over 220 billion lines of COBOL code).
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.
Personally, I like to think of Fortran as the language of large-scale numerical PDE and eigenproblem solvers. Most scientific and engineering problems boil down to one of these two.
At least in the US national lab system Fortran is nominally being phased out in a lot of projects. It's just gotten too hard to find highly skilled Fortran programmers to maintain these complicated projects, so a lot of codebases are gradually being moved away from it. However the reality is it's mostly aspirational; some of the large codebases have at least made big progress towards migrating onto C++ but the tail is very long indeed and it's still entrenched with many of the greybeard HPC folks. It's also tough to imagine some of the big legacy codes that are still heavily used in the nuclear industry (e.g. MNCP) migrating away due to the sheer amount of experimental validation that has been done on the existing Fortran code.
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.
National labs should be able to attract people who can learn Fortran well enough to maintain those codes. After all the hard part is the math, not the programming.
You'd be surprised. People who aren't particularly interested in programming qua programming don't typically have strongly held opinions about it. Using the same programming language as the group you're working in is usually the main consideration. Speaking from experience as someone who has worked in an applied math group where the predominantly used language was Fortran.
I don't get this. It's highly difficult to find vast troves of military reserves (ie: bodies who can do military stuff) in war time. That's what bootcamp and sergeants are for.
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?
Yeah, all of that is part of the long tail. Fortran isn't going away, but with younger people who grew up without Fortran getting into leadership positions momentum is in the favor of moving HPC and sometimes more mundane computational code to C++. It's not just that developers are harder to find, it's that C++ is also offering advantages with better tooling, better libraries and community support, etc. Leveraging (and contributing to) open source is also important for DoE, which is tough in Fortran.
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.
There are loads of people who'd be willing to do this at a national lab. The bigger problem is that very few national labs are located in places many young people want to live. For the ones that are (LBL), it's competitive to get a job there.
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.
I think Prolog is still used in some niches. But that definition is apt. Fortran is far from dead. It might even be on the verge of a renaissance.
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.
TIOBE index is sometimes very strange, but it takes into account available jobs as well. That said, their methodology has been challenged forever.
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!).
I don't care one way or another about the TIOBE index, but that video is obnoxious and isn't making an argument or presenting data. Not sure why anyone would be convinced by this.
Even if TIOBE wasn't garbage (and let's be clear: TIOBE is and always has been garbage for a litany of reasons), no such reference would exist, because the question is ill-specified.
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.
Jim's article pretty much confirms my assumption that Fortran isnt "dead" but is instead more of a de-facto domain-specific language. If you're a meterologist, you'll probably be using Fortran just because all of the existing libraries are built for it.
Unless you're doing scientific computing, Fortran is effectively dead.
C is very much also alive in games programming, binary security research, embedded systems, HPC, and as a target language for simple compilers. Oh, and as the lingua franca of all foreign function interfaces. And there's still a thriving vommunity of people writing C purely for fun (e.g. see obfuscated c programming competition).
I 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.
I understand that C is far more used than Fortran. Of course I also dont think C is dead. I was trying to make a statement about saying Fortran is just alive in scientific computing. While this is mainly true, scientific computing is so huge that it is quite a big thing to be alive in it.
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.
Jim's observation seems to be generally similar on other HPC clusters in other countries.
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.
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.
It's one of my go-to models (for checking the weather, not for computing the results myself!), I didn't know that most meteo stuff runs on FORTRAN.
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.
It's because all these jobs using Fortran are scientific research projects. It is not explicitly asked, but if you are doing high performance computing, chances are you will be using Fortran. Scientific codes live for decades.
For 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.
3 of our 15 devs write Fortran, but we don't find them through dev job sites. They have PhDs related to hydrodynamic simulations and many of the people in the field know each other through conferences.
Who care who thinks what, a tweet, really? As if we have to agree on some pointless statements. In certain areas it is used, in others not. Now what?
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++.
I don't know what the state of things is right now, but if Fortran is the language of choice for HPC, then explain to me why it's so hard to write portable code that targets accelerators.
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
Historically, it has been easier for vendors to work in their own walled gardens, and get customers locked in, than it is to collaborate on open standards and APIs.
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.
OpenMP support in Fortran will improve as flang matures. In OpenMP 5.0 "#pragma omp requires unified_shared_memory" was introduced. At LLNL, they are are currently building El Capitan (https://www.datacenterknowledge.com/supercomputers/lawrence-...), a supercomputer using AMD MI300A accelerators which support this concept. LLNL is also one of the OpenMP ARB members (https://www.openmp.org/about/members/).
Correction: most PhDs in scientific fields don't know what unit tests are. Nobody ever taught/told them to write unit tests, and they have never heard of them, have never seen one, let alone written one.
For fun, I wrote a CHIP8 interpreter in Fortran recently [1].
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.
This comment is dead on. People here are somehow trying to sell a bunch of dead languages that only a small niche of people care about. Anything that can be done with these languages can be done with Python, Rust, etc just as easily if not easier. There’s a reason why they teach Python and not Fortran.
While I love and and still make a big chunk of money from Fortran consulting (mostly translating old Fortran to Python or Matlab) it’s not dead...but there’s little reason to start a new project in today.
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.
Fortran is more alive today than it was 10 years ago. If you didn't notice, a lot of numpy libraries is Fortran code, and they are improving this all the time. It is more used for scientific and machine learning programming nowadays than it ever was.
Fortran is hardly dead, but neither is it is well.
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.
Fortran needs multiple healthy independent open-source implementations for production use. If you have the skill and inclination, please contribute fixes and features and bug reports and tests to GNU Fortran and LLVM Flang.
Secondarily, Fortran could benefit from modern educational materials, public test suites, effective responses to misinformation, and better discussion sites.
Good point, and thanks for noting it. I was only thinking of independent actively developed production compilers in my space of expertise, where C/C++ seems to be down to GNU, Clang, and EDG-based compilers, while Fortran still has at least GNU, Intel, nvfortran, LLVM Flang, NAG, and XLF. A decent C89 compiler for a single target is only about a 10K LOC project and there must be more than a few of them out there.
I am not complaining about the cadence of standards. It is the continued absence of critical modern programming features that has rendered the standard committee irrelevant.
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.
In case like me you wondered about 'VASP', it is a reference to the Vienna Ab initio Simulation Package, a computer program for atomic scale materials modelling, e.g. electronic structure calculations and quantum-mechanical molecular dynamics, from first principles.
Because it’s simple to grasp, easy to write, well-suited to the fields in which it is used (things like first-class multidimensional arrays, native complex numbers, good auto-vectorisers, things like OpenMP…), and quite efficient.
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.
236 comments
[ 1.9 ms ] story [ 302 ms ] threadDo 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:
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.
[0] https://pythonspeed.com/articles/numpy-2/
> 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.
[0] https://fortranwiki.org/fortran/show/elemental
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
where b is just a vector. Or at least you would make β bold to distinguish it from a scalarWhat exactly does this mean?
Since you can sum scalars to functions, it is natural to sum scalars to vectors.
---------
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:
4. Numeric operationsOperations 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:
6. Printing Mayan numeralsPrinting 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.)
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.
https://www.lazarus-ide.org/
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.
https://en.wikipedia.org/wiki/Extinct_language
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...
https://castle-engine.io/
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.
[1] https://www.tiobe.com/tiobe-index/
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!).
https://youtube.com/shorts/m76vWNr83wo
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.
Unless you're doing scientific computing, Fortran is effectively dead.
Thats kind of like saying,
I 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.
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.
Where are Go and Scala
For 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.
[1] https://ieeexplore.ieee.org/document/4263269
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++.
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.
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 ? :-)
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.
[1]: https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headline...
[1] https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headline...
https://news.ycombinator.com/item?id=38969390
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.
https://en.wikipedia.org/wiki/Industrial_Real-Time_Fortran
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
https://www.vasp.at
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.
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.