Read on Twitter
This is ok I guess, though I'm not sure why one wouldn't just bind to an external standard C routine. Not sure I'd ever need it but that's fine. Fortran didn't get proper bit operations until MIL-STD 1753 back in 1978; never seen them used in practice https://twitter.com/fortranlang/status/1331235446022672390
At the risk of alienating hardworking motivated Modern Fortran people, there are a few reasons I haven't put much effort towards the Fortran "Standard" Library despite having documenting my thoughts on what one should look like a few years back https://github.com/fortran-lang/stdlib
First, it's more than a little presumptuous to call the project a "standard" library when it's not actually standardized. Boost sidesteps this problem with C++; many of its features get standardized but only after they get used, tested, and modified as part of Boost
It's not just a matter of arbitrary naming; IMO the project should be clearly decoupled from actual ISO/ANSI standard Fortran. Boost solved this problem for C++; why reinvent it for Modern Fortran? That is the running theme of my objections.
There's a proliferation of new Fortran-only tools that duplicate the functionality of mature general-purpose tools. I am absolutely uninterested in using immature Fortran-only tools that lack features I currently rely on. So much wheel-reinventing. :(
For me, Fortran stdlib discussion went off the rails once people started talking about standardizing numerical libraries, AS IF THAT WAS WHAT FORTRAN HAS EVER BEEN LACKING. That ship sailed sometime in the 1970s with netlib.
It became clear to me that the bright, energetic, motivated, hard-working people looking at the lack of a standard library were barely interested in anything I cared about and were devoted to creating dead-end niche tools and I just don't have the energy to work against that
More and more often I look at social situations like this and ask "Will I do more harm than good?" and just withdraw. I spent a decade getting paid for people to ignore my advice and subsequently crash and burn; it's depressing and I no longer do it for free.
I've looked at some of the new tools and found no compelling reason to use them. FORD ( https://github.com/Fortran-FOSS-Programmers/ford) was born out of frustration with Doxygen. Output is prettier but HTML only (non-starter for my needs) and it only works with Fortran. Hard pass.
That it requires a program unit's documentation to be enclosed inside the unit was also a big stumbling block. It's a design choice but the lack of flexibility to keep the formatting style I already use with Doxygen seemed like a gratuitous boat-burning. Us or Them. :(
I already have enough trouble managing the plethora of also-ran build automation systems from everyone + dog in the He-Man CMake Haters Club. Why the hell would I ever want a Fortran-only build automation system? Wouldn't writing a CMake tutorial be faster and easier?
My goal here is not to shit all over the hard work of others. I just question the value of reinventing working infrastructure and further isolating Fortran as niche computing. It just doesn't seem sustainable.
For generic tasks like documentation, build automation, package management, etc., I want to use fewer tools, not more. I write more than just Fortran code and my toolchain reflects that. None of these tools buy me enough to invest the effort into using and developing them.
Because ultimately I'm going to run into a limitation that will require me to send patches back upstream. With a mature general-purpose tool with many users, the probability I'll need to do that is low. Much higher with a niche tool.
I do not want to spend time removing bugs from a niche tool that were already worked out of a mature tool a decade ago. It just doesn't seem like a good use of anyone's time.
We won't get into the general Open Source community's (willful?) ignorance that in many organizations, working on a non-Windows desktop OS is a privilege. Likely the same cloistered environment that can't tell you what a non-academic license for MATLAB costs.
Another complaint sort of falls into the "BuT wHy ArEn'T YoU wOrKiNg oN mY pRiOrItIeS?!" bin. Sort of. Let's look at some unsolved problems in Fortran space. Weak support for generics, data structures, and input processing. ABI and .mod file chaos. No support for contracts.
Rather than focusing on "Like <x> but gratuitously specific to Fortran" features, maybe focus on Fortran's advantages and the peculiarities of its problem domain and its developers. Reimagining Fortran as a faster, less magical, stable, trustable Python is rather doomed.
Again, I won't tell volunteers to work on things they don't enjoy or care about. I can't. It's just hard to contribute to the codebase or discussion when you see so much effort and focus spent on (re)solving already-solved problems
So. Tiring.
