Looks to me like the age-old standard problem of using higher abstractions and expecting the machinery underneath to be smart enough to deploy it optimally to the underlying hardware.
For similar instances of the same story, see: compilers, java, haskell, cuda, etc...
News at 10: you always pay a performance price when you use high level abstractions, aka you can't have your lunch and eat it too.
Theoretically you are correct, but taking the skills of the user into account, I think the very opposite is true. In practice, hardly anyone has the skills to actually implement anything with high performance anymore (especially in numerics) and it is thus (in most cases ) more performant to simply stick to stuff like numpy.
In most cases, "working code, fast" is more important than "fast working code".
> "working code, fast" is more important than "fast working code"
That depends on who you ask. If you ask the people who are managing the schedules, whose job reviews and bonuses are tied to meeting a specific date? Yes, absolutely, performance is a "nice to have" as long as the dates don't "slip". Now ask the users, and the number one complaint I hear most often is "why is this thing so damned slow?"
> Now ask the users, and the number one complaint I hear most often is "why is this thing so damned slow?"
Good point. My viewpoint is rather focused on numerical linear algebra, since I worked there and the article is about it. If you skim through the paper mentioned, in the article you can e.g. compare numpy and armadillo. You will see that the speedups from using a (arguably) much more complex C++ framework instead of numpy are marginal and will not be visible for the user. The increased production/maintenance costs due to a more complex code, will be visible for the user.
In other words, we need an optimizing linear algebra compiler to compile high-level abstractions to efficient BLAS/MKL calls, instead of just interpreting them for a literal translation. For example, in the case of NumPy, when given x = inv(A) @ b it should attempt to optimize it as x = A \ b under safe conditions. So, why not the best of both worlds?
By machinery do you mean compiler? The Java JIT has become extremely, extremely fast. All those $B that have collectively put into it have yielded reaped rewards. It is of course challenging to have your lunch and eat it too if you're not aware of the best way to order it.
For similar instances of the same story, see: compilers, java, haskell, cuda, etc...
News at 10: you always pay a performance price when you use high level abstractions, aka you can't have your lunch and eat it too.