I've always had a soft spot for Fortran, even though I rarely use it any more.
When I was in undergrad, so sometime around 2006 or so, I read somewhere that Fortran was actually faster than C in some cases, due I believe to the compiler and certain choices it makes regarding aliasing arrays and whatnot.
I am an aerospace engineer and avid flight simmer, mostly WWII combat sims, and a huge part of the hobby involves arguing with other people about WWII piston aircraft and their performance. Pages upon pages of forum threads replete with PDFs of historical documents in German, Russian, etc. In order to win arguments more effectively, I decided to write a parametric "flight sim" that would accept a set of maneuvers as an input (e.g. "start at 10000m, dive until speed reaches X km/h indicated, zoom climb back up" or "turn in a circle at Y km/h indicated") so that I had something to compare the in-game results and historical data with.
I decided to write the whole thing in Fortran 2003 (the 2008 revision was still a draft, as I recall), because fast.
I bought a copy of Stanley Hooker's book "The Performance of a Supercharged Aero Engine" from the Rolls-Royce heritage press, implemented the method therein. Implemented a numerical vortex panel method for the lifting surfaces, the whole shebang. It was actually a really fun project and it worked pretty well. Fortran is a neat, quaint language and I look back on that project fondly but ultimately I don't miss Fortran. The syntax is needlessly verbose. I/O is a chore. String manipulation is a pain. If you ask me, C++ (despite its many flaws) is superior in every way.
Author of LFortran here. LFortran is written in C++, because I knew I will be able to fully deliver the project in it. So I know C++ and Fortran very well. I can say for sure that C++ is not superior in every way. It's slower to compile, hard to deal with dependencies (that's more of a tooling issue), it's more complex, and specifically for numerical array-oriented computing C++ is actually much more verbose and harder to read. For non-numerical computing, such as compiler development, C++ is not a bad choice, that's why I chose it. The slow compilation of C++ is truly a major problem for me, and after we deliver LFortran we'll see if maybe moving to C might be worth it, just to get 10x faster compilation of the C/C++ sources of LFortran itself (the speed of LFortran I think would be similar, we already use arenas and other tricks for performance, which can be done in C just as easily).
I haven't used vcpkg, but looking at their tutorial at https://learn.microsoft.com/en-us/vcpkg/get_started/get-star..., it seems you still have to use cmake, and if so, it is indeed more complex than fpm (https://fpm.fortran-lang.org/tutorial/hello-fpm.html) where you don't use cmake. Fpm is similar to Cargo. Cargo is indeed as simple as fpm. However, as I mentioned above, this is just a tooling issue, somebody can (and should!) write Cargo for C++. In fact, fpm can build C++ projects also.
The best package manager that I like the most for C++ is Pixi (https://pixi.prefix.dev), that works really well.
FORmula TRANslation, the clue is in the name. It's great at math, but yeah, strings and OS stuff is a PITA. The modern vector-based syntax is still really nice and I've yet to come across a C++ library quite as slick.
But I think what it was really missing last time I looked at it was good access to compiler intrinsics (or otherwise) to hit vectorizations and math optimization instructions. The OpenMP simd pragmas weren't really doing a fantastic job. I hope that's better now it's in LLVM.
It's such an odd little subcultural quirk that Fortran (really HPC) people call programs and libraries "codes". Most software folks refer to "code", as if it was a substance like sand or water, and use other words for specific units of "code" (programs, libraries, modules).
>Fortran (really HPC) people call programs and libraries "codes".
I think it's a European engineering thing that just sort of caught on, actually. For example when I was in undergrad, my 4th-year computational fluids prof made us use "Code Aster"[0] and "Code Saturne"[1] which are both made by a French lab, I believe. Most of the usage of "code as a countable noun" that I've encountered has origins in English-as-a-second-language projects.
The uncountable aspect of many English words is highly unintuitive to many of us.
Information. Code. Software.
Hardware.
I suspect many people don't even know they are uncountable.
I suppose for software we should just use programs or applications. But that's slightly more specific than software!
In French we can have both: le logiciel as some uncountable mass, or un/des/N logiciels if you need to count them.
Why the hell do I need to cut information into pieces to count it?
Both English and French are cursed languages, but English loses on this one.
And then there's the trousers. And now you need to say "a pair of" to talk about one unit of them. Though to be completely fair we have that for the glasses (lunettes) and the scissors as well.
> I suspect many people don't even know they are uncountable.
Well, most English speakers may not know the term, but they can feel the concept just fine.
> In French we can have both: le logiciel as some uncountable mass, or un/des/N logiciels if you need to count them.
This mostly works in English (and other European languages) as well, e.g. "Two teas/beers, please" etc. But in English this turn of phrase is much more restricted which is indeed a shame.
Now that you say it, when speaking about software code, it might not be very common to use the plural form in French too, it's indeed more like water, some uncountable mass. I don't think I would be shocked though.
If you want to peer into an alternative reality / funhouse mirror of programming terms, you should look at ALGOL 68. For instance, types are called "modes".
Author of the blog post. It's just being a non-native speaker and writing the blog post by hand shows these little mistakes. I've been using the terms "code" and "codes", but you might very well be right that my usage is not entirely correct. I'll ask native speakers what the proper usage is here.
It's very common among scientific programmers to call programs "codes," native speaker or not. It's just a quirk of different computing communities evolving differently.
> Sort of how Common Lisp calls threads ‘processes’.
Can you point to any documentation on that? It's not in the hyperspec and it doesn't seem to be in Common Lisp the Language, 2nd Edition (using the index)
"deck" is the fairly normal word throughout the EDA industry. i reckon it's because such things used to be literal decks of punchcards, but i know less about EDA history than programming history.
Author of LFortran here. The historical answer is that both LFortran and Flang started the same year, possibly the very same month (November 2017), and for a while we didn't know about each other. After that both teams looked at the other compiler and didn't think it could do what they wanted, so continued on their current endeavor. We tried to collaborate on several fronts, but it's hard in practice, because the compiler internals are different.
I can only talk about my own motivation to continue developing and delivering LFortran. Flang is great, but on its own I do not think it will be enough to fix Fortran. What I want as a user is a compiler that is fast to compile itself (under 30s for LFortran on my Apple M4, and even that is at least 10x too long for me, but we would need to switch from C++ to C, which we might later), that is very easy to contribute to, that can compile Fortran codes as fast as possible (LLVM is unfortunately the bottleneck here, so we are also developing a custom backend that does not use LLVM that is 10x faster), that has good runtime performance (LLVM is great here), that can be interactive (runs in Jupyter notebooks), that creates lean (small) binaries, that fully runs in the browser (both the compiler and the generated code), that has various extensions that users have been asking for, etc. The list is long.
Finally, I have not seen Fortran users complaining that there is more than one compiler. On the contrary, everybody seems very excited that they will soon have several independent high-quality open source compilers. I think it is essential for a healthy language ecosystem to have many good compilers.
I appreciate the usecase you're describing but I feel like "that has good runtime performance (LLVM is great here)" is at odds with the rest of that list. I don't see that as a problem though. I think it's useful to have a very fast lightweight compiler for development and prototyping (both of projects and the compiler itself) and a slower one for highly optimized production releases.
Yes, that's one answer. But I actually think you can absolutely have both in the same compiler. But you need to have two backends, as I described. You use the custom backend for development (fast to compile) and you use LLVM for release (fast to run).
Well yes, but at that point aren't you effectively writing two compilers in one? It seems to me that would be at odds with wanting it to be fast to compile itself (you said under 30s) and would make it more difficult for the uninitiated to contribute to.
I don't mean to discourage and I don't disagree with the aims. I just have the (possibly mistaken) impression that compilers inevitably fall on a continuum from simple and fast to complex and slow.
No, you "only" have to write a backend. Which is still a lot of work, but much less work than another compiler. There are multiple ways it can be designed, but one idea that I like the most right now is to create an API for LLVM, and then implement the same API ourselves with a fast backend. That way we reuse everything in current LFortran, including lowering to LLVM, we just have to refactor it to use our own API instead.
For extra fun, "flang" actually refers to three different projects, one of which also completely rebuilt its frontend, so there are four separate "flang" frontends to LLVM. And I know of at least one proprietary LLVM-based Fortran compiler that's not based on any of the flags, and I suspect there are a few more lurking about.
The short answer as to why there are so many different LLVM Fortran frontends is that open source community took a long time to find someone willing to commit to a Fortran frontend to LLVM, and even when that happened, the initial results weren't particularly usable--it's not until I want to say late 2020 or early 2021 that there's an in-LLVM-tree flang project, and the exe isn't renamed from flang-new to flang until 2024.
I started writing the new "f18" Fortran front-end at NVIDIA in the summer of '17, and it was added to LLVM as "flang" in June 2020. There were already at least three other "flang"s at the time, one of which was our open-sourced llvm-targeting pgifortran compiler.
I still call this latest one "flang-new" myself just because that's the only unambiguous name for it. The name confusion is not my fault, I promise.
There is Classic Flang, there is New Flang (part of LLVM tree), there is LFortran, there is Intel's ifx (also based on LLVM) and Nvidia's nvfortran (also based on LLVM, I think). And maybe even more.
Fortran ecosystem is actually more prolific, at least in terms of toolchains, including proprietary ones, than most of more popular languages.
Digression, but people sometimes forget that there is whole world outside of Python or JS, and that GitHub Stars or ShowHN posts do not easily translate to real world usage.
Today, there are at least 9 production-level surviving Fortran compilers (GNU Fortran, IFX, nagfor, nvfortran, XLF, Cray/HPE's ftn, Fujitsu's frt, old Flang-based Arm/AMD, and flang-new). This situation has advantages and disadvantages for our users. Their Venn diagram of equivalently implemented features is very much not a circle, and portability across compilers is really tough. The ISO standard is hardly clear and doesn't have a test suite or reference implementation, so it's been a very challenging task to make flang-new as easy to port existing codes to as possible.
I've always had a soft spot for Fortran, even though I rarely use it any more.
When I was in undergrad, so sometime around 2006 or so, I read somewhere that Fortran was actually faster than C in some cases, due I believe to the compiler and certain choices it makes regarding aliasing arrays and whatnot.
I am an aerospace engineer and avid flight simmer, mostly WWII combat sims, and a huge part of the hobby involves arguing with other people about WWII piston aircraft and their performance. Pages upon pages of forum threads replete with PDFs of historical documents in German, Russian, etc. In order to win arguments more effectively, I decided to write a parametric "flight sim" that would accept a set of maneuvers as an input (e.g. "start at 10000m, dive until speed reaches X km/h indicated, zoom climb back up" or "turn in a circle at Y km/h indicated") so that I had something to compare the in-game results and historical data with.
I decided to write the whole thing in Fortran 2003 (the 2008 revision was still a draft, as I recall), because fast.
I bought a copy of Stanley Hooker's book "The Performance of a Supercharged Aero Engine" from the Rolls-Royce heritage press, implemented the method therein. Implemented a numerical vortex panel method for the lifting surfaces, the whole shebang. It was actually a really fun project and it worked pretty well. Fortran is a neat, quaint language and I look back on that project fondly but ultimately I don't miss Fortran. The syntax is needlessly verbose. I/O is a chore. String manipulation is a pain. If you ask me, C++ (despite its many flaws) is superior in every way.
Author of LFortran here. LFortran is written in C++, because I knew I will be able to fully deliver the project in it. So I know C++ and Fortran very well. I can say for sure that C++ is not superior in every way. It's slower to compile, hard to deal with dependencies (that's more of a tooling issue), it's more complex, and specifically for numerical array-oriented computing C++ is actually much more verbose and harder to read. For non-numerical computing, such as compiler development, C++ is not a bad choice, that's why I chose it. The slow compilation of C++ is truly a major problem for me, and after we deliver LFortran we'll see if maybe moving to C might be worth it, just to get 10x faster compilation of the C/C++ sources of LFortran itself (the speed of LFortran I think would be similar, we already use arenas and other tricks for performance, which can be done in C just as easily).
I will concede that compile times in C++ do indeed suck.
But surely managing dependencies with e.g. vcpkg is no worse than with fpm?
I haven't used vcpkg, but looking at their tutorial at https://learn.microsoft.com/en-us/vcpkg/get_started/get-star..., it seems you still have to use cmake, and if so, it is indeed more complex than fpm (https://fpm.fortran-lang.org/tutorial/hello-fpm.html) where you don't use cmake. Fpm is similar to Cargo. Cargo is indeed as simple as fpm. However, as I mentioned above, this is just a tooling issue, somebody can (and should!) write Cargo for C++. In fact, fpm can build C++ projects also.
The best package manager that I like the most for C++ is Pixi (https://pixi.prefix.dev), that works really well.
FORmula TRANslation, the clue is in the name. It's great at math, but yeah, strings and OS stuff is a PITA. The modern vector-based syntax is still really nice and I've yet to come across a C++ library quite as slick.
But I think what it was really missing last time I looked at it was good access to compiler intrinsics (or otherwise) to hit vectorizations and math optimization instructions. The OpenMP simd pragmas weren't really doing a fantastic job. I hope that's better now it's in LLVM.
It's such an odd little subcultural quirk that Fortran (really HPC) people call programs and libraries "codes". Most software folks refer to "code", as if it was a substance like sand or water, and use other words for specific units of "code" (programs, libraries, modules).
>Fortran (really HPC) people call programs and libraries "codes".
I think it's a European engineering thing that just sort of caught on, actually. For example when I was in undergrad, my 4th-year computational fluids prof made us use "Code Aster"[0] and "Code Saturne"[1] which are both made by a French lab, I believe. Most of the usage of "code as a countable noun" that I've encountered has origins in English-as-a-second-language projects.
[0] https://code-aster.org/
[1] https://en.wikipedia.org/wiki/Code_Saturne
The uncountable aspect of many English words is highly unintuitive to many of us.
Information. Code. Software. Hardware.
I suspect many people don't even know they are uncountable.
I suppose for software we should just use programs or applications. But that's slightly more specific than software!
In French we can have both: le logiciel as some uncountable mass, or un/des/N logiciels if you need to count them.
Why the hell do I need to cut information into pieces to count it?
Both English and French are cursed languages, but English loses on this one.
And then there's the trousers. And now you need to say "a pair of" to talk about one unit of them. Though to be completely fair we have that for the glasses (lunettes) and the scissors as well.
> I suspect many people don't even know they are uncountable.
Well, most English speakers may not know the term, but they can feel the concept just fine.
> In French we can have both: le logiciel as some uncountable mass, or un/des/N logiciels if you need to count them.
This mostly works in English (and other European languages) as well, e.g. "Two teas/beers, please" etc. But in English this turn of phrase is much more restricted which is indeed a shame.
And let's not even start with pluralia tantum.
> Well, most English speakers may not know the term, but they can feel the concept just fine.
Oh yeah, I should have specified, I was speaking about non native speakers, and thinking about people speaking French or a similar language.
>In French we can have both: le logiciel as some uncountable mass, or un/des/N logiciels if you need to count them.
Mais est-ce qu'on dit "les codes"? Selon moi ça ne marche pas.
Now that you say it, when speaking about software code, it might not be very common to use the plural form in French too, it's indeed more like water, some uncountable mass. I don't think I would be shocked though.
If you want to peer into an alternative reality / funhouse mirror of programming terms, you should look at ALGOL 68. For instance, types are called "modes".
https://jemarch.net/a68-jargon/
(There are also "incestuous unions", which is the actual term used in the spec.)
Huh - R has a concept of “mode” that overlaps and complements “type”… but then again R also a very funhouse mix of terminology.
https://rstudio.github.io/r-manuals/r-lang/Objects.html#inde...
From the docs, an incestuous union is the equivalent of a packed union in C? Well, you gotta be packing' to be incestuous :D
Author of the blog post. It's just being a non-native speaker and writing the blog post by hand shows these little mistakes. I've been using the terms "code" and "codes", but you might very well be right that my usage is not entirely correct. I'll ask native speakers what the proper usage is here.
It's very common among scientific programmers to call programs "codes," native speaker or not. It's just a quirk of different computing communities evolving differently.
I do come from the scientific community, so didn't know until today that not every community uses the term "codes".
I guess when you’ve been calling it that before everyone else you’re allowed. Sort of how Common Lisp calls threads ‘processes’.
As does Smalltalk and Erlang, and to make things more interesting, all three mean something not exactly the same.
> Sort of how Common Lisp calls threads ‘processes’.
Can you point to any documentation on that? It's not in the hyperspec and it doesn't seem to be in Common Lisp the Language, 2nd Edition (using the index)
in the ngspice user manual, they call circuit descriptions an "input deck"
https://ngspice.sourceforge.io/docs/ngspice-manual.pdf
"deck" is the fairly normal word throughout the EDA industry. i reckon it's because such things used to be literal decks of punchcards, but i know less about EDA history than programming history.
[dead]
I am curious to know why there are two Fortrans (i.e. LFortran and LLVM Flang) both targeting the LLVM backend?
Author of LFortran here. The historical answer is that both LFortran and Flang started the same year, possibly the very same month (November 2017), and for a while we didn't know about each other. After that both teams looked at the other compiler and didn't think it could do what they wanted, so continued on their current endeavor. We tried to collaborate on several fronts, but it's hard in practice, because the compiler internals are different.
I can only talk about my own motivation to continue developing and delivering LFortran. Flang is great, but on its own I do not think it will be enough to fix Fortran. What I want as a user is a compiler that is fast to compile itself (under 30s for LFortran on my Apple M4, and even that is at least 10x too long for me, but we would need to switch from C++ to C, which we might later), that is very easy to contribute to, that can compile Fortran codes as fast as possible (LLVM is unfortunately the bottleneck here, so we are also developing a custom backend that does not use LLVM that is 10x faster), that has good runtime performance (LLVM is great here), that can be interactive (runs in Jupyter notebooks), that creates lean (small) binaries, that fully runs in the browser (both the compiler and the generated code), that has various extensions that users have been asking for, etc. The list is long.
Finally, I have not seen Fortran users complaining that there is more than one compiler. On the contrary, everybody seems very excited that they will soon have several independent high-quality open source compilers. I think it is essential for a healthy language ecosystem to have many good compilers.
I appreciate the usecase you're describing but I feel like "that has good runtime performance (LLVM is great here)" is at odds with the rest of that list. I don't see that as a problem though. I think it's useful to have a very fast lightweight compiler for development and prototyping (both of projects and the compiler itself) and a slower one for highly optimized production releases.
Yes, that's one answer. But I actually think you can absolutely have both in the same compiler. But you need to have two backends, as I described. You use the custom backend for development (fast to compile) and you use LLVM for release (fast to run).
Well yes, but at that point aren't you effectively writing two compilers in one? It seems to me that would be at odds with wanting it to be fast to compile itself (you said under 30s) and would make it more difficult for the uninitiated to contribute to.
I don't mean to discourage and I don't disagree with the aims. I just have the (possibly mistaken) impression that compilers inevitably fall on a continuum from simple and fast to complex and slow.
No, you "only" have to write a backend. Which is still a lot of work, but much less work than another compiler. There are multiple ways it can be designed, but one idea that I like the most right now is to create an API for LLVM, and then implement the same API ourselves with a fast backend. That way we reuse everything in current LFortran, including lowering to LLVM, we just have to refactor it to use our own API instead.
A fast-to-compile but slow-to-run LLVM alternative would make Julia much more useable day-to-day too.
For extra fun, "flang" actually refers to three different projects, one of which also completely rebuilt its frontend, so there are four separate "flang" frontends to LLVM. And I know of at least one proprietary LLVM-based Fortran compiler that's not based on any of the flags, and I suspect there are a few more lurking about.
The short answer as to why there are so many different LLVM Fortran frontends is that open source community took a long time to find someone willing to commit to a Fortran frontend to LLVM, and even when that happened, the initial results weren't particularly usable--it's not until I want to say late 2020 or early 2021 that there's an in-LLVM-tree flang project, and the exe isn't renamed from flang-new to flang until 2024.
I started writing the new "f18" Fortran front-end at NVIDIA in the summer of '17, and it was added to LLVM as "flang" in June 2020. There were already at least three other "flang"s at the time, one of which was our open-sourced llvm-targeting pgifortran compiler.
I still call this latest one "flang-new" myself just because that's the only unambiguous name for it. The name confusion is not my fault, I promise.
There is Classic Flang, there is New Flang (part of LLVM tree), there is LFortran, there is Intel's ifx (also based on LLVM) and Nvidia's nvfortran (also based on LLVM, I think). And maybe even more.
Fortran ecosystem is actually more prolific, at least in terms of toolchains, including proprietary ones, than most of more popular languages.
Digression, but people sometimes forget that there is whole world outside of Python or JS, and that GitHub Stars or ShowHN posts do not easily translate to real world usage.
Today, there are at least 9 production-level surviving Fortran compilers (GNU Fortran, IFX, nagfor, nvfortran, XLF, Cray/HPE's ftn, Fujitsu's frt, old Flang-based Arm/AMD, and flang-new). This situation has advantages and disadvantages for our users. Their Venn diagram of equivalently implemented features is very much not a circle, and portability across compilers is really tough. The ISO standard is hardly clear and doesn't have a test suite or reference implementation, so it's been a very challenging task to make flang-new as easy to port existing codes to as possible.