# Scipy is replacing Fortran with C **URL:** https://fortran-lang.discourse.group/t/scipy-is-replacing-fortran-with-c/9059 **Category:** Uncategorized **Created:** [January 11, 2025, 11:57am UTC](https://fortran-lang.discourse.group/t/scipy-is-replacing-fortran-with-c/9059 "2025-01-11T11:57:11Z") **Posts on this page:** 1 **Showing post:** 2
### Author: ![ivanpribec](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/ivanpribec/32/3290_2.png) [@ivanpribec](https://fortran-lang.discourse.group/u/ivanpribec) #### Post date: [January 11, 2025, 1:51pm UTC](https://fortran-lang.discourse.group/t/scipy-is-replacing-fortran-with-c/9059/2 "2025-01-11T13:51:45Z")
This has been discussed at length also on Fortran Discourse: > [@The difficulties of using Fortran in SciPy](https://fortran-lang.discourse.group/t/the-difficulties-of-using-fortran-in-scipy/6753): > > The article catalogs the difficulties. A related thread is [SciPy: "there is interest in adopting this (PRIMA) implementation, but little appetite for taking on more Fortran code"](https://fortran-lang.discourse.group/t/scipy-there-is-interest-in-adopting-this-prima-implementation-but-little-appetite-for-taking-on-more-fortran-code/5821). Let me excerpt the positive part of the article. While Fortran has long been the butt of the joke in IT departments the world over, in a curious twist of fate, it has seen a dramatic resurgence over the last few years. While the reasons for this are not exactly obvious (at least to us!), a few possible explanations… Since it is a long thread, I will link to a direct answer from one of the SciPy maintainers, why preserving the existing fixed-form Fortran code is non-desirable: [The difficulties of using Fortran in SciPy - #54 by ev-br](https://fortran-lang.discourse.group/t/the-difficulties-of-using-fortran-in-scipy/6753/54) I can certainly agree the style of these existing legacy codes can be hard to comprehend (even for Fortran programmers). There are other issues too like static variables (`save`), API’s relying on named user procedures instead of procedure arguments (callbacks), and a bunch of wrapper idiosyncrasies which get in the way of sane software engineering. The next issue SciPy faced is due to build woes, such as: - lack of native Fortran compiler on Windows (if I remember correctly using `gfortran` via Cygwin or MinGW is problematic, because of incompatibilities in the underlying C libraries when the Python interpreter is compiled with MVSC) - issues on MacOS (and more recently also Windows) with Aarch64 processors, where Fortran compilers still aren’t as mature (although it is getting better) A good write-up can be found here: [The 'eu' in eucatastrophe – Why SciPy builds for Python 3.12 on Windows are a minor miracle | Labs](https://labs.quansight.org/blog/building-scipy-with-flang) * * * There is also a related thread at the Scientific Python Discourse, discussing new Fortran libraries/components: > **[Is adding new Fortran to SciPy generally allowed?](https://discuss.scientific-python.org/t/is-adding-new-fortran-to-scipy-generally-allowed/1438)** > > What’s the project’s policy on new Fortran code? Suppose there’s some feature which would be nice to have. There’s an externally developed, high-quality implementation, but it’s written in Fortran. My impression from #18566 is that we’re trying to... --- _[View the full topic](https://fortran-lang.discourse.group/t/scipy-is-replacing-fortran-with-c/9059)._