[raoulj]

In the defense of the SciPy response, while there may be some programming language zealotry behind the position, it seems to be from a lack of expertise in SciPy to maintain its Fortran code that's pushing SciPy to avoid new Fortran additions. Hopefully OP gets PRIMA through! Been admiring this effort, Dr. Zhang.

[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]

Thank you so much for your encouragement! Such positive feedback means a lot to me.

[cozzyd]

As long as PRIMA is maintained (which seems likely independently), it's only the bindings that need to be maintained. And it's trivial to write a Fortran interface in C or C++ (perhaps that can be included in PRIMA anyway) and then SciPy can pretend like it's not Fortran...