Fortran Package Manager(github.com)
github.com
Fortran Package Manager
https://github.com/fortran-lang/fpm
72 comments
Fortran has a lot of interesting current compiler work leveraging MLIR, a subproject of LLVM: Flang [0] and CIL for C/C++/Fortran [1]. It seems like Fortran tooling is making somewhat of a comeback.
[0]: https://github.com/llvm/llvm-project/tree/main/flang
[1]: https://llvm.org/devmtg/2020-09/slides/CIL_Common_MLIR_Abstr...
[0]: https://github.com/llvm/llvm-project/tree/main/flang
[1]: https://llvm.org/devmtg/2020-09/slides/CIL_Common_MLIR_Abstr...
There is also LFortran, an interactive Fortran compiler:
https://lfortran.org/
Which has multiple backends, besides the default LLVM one, it also has a C++ backend (to translate Fortran projects to a readable C++), and once MLIR matures, we'll add an MLIR backend also.
(I am the original author.)
https://lfortran.org/
Which has multiple backends, besides the default LLVM one, it also has a C++ backend (to translate Fortran projects to a readable C++), and once MLIR matures, we'll add an MLIR backend also.
(I am the original author.)
"I don't know what the language of the year 2000 will look like, but I know it will be called Fortran." —Tony Hoare
I have seen this quote thrown around a lot and have never had the proper context to understand what Hoare was getting at.
The quote is from 1982[1], which seems a bit too late for any “Fortran juggernaut” jokes to have been relevant, and even in 1982 I would have guessed that Fortran was considered a bit old-fashioned. Was he commenting on its comparatively simple design, compared to “flashier” languages like Pascal? Was he just noting its ubiquity in science / government work? Or was Fortran at the time considered a buzzword, something cool-sounding to rope ignorant managers into approving tech projects?
I am a Young Person (thirties) so this era of computing is before my time. More to the point, Hoare’s statement was a deliberately squishy social comment and not a rigorous computer-science comment, which makes it harder for outsiders to “objectively” understand his point. I just can’t see a way that Fortran really fits in the comment - what was the punchline supposed to be?
[1] https://arstechnica.com/science/2014/05/scientific-computing...
The quote is from 1982[1], which seems a bit too late for any “Fortran juggernaut” jokes to have been relevant, and even in 1982 I would have guessed that Fortran was considered a bit old-fashioned. Was he commenting on its comparatively simple design, compared to “flashier” languages like Pascal? Was he just noting its ubiquity in science / government work? Or was Fortran at the time considered a buzzword, something cool-sounding to rope ignorant managers into approving tech projects?
I am a Young Person (thirties) so this era of computing is before my time. More to the point, Hoare’s statement was a deliberately squishy social comment and not a rigorous computer-science comment, which makes it harder for outsiders to “objectively” understand his point. I just can’t see a way that Fortran really fits in the comment - what was the punchline supposed to be?
[1] https://arstechnica.com/science/2014/05/scientific-computing...
Since you honored me by referencing my article, I’ll offer my interpretation. Notices he says “the language”. At the time, Fortran was the language for numerical/scientific computing. By 1982 it had evolved significantly from its origins 30 years earlier, but was still called Fortran. He is saying that it will continue to evolve, but no matter what it will look like in another 30 years, it will still be the language, and will still be called Fortran. He was prescient: Fortran 90 included radical advances to the language, but it remained, pretty much, the scientific programming language, and was still called Fortran. The last sentence of the article, which is from 2014, refers back to the epigram, and predicts that Julia may be the language that finally supplants Fortran for use in science and engineering. Now, Fortran is still dominant in high performance scientific computing, C++ has a niche in particle physics, but Julia is, in fact, making rapid headway across a wide variety of disciplines. So I think my prediction is turning out to be pretty good.
In 1982, FORTRAN use was widespread. The limitations of the language were well known, and it was "obvious to all" that the languages of the future would be more sophisticated and overall "better" than FORTRAN.
It was not "cool", but very mainstream. Taught to all engineering majors in college. And it was the go to language when COBOL wasn't a match.
I interpret this statement as pointing at the tremendous inertia against change, and the fact that most of the tasks given to the computer do not require a abstraction and advanced concepts; just the "IF THEN", "DO", and assignment.
I think he was off by 10 years.
Even now "You can write FORTRAN in any language". I have seen javascript done this way. And it works. We can argue about how well, but it works.
In 1982, I knew of someone at a university who was working on the Fortran 8x specification that became Fortran 90. I don't remember it being thought of as old-fashioned, maybe just less of a general purpose language than in earlier years.
This is... built using Fortran, NICE.
Writing a TOML parser in Fortran is precisely my definition of FUN.
Writing a TOML parser in Fortran is precisely my definition of FUN.
And it was built in Haskell in the first version.
https://github.com/fortran-lang/fpm/pull/420
https://github.com/fortran-lang/fpm/pull/420
The first version was actually in Rust, then Haskell and finally in Fortran.
It sounded like a crazy idea at first, but then we discussed it and realized this is exactly what we should do. It makes perfect sense.
FUN == FU*ing Nightmare? ;)
this is the code for the TOML parser
https://github.com/fortran-lang/fpm/blob/master/src/fpm/toml...
which seems to use another package
https://toml-f.github.io/toml-f/
https://github.com/fortran-lang/fpm/blob/master/src/fpm/toml...
which seems to use another package
https://toml-f.github.io/toml-f/
This is really cool. There are definitely problems with security when it comes to package managers, but I think it has become apparent that having a dedicated package manager for your language is almost as important as the language features your language offers.
As a side note. I've never used Fortran, but I see it around from time to time (R & Python packages that have fortran dependencies). Is Fortran seeing a bit of a resurgence? Is there any reason to use Fortran over say C, C++, Rust, or some other language? Or is it simply down to Fortran's maturity providing robust libraries in certain areas that other languages haven't?
As a side note. I've never used Fortran, but I see it around from time to time (R & Python packages that have fortran dependencies). Is Fortran seeing a bit of a resurgence? Is there any reason to use Fortran over say C, C++, Rust, or some other language? Or is it simply down to Fortran's maturity providing robust libraries in certain areas that other languages haven't?
It seems like there's a small resurgence. You'd use fortan over those other languages for scientific computing. It's built for number crunching. As so it has some language features that help, has been optimized for it (see the n-body problem benchmark), and a lot of the number curnching libraries are written in it.
One example of a project that I've used (but didn't work on) is GEMINI which is a newish prokect written in modern fortan. https://github.com/gemini3d/gemini3d
One example of a project that I've used (but didn't work on) is GEMINI which is a newish prokect written in modern fortan. https://github.com/gemini3d/gemini3d
huh, ifort is slower than I remember compared other langs/impls: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
I don't know what exactly is going on, but last time I looked into it, it seemed the main difference between the codes was how quickly you can do 1/sqrt(x). Ultimately, I would like to see more numerical benchmarks and also compare more versions in a given language.
We started a repository for it:
https://github.com/fortran-lang/benchmarks/
But didn't have time to work on it yet. See the issues, e.g., at:
https://github.com/fortran-lang/benchmarks/issues/2
For some discussion how to best do that.
We started a repository for it:
https://github.com/fortran-lang/benchmarks/
But didn't have time to work on it yet. See the issues, e.g., at:
https://github.com/fortran-lang/benchmarks/issues/2
For some discussion how to best do that.
> sqrt
Used often enough in n-body to make a difference, not used often enough in spectral-norm? not used in fannkuch-redux …
Used often enough in n-body to make a difference, not used often enough in spectral-norm? not used in fannkuch-redux …
Matrix Fortran code can be faster (due to more information for the compiler)
I rely on FPM the Effing Package manager[0]. Occasionally, I run into php-fpm [1]. There's an unfortunate naming collision, at least with the first.
[0]: https://github.com/jordansissel/fpm
[1]: https://www.php.net/manual/en/install.fpm.php
[0]: https://github.com/jordansissel/fpm
[1]: https://www.php.net/manual/en/install.fpm.php
We asked for and received a blessing from Jordan: https://github.com/fortran-lang/fpm/issues/90
I mean that's great - but I don't think it's necessary, it's a name not a trademark. I was trying to point out that its unfortunate when names collide.
Fortran has one. But not C. What hath God wrought.
Well, in FORTRAN, GOD is REAL (and JESUS is INTEGER, but that's not as funny). Even modern fortran has to maintain this feature for legacy reasons, leading one to add 'implicit none' to the beginning of each module etc.
> in FORTRAN, GOD is REAL
.. but not COMPLEX nor LOGICAL
.. but not COMPLEX nor LOGICAL
> > in FORTRAN, GOD is REAL
> but not COMPLEX
Theology concurs: https://en.m.wikipedia.org/wiki/Divine_simplicity
> but not COMPLEX
Theology concurs: https://en.m.wikipedia.org/wiki/Divine_simplicity
I think I would prefer a separation between the package manager and build system. I’ve already got a build system for my FORTRAN codes, and that system can handle all the complications. SPACK, for example, can easily work with a pre-existing build system. But I definitely think that the worst part of FORTRAN compared to modern languages is that it takes so much work to manage external dependencies, so I appreciate the effort.
This issue of separating a build system and a package manager vs lumping it together is a key design decision. We chose to follow Rust's Cargo, which lumps it together. It seems like a wrong decision at first (for the reason you stated), but we feel it is actually the right decision: from the user experience it feels much more natural and robust. I was not sure at first, but after playing with Cargo and Rust, you realize that this is the way to go.
For folks who have never used Fortran, how is the day to day life compared to Python or Java?
Never or ever? I have to use it for a work project. It's ok when dealing with numbers or matrices, but very painful in many respects. It's missing quite a few features found in more recent languages. I don't recommend it personally unless you're working with other big fortran codes.
* Missing standard data structures, like hash maps. I just wish I had something like a Python dictionary built in.
* Strings are pretty awful. You can now have resizeable strings but using them is very painful (and buggy in gfortran). You'll have to constantly strip spaces off the ends of strings to even print them.
* Some of the compilers are very immature (gfortran), if using any fairly recent features (e.g. resizeable strings). I've hit several (still unfixed) compiler bugs and my code contains some terrible workarounds.
* Available libraries are hit and miss, particularly outside the numerical area.
* Linking to C/C++ is possible, but painful with the binding support.
* Documentation (including books) just isn't good compared to what's available for C/C++/Python, etc.
* No templates (would come in very handy for some routines which handle different numerical types).
* Ok for numerics, though can't use C/C++ intrinsics for AVX/SSE maths.
I suppose what I like better than C/C++ is the module system and built-in support for N dimensional arrays with proper slicing, etc. The allocatable array thing is quite nice - it's like smart pointers in C++.
* Missing standard data structures, like hash maps. I just wish I had something like a Python dictionary built in.
* Strings are pretty awful. You can now have resizeable strings but using them is very painful (and buggy in gfortran). You'll have to constantly strip spaces off the ends of strings to even print them.
* Some of the compilers are very immature (gfortran), if using any fairly recent features (e.g. resizeable strings). I've hit several (still unfixed) compiler bugs and my code contains some terrible workarounds.
* Available libraries are hit and miss, particularly outside the numerical area.
* Linking to C/C++ is possible, but painful with the binding support.
* Documentation (including books) just isn't good compared to what's available for C/C++/Python, etc.
* No templates (would come in very handy for some routines which handle different numerical types).
* Ok for numerics, though can't use C/C++ intrinsics for AVX/SSE maths.
I suppose what I like better than C/C++ is the module system and built-in support for N dimensional arrays with proper slicing, etc. The allocatable array thing is quite nice - it's like smart pointers in C++.
Thank you. I agree with all of this, and that is precisely the reason why I decided to get involved to make things better. To fix all of the above I believe we need:
* Much better tooling and more organized community, thus we started https://fortran-lang.org/ and the associated projects (fpm, stdlib, ...) and discussion board (Discourse)
* Better compiler that has good support for all Fortran features, and can help with linking and using C++ and Python libraries (automatic wrappers both ways), better optional warnings (to prevent old style code), good support for GPUs, etc. Also interactive like Python or Julia. I started LFortran (https://lfortran.org) to fix that.
* Perhaps some improvements to the language (I joined the Standards Committee and I encourage people to join). We have a subgroup for generics (templates). The hash maps should probably go to stdlib first, later we can think about putting them into the language itself.
* Much better tooling and more organized community, thus we started https://fortran-lang.org/ and the associated projects (fpm, stdlib, ...) and discussion board (Discourse)
* Better compiler that has good support for all Fortran features, and can help with linking and using C++ and Python libraries (automatic wrappers both ways), better optional warnings (to prevent old style code), good support for GPUs, etc. Also interactive like Python or Julia. I started LFortran (https://lfortran.org) to fix that.
* Perhaps some improvements to the language (I joined the Standards Committee and I encourage people to join). We have a subgroup for generics (templates). The hash maps should probably go to stdlib first, later we can think about putting them into the language itself.
I do an awful lot of baseball stats work .. for fun .. and quite a bit of it is done in FORTRAN. Working with numbers, large matrices and some pretty hairy calculations is much easier, to me, that using R or Python. There are also some really nice libraries available.
Of course, you have to overcome decades worth of ``stuff'' but it certainly is the right tool for what I am doing. It has a purpose but there is a learning curve to getting things done the FORTRAN way.
Of course, you have to overcome decades worth of ``stuff'' but it certainly is the right tool for what I am doing. It has a purpose but there is a learning curve to getting things done the FORTRAN way.
It depends on what you are doing. If it is numerical work with matrix operations, then Fortran is fast and pretty intuitive. Some of the annoyances come from dealing with legacy code and mixing it with modern standards.
Also Compared to Python Fortran is an old school compiled language - you have to get used to working with a compline/link cycle without the interactivity that Python has.
This isn't any better or worse but does require a shift in mind set.
Though I believe some people are trying to build a Fortan Repl
This isn't any better or worse but does require a shift in mind set.
Though I believe some people are trying to build a Fortan Repl
> Also Compared to Python Fortran is an old school compiled language - you have to get used to working with a compline/link cycle without the interactivity that Python has.
I mean, yeah, Fortran is a bit old school, but being compiled is not exactly old school. Plenty of modern languages are compiled. I'd even say that Python and JS are the odd ones out from a modern perspective.
I mean, yeah, Fortran is a bit old school, but being compiled is not exactly old school. Plenty of modern languages are compiled. I'd even say that Python and JS are the odd ones out from a modern perspective.
It might be a bit of a shock for those coming only from interpreted languages though.
That's true, I keep forgetting about https://lfortran.org/ Unfortunately in my experience the people I know who almost exclusively code in fortran are not really interested in jupyter notebooks.
Indeed, I expect it will be newcomers to Fortran from languages like Python, Julia or Matlab who will really like LFortran once it matures. We are working very hard on it and are close to compiling real world projects, you can follow our progress on MVP here:
https://gitlab.com/lfortran/lfortran/-/issues/313
Current Fortran programmers might not always appreciate the interactive part, but I think they will also like LFortran as another independent compiler and for some of its features once it matures (such as C++ translation, fast compilation, good warnings, automatic wrappers to/from Python, etc.).
https://gitlab.com/lfortran/lfortran/-/issues/313
Current Fortran programmers might not always appreciate the interactive part, but I think they will also like LFortran as another independent compiler and for some of its features once it matures (such as C++ translation, fast compilation, good warnings, automatic wrappers to/from Python, etc.).
Nail on the head with the mixing of standards. Every FORTRAN codebase Ive had to use at work always has a mix of 77, 90, and even pre 77 code mixed all together
Is there any value in learning Fortran today, regardless if you work in a domain where it’s a thing or now?
From seeing a lot of job postings in the sort of domains one would expect it to be used(scientific stuff and similar “academic” and research fields) it seems like Python and maybe Julia has taken over for most stuff and Fortran requirements are written as if it’s a “nice to have” for any legacy maintenance.
From seeing a lot of job postings in the sort of domains one would expect it to be used(scientific stuff and similar “academic” and research fields) it seems like Python and maybe Julia has taken over for most stuff and Fortran requirements are written as if it’s a “nice to have” for any legacy maintenance.
A bunch of scientific libraries in Python and Julia are wrappers for really fast stuff made in Fortran, C/C++ so...
BLAS/LApack are pretty much the only Fortran libraries that Julia uses afaik. There is also in development work on a Julia only blas replacement (Octavian.jl) which is competitive with mkl for the basic gemm already (more work needed for some of the more obscure functions). Lots of the push behind Julia is for it's ability to let fairly simple code compete with hands optimized Fortran.
If you work in a 'number crunching' domain it's worth learning enough Fortran to be able to read it. You'll at some point probably have to look at some Fortran code and try understand how it works (or doesn't work).
However the chances that you'll be called upon to write new Fortran is tiny.
However the chances that you'll be called upon to write new Fortran is tiny.
Just curious is Fotran Still being used in Newer Projects
I find the trinity of Matlab, Fortran and Julia quite interesting. They all have a similar syntax and I guess Julia can grab quite some people from the other two ecosystems. Clasically, scientists used Matlab for prototyping and Fortran for high performance implementations. With Julia, things might change. However, in science, changes happen slowly and there are still tons of codes (and also new codes) written in Fortran.
If given a modern tooling, Fortran is not too bad, thought. It is in some respect a "no bullshit" language which doesn't allow you to spend your time on infrastructure, architecture or meta programming, because it is virtually impossible to do these things within Fortran ;-)
If given a modern tooling, Fortran is not too bad, thought. It is in some respect a "no bullshit" language which doesn't allow you to spend your time on infrastructure, architecture or meta programming, because it is virtually impossible to do these things within Fortran ;-)
Also with LFortran (https://lfortran.org) being interactive like Julia, our hope is that it will allow to prototype directly in Fortran.
(I am the original author of LFortran.)
(I am the original author of LFortran.)
Thanks for sharing
I’ll definitely check it out
Yes. Fortran is used extensively in climate modelling (even newer models).
If you're interested in climate modeling, you should really check out Clima.jl. it's an international collaboration on building a next gen climate model in Julia that uses some cool tricks like heavy usage of surrogate models that would be really hard to do in Fortran
Really that’s interesting,
just curious fortran over other languages
In many numerical math, you do not need fancy data structures. Just loops over huge arrays of floating point numbers, performing a simple operation inside the loop. Said operation may have a small bit of complexity inside, thus it cannot be "vectorized" readily. Implementing this kind of algorithms is either cumbersome or extremely slow in Python, but in Fortran or C it is straightforward and fast.
The intuition is similar to "why C over other languages?": speed. Many programmers treat C as the fastest/lowest-level cross-platform language, but Fortran sometimes has a slight edge (especially with specialised compilers, e.g. I remember Intel's producing very fast binaries).
Although it's general-purpose, Fortran skews heavily towards numerical calculations, which is probably why it's not used much outside science and engineering (e.g. most Web stuff is 'string processing' rather than numerical).
Fortran was used to write highly optimised numerical libraries like BLAS, which are so widely used and performance-critical that it pretty much cemented Fortran's use; although (a) such libraries can be used by other languages, and (b) they've become so optimised over the decades that they're essentially pure machine-code these days ;)
Although it's general-purpose, Fortran skews heavily towards numerical calculations, which is probably why it's not used much outside science and engineering (e.g. most Web stuff is 'string processing' rather than numerical).
Fortran was used to write highly optimised numerical libraries like BLAS, which are so widely used and performance-critical that it pretty much cemented Fortran's use; although (a) such libraries can be used by other languages, and (b) they've become so optimised over the decades that they're essentially pure machine-code these days ;)
But interfacing with Fortran from other languages is easy (well, barring some compiler assumptions that everyone seems to be making anyway). Why not leverage the general purpose strength of languages like Rust or C++ or Python (or even C), while still retaining access to the vast trove of numerical Fortran libraries?
(Not that I'm judging, people should use whatever language they prefer).
(Not that I'm judging, people should use whatever language they prefer).
That's what tends to happen, at least in the code I've worked on. C/C++ for the bits that need to "talk" to the OS, python/perl/bash for scripting purposes, and Fortran for the number-crunching core.
Weather forecasting in most countries are based on numerical models written in Fortran.
Despite what you may have heard, the language has evolved over the decades and has most of the features one would expect from a modern language.
Despite what you may have heard, the language has evolved over the decades and has most of the features one would expect from a modern language.
Yes, a nuclear modelling software called MCNP is widely used and written entirely in fortran. Some of its source code can date back to the dawn of computing in the 1940s!
Edit to say I missed your newer project specification; MCNP is still under very active development and frequent updates, if that counts.
Edit to say I missed your newer project specification; MCNP is still under very active development and frequent updates, if that counts.
Nota only it keeps being used, the latest versions support generics, modules and OOP.
It even got modules before C++.
It even got modules before C++.
Yes, see for example http://mesa.sourceforge.net/index.html which is a stellar evolution code used a lot in astrophysics.
Yes, but I think not as much as advocates of it would suggest.
Just like SQL, it suffices to rule on one specific use case to keep being used.
Yeah exactly - it's great for numerical computing.
I get a bit annoyed by Fortran advocates complaining about people using C++/Python instead of it, when there aren't libraries for doing really basic things. I think Fpm is a really good step in the right direction though.
I get a bit annoyed by Fortran advocates complaining about people using C++/Python instead of it, when there aren't libraries for doing really basic things. I think Fpm is a really good step in the right direction though.
I am a Fortran advocate, but I don't complain that people use C++ or Python. I use C++ and Python myself, both are great languages. I agree Fortran is missing the library ecosystem, and that is why we started fpm. It takes years to fix this problem.
SQL is based on set theory and there is a reason for its existence. FORTRAN is based on legacy. Still remember the I j k and 80 columns things ...
To be honest reading https://github.com/fortran-lang/fpm/blob/master/src/fpm_back... the only thing look like the old fortran I know is integer I j and do loop. No go to I guess.
To be honest reading https://github.com/fortran-lang/fpm/blob/master/src/fpm_back... the only thing look like the old fortran I know is integer I j and do loop. No go to I guess.
Apparently you haven't kept up with times.
https://www.manning.com/books/modern-fortran
https://www.manning.com/books/modern-fortran
SciPy and NumPy both use Fortran :P
https://www.quora.com/Which-python-packages-besides-Numpy-us...
Does NumPy use Fortran?
NumPy does not use Fortran. It provides an interface to BLAS (Basic Linear Algebra Subprograms) and Lapack (Linear Algebra Package) for which the reference implementation is written in Fortran.
NumPy does not use Fortran. It provides an interface to BLAS (Basic Linear Algebra Subprograms) and Lapack (Linear Algebra Package) for which the reference implementation is written in Fortran.
Well, it uses FORTRAN code, machine-translated into C.
Which is "C code" but not really C code.
Which is "C code" but not really C code.
A single Fortan
Fortran Package Manager's First Birthday (2020-12?): https://github.com/everythingfunctional/fortran-forum-fpm-fi...
Resurrecting Fortran (2021-03): https://ondrejcertik.com/blog/2021/03/resurrecting-fortran/
First year of Fortran-Lang (2020-12): https://medium.com/modern-fortran/first-year-of-fortran-lang...