I think two interesting comments are those by qsort
Given the capabilities of modern machines and the fact that non-homogenous hardware (GPUs, different processors like in Apple Silicon) is back, the “winning” strategy is to have high-level scripting languages where you can ignore most of the details, which call into hyper-optimized, high performance libraries. For instance, when you’re using Scipy, you call into Fortran and C almost interchangeably.
Since most likely you aren’t writing full programs in the low-level language, it doesn’t need to be a general-purpose language offering the same affordances, say, C++ is supposed to provide.
For numerical/scientific code, Fortran is much, much easier to use, especially for people whose background isn’t computer science. Being able to write your code in terms of matrices and arrays rather than “pointer to const restrict” is a godsend when you’re programming what is often very difficult mathematical code. When compared to modern C or C++ you won’t get any advantage in terms of performance, but you don’t lose much either, and in return you get to use a language that’s much more suited to the task.
The historical Achilles’ heel of Fortran is that it’s kind of awkward as a general-purpose language, but that’s negated by the “compiled core, interpreted shell” approach that’s dominant these days.
I was going to post here. Let’s go ahead and participate in the discussion there. I just commented a few times there. Let’s learn from the feedback there, and use the opportunity to promote Fortran.
“Achilles’ heel” indeed. That’s the experience with modern Fortran in many domains.
As I commented here, with just a handful of new facilities added to the language, Fortran can greatly overcome being an awkward language for many tasks i.e., anything besides hard-core number-crunching where, at times with some effort, many other programming paradigms and languages are able to do just as well as Fortran, or even better.
Too bad it’s proving impossible to get such few, new features introduced, again and again the practitioners feel the need but they are being ignored.
The world of Fortran is no longer that of Backus et al. Backus and co. set out do something that can possibly delight the practitioners, not merely meet some basic needs with a higher level language beyond Assembly. Now, with modern Fortran language development, it is perennially trying to do the barest of minimum to stay relevant and/or to manage the decline of Fortran. “Too little, too slow” is how it goes. The “voice of the customer” is being largely ignored.
@certik LFortran is currently on the front page of Hack News as well. See here. It is the top two right now. I posted it. Hope it will help to promote both LFortran and Fortran. Enjoy another boost of GitHub stars.
This, from nologic01 resonates quite strongly and is all the more painful because of how slow the committee is in adopting modern practices into Fortran:
Yet suddenly the same arcane HPC is effectively also the domain of “AI” and the associated planetary hyperventilation. Now all sorts of modern initiatives and language ecosystems aim to reposition to gainfully intermediate that AI revolution. Python was the scripting language that somewhat unexpectedly enabled all this, but now its warts are under the microscope and people think of various alternatives (julia), supersets (mojo), newcomers like rust etc. But that race is definetely not settled and it might not be so for quite some time. The requirements are highly non-trivial.
As far as taking part in this race, Fortran seems to have missed not one but several boats. Yet the fact remains that it was a language designed for number crunching and evolved as language for HPC, with parallel computing features (since F90) etc. It combines easy to read imperative numerical code with near optimal computational performance.
Its like a former world champion in a sport that was fell out of favor for a long time but is now unexpectedly back in vogue. So the question is whether the champ can get back into shape or make room for new contenders
@general_rishkin indeed, and I even replied to this comment there too.
Let’s not blame the committee here, even if it adopted more features faster, that by itself doesn’t implement them and I think it’s actually an advantage, as the language is not bloated. I think it’s the compilers that need to drive the effort, as well as the wide Fortran community that need to improve the overall tooling and ecosystem. We are improving both the tooling and the compilers, we just need time, as writing a compiler is a 5 - 10 year effort. You have to start, but you can’t expect results overnight. If you want results today, then the compiler effort should have been started 10 years ago. The same with the tooling and ecosystem. Those are all very long term efforts. We started, now we need to continue and not give up.
Thanks @zaikunzhang ! Very good to see LFortran there.
Fortran is quite unique. Besides possibly LISP, it is the only language that regularly receives comments like this one:
I’m confused why you would post this, and I’m even more confused why it would make the front page. Fortran is a dying programming language, and even if they have a website now, they are still a dying language.
In essence: Fortran, please die more quickly.
However, I see less and less of such comments over time, and even this one got downvoted, etc. Once we make it to the front page of Hacker News, and we receive no more comments of the type “please die more quickly”, then we finally made it! We are almost there, but not quite yet.
It has probably more to do with the people active on the Orange Site. Engaging in discussions there is like wrestling with a pig, eventually you get dragged into the mud, and in general it is not worth it.
@interkosmos heh, it can be. But I like getting into the “ring” and make myself available for questions, feedback and criticism. I must say this time the feedback has been excellent, both for fortran-lang and LFortran. Very good comments I thought.
@zaikunzhang indeed, that’s great. I am very happy about that. We have been steadily developing it, and we will post a few blog posts soon with updates, we are still finishing the work to compile our third code. Thank you for your support!
Thank you @certik for your efforts! I hope Fortran will reclaim the popularity, so that I do not need to explain why I use Fortran when introducing PRIMA. In addition, I hope LFortran will mature as soon as possible, so that projects like PRIMA will be much less painful to develop.
On the Hacker News thread a plausible question is “Yes, Fortran may be easier for number crunching with arrays than C++, but why not just use Python with Numpy?” Here are few thoughts I may post on HN the next time the question arises.
I mostly use Python at work, because of libraries like pandas, because speed is not yet a problem, and because other colleagues, especially younger ones, are more likely to use and extend my Python code. Python with NumPy is fine for some scientific computing, but here are some drawbacks:
(1) CPython will run your script until it comes across a variable you have not defined, or a function you have imported, or other show-stoppers. This is frustrating when it happens after the script has run for some time. Smaller problems such as variables set but never used are also ignored. To use Python productively for larger programs I think tools such as ruff and vulture are needed. Gfortran with the right compiler options (and turning some warnings into errors) gives you some functionality that you only get with external tools in Python. (This is probably true with ifort or NAG Fortran as well – I mostly use gfortran.)
(2) Python has optional type annotations, but it is difficult for me to force myself to use them consistently when they give no speed boost and when I need to use yet another tool, mypy, to find errors revealed by annotations. In Fortran you use IMPLICIT NONE and put code in modules and are then forced to fix errors due to mismatched types.
(3) In Fortran you need not think for more than a few seconds about how to do a calculation using array operations and intrinsic functions. If it’s not obvious, write a loop, which will generally be as fast. In Python, R, and Matlab, you need to shoehorn your problem into array operations to get decent speed.
(4) In Fortran you can and should write functions that resemble mathematical functions, which return something and have intent(in) arguments. If a procedure does not satisfy these requirements you write a subroutine. I think the “function” concept is overloaded to cover too many things in imperative languages that do not have subroutines.
I think we should post Fortran-related projects on HN when there is a major advance – “news”. If advocates of a language are perceived as overly promotional, that can hurt the reputation of a language.
Note that HN supposedly keeps track of inbound hyperlink traffic and downranks topics that are receiving a large portion of their votes from visitors arriving from the same domain to reduce the effectiveness of coordinating (abusing) the voting system. For that reason, it’s best not to post HN links directly to domain-specific forums like this one.
“Fortran 2023” is the title. it was still on the front page when i checked. I’ll add the link too, i don’t think it’s important anymore, it was just to avoid the story being flagged if bunch of people clicked through and upvoted but i assume that’s less likely now that it’s been established. (But don’t click the link and upvote)
