The model that has worked amazingly well for Python (and Matlab, and R, and probably a number of others) is to encapsulate the hard stuff - say BLAS for linear algebra, or GraphLab for loopy belief propagation - together with all the amazingly tuned shared memory support, concurrency, parallelism, data locality, whatnot - in C-level modules written by expert people and expose a powerful API that doesn't expose you to the nontrivialities of concurrent or parallel programming. If you spend lots of time in the driver code, you most certainly won't be happy with Python, R, or Matlab, but then Cython (and possibly Numba at some point) help push this "lots of time" further and further down.
"all else fails" is the starting point of pretty much everyone doing real work. What's your alternative here? Most of the time, specialized libraries will be both more convenient and more efficient than rolling your own with fine-grained concurrency/parallelism in Java or PyPy.
The paper "Evaluating the Design of the R Language" [1] is a great read on this subject. A key figure they found (p. 17 end of top paragraph) is that in a realistic corpus of work, only 22% of compute time was spent in C/Fortran "kernels" as opposed to R code. So the effectiveness of the "two language" design is somewhat limited, even for scientific workloads where kernels like BLAS, FFTs, etc. apply (and there are many areas where they don't really).
R is (according to that study) 500x slower than C. But let's say that we have a language that is just 10x slower than medium-optimized C. In that case, a 100sec. program run spends 78sec. in that language and 22sec. in that compute kernel.
Now imagine that you speed up the language by 2x but have to forego the use of efficient C code. Now, the program would spend 39sec. outside the "kernel" stuff and 110sec. in the stuff that used to be a C library but had to be reimplemented.
Then again, even if you consider a "one language" design such as Cython (where you can write code that's between Python and C, both convenience-wise and performance-wise), performance-sensitive code looks markedly different than straighforwardly writing down a program.
This is why the "two language" design survives, even while you see very usable work in pure-C++ or even pure-Java.
Comments
The model that has worked amazingly well for Python (and Matlab, and R, and probably a number of others) is to encapsulate the hard stuff - say BLAS for linear algebra, or GraphLab for loopy belief propagation - together with all the amazingly tuned shared memory support, concurrency, parallelism, data locality, whatnot - in C-level modules written by expert people and expose a powerful API that doesn't expose you to the nontrivialities of concurrent or parallel programming. If you spend lots of time in the driver code, you most certainly won't be happy with Python, R, or Matlab, but then Cython (and possibly Numba at some point) help push this "lots of time" further and further down.
"all else fails" is the starting point of pretty much everyone doing real work. What's your alternative here? Most of the time, specialized libraries will be both more convenient and more efficient than rolling your own with fine-grained concurrency/parallelism in Java or PyPy.
The paper "Evaluating the Design of the R Language" [1] is a great read on this subject. A key figure they found (p. 17 end of top paragraph) is that in a realistic corpus of work, only 22% of compute time was spent in C/Fortran "kernels" as opposed to R code. So the effectiveness of the "two language" design is somewhat limited, even for scientific workloads where kernels like BLAS, FFTs, etc. apply (and there are many areas where they don't really).
[1] http://r.cs.purdue.edu/pub/ecoop12.pdf
R is (according to that study) 500x slower than C. But let's say that we have a language that is just 10x slower than medium-optimized C. In that case, a 100sec. program run spends 78sec. in that language and 22sec. in that compute kernel.
Now imagine that you speed up the language by 2x but have to forego the use of efficient C code. Now, the program would spend 39sec. outside the "kernel" stuff and 110sec. in the stuff that used to be a C library but had to be reimplemented.
Then again, even if you consider a "one language" design such as Cython (where you can write code that's between Python and C, both convenience-wise and performance-wise), performance-sensitive code looks markedly different than straighforwardly writing down a program.
This is why the "two language" design survives, even while you see very usable work in pure-C++ or even pure-Java.