[jvanderbot]

Python itself isn't really used for scientific computing. Pythons bindings to high performance libraries, many of which use Fortran under the hood, are used for scientific computing.

Combined with the ease of displaying results ala Matlab but much less of the jank, and you have an ideal general purpose sci comp environment

[Lyngbakr]

Back when I worked in scientific programming, we adopted a similar approach. The heavy lifting functions we wrote in C, but they were called from R which allowed us to plot the results, etc., easily. And the libraries we used (for solving differential equations) were all old school Fortran libraries.

If I were to start again today, I think I'd give Julia a look, though.

[dataminded]

You can make this claim about anything that isn't direct machine instruction.

End users are using python - the advantage of modern computing is that whatever happens afterwards is irrelevant.

[KeplerBoy]

Still, people leave a lot of performance on the table when using Numpy in sub-optimal ways or when the problem just doesn't translate neatly to Numpy.

It's tempting to get lazy and just use a for-loop to iterate over an array sometimes and that will absolutely kill your performance.

[ska]

There is often no real value in optimizing such code, if the computation finishes in a time that doesn’t mess with your workflow. Spending more time on it will often just take time away from something more valuable to the research.

[KeplerBoy]

Ahh yes, that's a good point. If you're, for example working in a Jupyter Notebook, it absolutely doesn't matter if a cell needs 3 seconds or 3 milliseconds to execute.

[dataminded]

Frequently because those performance gains aren't actually needed. We live in an age where you can cheaply and quickly scale the hardware for 99% of tasks. Tasks that are too expensive to compute inefficiently are also unlikely to be profitable enough to be doing at all.