Of general interest: SciPy's solution to the two-language problem is

… 5 languages. :wink:

Link to article

Lest someone feels the need to correct me: this is tongue in cheek. I do recognize the need to wrap established libraries. The article does not actually say how much of “fast language code” is in the libraries and how much is used to replace slow Python.


I think SciPy should be applauded as a heroic effort to do scientific computation in a language not even remotely designed for that purpose, and delivering a result that many people find useful. Julia has benefited a lot from the limitations of Python that were uncovered in the process and we should always appreciate that.

Incidentally, I find it weird when they point out that

When started in 2001, the library had little funding and was written mainly by graduate students—many of them without a computer science education and often without the blessing of their advisors.

Perhaps economics is an outlier, but it is my impression that

  1. advising faculty generally do not care about code details, just results. Asking for a blessing on code would feel weird from either side, except perhaps for computationally intensive methodological projects.

  2. non-CS grads students rarely ever have a CS education. This generalizes: for better or worse, most code written in an academic context has never been touched by people with a CS education.

  3. it is very rare to get funding just to write a library from scratch. Perhaps to improve on an existing, widely used library, but that is not the norm either.


this hits home hard… especially bad when codes are Fortran, C++, C (not giving out sub-field names

FWIW, I don’t think that a bachelor/master’s degree in CS has much to do with writing clean, maintainable, well designed code. It has more to do with experience, which comes from making a lot of mistakes.


That appears to mainly be wrapped libraries: https://github.com/scipy/scipy/search?l=fortran

1 Like