With the right controls it might be a better (more flexible) version of Vim's block selection mode. Which I use almost daily, it's super useful but depends on lines being vertically aligned, which multiple cursors don't need to care about.
But I don't see another purpose for them; find-replace with regex support and macros only fail in rare cases where actual syntax parsing is needed.
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.
I don’t mean at all to imply scipy and co are flashy but rickety pieces of software. I think it’s a testament to their quality that such libraries have reached a broad and diverse audience.
I think the foundational libraries of the scientific Python ecosystem are definitely well taken care of. I think a lot of that care comes from “brute forcing” the ecosystem to make it work, eg distributing native compiled C/Fortran code seamlessly on a bunch of platforms with entirely new (at the time) package managers like conda, or wholly new scientific distributions of Python. My observations are more to do what’s built atop them.
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.
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.
