[ok123456]

F2py, which is already a standard part of numpy, does the heaving lifting and generates idiomatic python wrappers for Fortan code.

It's just zealotry of them going "eeew fortran that's like really really old". Fortran got multidimensional dense numeric arrays right. Modern Fortran allows you to do elemental/vectorized operations on them. C does not even come close, and requires tons of preprocessor macros if you try. Every other 'modern' language introduces a bunch of tooling and dependencies just to get where Fortran is, because they just don't have a focus on scientific computing.

[michaelt]

> It's just zealotry of them going "eeew fortran that's like really really old".

The developers of SciPy are maintaining a codebase that is 18% fortran, according to [1]. The only language that makes up a larger part of the codebase is python.

Don't you think it's possible their opinion on fortran is actually informed by quite a bit of experience?

[1] https://github.com/scipy/scipy/

[zaikunzhang]

I guess one of the major issues is the compilation and packaging of the Fortran code. It is also my experience when developing PDFO ( https://www.pdfo.net/ ), the predecessor of PRIMA.

This is also reflected by the following comment at https://github.com/scipy/scipy/issues/18118#issuecomment-155...

> The real maintenance burden is the compilation and the packaging not the code itself that we are carrying around.

[bouchard]

I don't believe anybody would argue against their reluctance for old FORTRAN 77 code; it's a PITA to deal with.

The central issue is that their experience with the old Fortran doesn't translate to modern Fortran; they are two different beasts.

[zaikunzhang]

> The central issue is that their experience with the old Fortran doesn't translate to modern Fortran; they are two different beasts.

This is so true! I hope anyone could spend a few minutes checking what modern Fortran is before blaming it. A good reference is https://fortran-lang.org/en/

[ok123456]

Buy a copy of plusfort.