73 ms·
> How about beating Python + numpy + pandas in data crunching I'd think this sentiment misses a small bit of context. In the above combination, Python is the
by bostik 11y ago
> How about beating Python + numpy + pandas in data crunching
I'd think this sentiment misses a small bit of context.
In the above combination, Python is the glue language, which merely makes it easy to dispatch the heavy lifting. Numpy is a damn good convenience wrapper around the under-the-hood number crunching engines - which themselves are written in static languages.
I mean, have you ever tried to _build_ numpy from scratch? That thing pulls in both BLAS and LAPACK, some of the most heavily optimised libraries in the world. These fortran(!) libraries can trace their ancestry all the way to 1970's, and have benefited from aggressive optimisations done over the course of 4 decades. [0,1]
So, invoking numpy as a testament to power of dynamic languages misses a pretty important point. And I say that as someone who loves Python, and uses it as a first-choice tool in perhaps 90% of use cases.
0: https://en.wikipedia.org/wiki/Basic_Linear_Algebra_Subprograms https://en.wikipedia.org/wiki/Basic_Linear_Algebra_Subprogra...
1: https://en.wikipedia.org/wiki/LAPACK https://en.wikipedia.org/wiki/LAPACK
- Veedrac 11y ago> So, invoking numpy as a testament to power of dynamic languages misses a pretty important point. I don't think so. People build Numpy in a different language to the one they expose it in because those languages have different strengths. If Numpy's source languages (including BLAS and LAPACK) were suitable for front-end usage, Python would have never entered the equation. I think it's more a testament that despite the base libraries being so freely accessible, only dynamic languages have actually built front-ends that people want to use. Even Julia is dynamic.