atsider

Yep, to me it's not far superior to find-replace: https://nullprogram.com/blog/2017/09/07/

I think there is nothing to prove, I set up my prosody just by reading the documentation -- eventually https://compliance.conversations.im/ is a great tool to see how well you are doing, and which modules are worth uncommenting lines from the initial config file. I have a functional and working server with just a score of 85%.

The only real pain point could be iOS, but it is the platform the one that makes things extra difficult, see for example what happens with browsers (https://en.wikipedia.org/wiki/Firefox_for_iOS)

wrt to old crusty FORTRAN code: scipy is using many of those popular libraries, it is based on them.

wrt to type signatures, many of those ancient FORTRAN libraries are written with implicit interfaces, so bugs are likely to show up. I came to learn this when compared some versions floating around with the patched versions supplied with scipy.

My aim is not to bash, but justify scipy is a solid piece of software, based on known developments, not just a shiny "new" thing.

Yep, it combines the convenience of a GUI, the scripting capabilities and the power of the key shortcuts. It's almost perfect!

I'm using Debian's 78.5.0. It uses external gpg by default and works flawlessly for me with my hardware USB token.

This us a great addon I discovered recently, but nevertheless they have an introductory video about the Blender editor: https://github.com/GDQuest/blender-power-sequencer/blob/1.5....

And yet none of those technologies is fortran-specific, nor mentioned on its standard, nor solve at tiny bit the problems the OP was specifying.

But then we are not talking about fortran anymore: I tried recently PGI and it is far behind than intel/gfortran with respect to the standard.

I can code with CUDA in many more languages than fortran. If I wanted to use gfortran, I just would make a wrapper to CUDA with C++.

Exactly, that is my point: so we are mainly still in the land of Fortran95, which is not designed for taking advantage of the latest features of the hardware.

Nowadays intel is not a reference for C++; the versions found on HPC compilers are not the fastest nor the best following the latest standards.

I don't think commercial/open source is the key here: on the fortran side we have been long suffering from a lot of bugs/regressions with the current versions of intel fortran (with respect to the "latest" features like OOP) -- I would even say that they could be more than we are finding in gfortran.

An explanation could be that they are investing time in supporting their big customers that likely use ancient code bases.