Fortran Package Manager
github.com
github.com
Fortran Package Manager's First Birthday (2020-12?): https://github.com/everythingfunctional/fortran-forum-fpm-fi...
It was very quickly that many interested in using fpm also expressed some interest in helping with its development. There was one problem. Most people were not familiar with Haskell, making that a significant barrier to their being able to contribute. But everybody had significant experience (or at least interest) in Fortran. It was thus that we decided we would rewrite fpm in Fortran, enabling a larger portion of its intended users to also be contributors. With the initial prototype usable for developing libraries, and many already converting their existing libraries to be fpm compatible, it didn’t seem quite so daunting a task as it otherwise would have.
First year of Fortran-Lang (2020-12): https://medium.com/modern-fortran/first-year-of-fortran-lang...
[0]: https://github.com/llvm/llvm-project/tree/main/flang
[1]: https://llvm.org/devmtg/2020-09/slides/CIL_Common_MLIR_Abstr...
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...
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.)
Writing a TOML parser in Fortran is precisely my definition of FUN.
https://github.com/fortran-lang/fpm/blob/master/src/fpm/toml...
which seems to use another package
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?
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
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.
Used often enough in n-body to make a difference, not used often enough in spectral-norm? not used in fannkuch-redux …
.. but not COMPLEX nor LOGICAL
> but not COMPLEX
Theology concurs: https://en.m.wikipedia.org/wiki/Divine_simplicity
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
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.).
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.
* 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++.
* 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.
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.
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.
However the chances that you'll be called upon to write new Fortran is tiny.
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 ;)
(Not that I'm judging, people should use whatever language they prefer).
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 ;-)
(I am the original author of LFortran.)
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.
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.
Edit to say I missed your newer project specification; MCNP is still under very active development and frequent updates, if that counts.
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.
It even got modules before C++.
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.
Which is "C code" but not really C code.