Hacker News Reader

Comment by montebicyclelo | Hacker News Reader

The code from this study is here: https://github.com/greensoftwarelab/Energy-Languages

From looking at the code snippets, a big issue with this study becomes clear - it doesn't reflect how languages like Python are used in practice.

In practice, the "hot loops" of Python are in c/c++/fortran/cython/numba/... i.e. Python code usually makes use of a vast ecosystem of optimized science/maths/data science libraries. Whereas the study code is mainly using pure Python.

It's an issue with the methodology that the programs are written specifically for this study; creating an artificial situation.

View on HN

> In practice, the "hot loops" of Python are in c/c++/fortran/cython/numba/

This is a vast overgeneralization. You'll find these optimized loops in optimized packages, done by engineers with enough experience. In practice, there is a lot of slow running code. And that includes "optimized" code that runs on numpy or similar but simply doesn't lend itself very well to being optimized in that way.

Python is convenient for short scripts, but very slow to execute.

That is a really good point about Python being a connector language and internal API implementations done in C/C++/Fortran/etc... It kind of makes me question the entire premise of this paper.

That may be the case for numerical code. However, a big niche for Python (if not the biggest one) is web services. How common is calling C++/Fortran code in a Django/Flask project? Those projects seem to have layers upon layers of pure Python code, with metaprogramming and whatnot.

Additionally, going through the FFI from C++ to Python and back to C++ has a cost. Eliminating this overhead was one of the motivations behind Julia.

Even in web services, the computationally-intensive bits are usually the database queries, which are also not handled by pure Python.

> In practice, the "hot loops" of Python are in c/c++/fortran/cython/numba/

How would this be comparing apples to apples? The paper’s main objective is to compare programming languages in their own native calls. It is like properly translating the Bible or Shakespeare to other languages: some translations will be more textual than others, loosing all the nuances, specially if compared to the original transcript.

If you have python glue calls to other processes written in other languages, then you would be creating noisy in results. It is not the purpose of the paper at all, and it is outside of its scope.

Forgive my pedantry but the ecosystem is not the language. Nor is practice. Ad absurdum, you could include the hardware pythonists usually employ.

If you use python as glue, it should be compared to other languages used as glue.

Is it not fair enough to use ubiquitous libraries in the code for this test? E.g. look at the n bodies code.. someone trying to write efficient Python code would be using NumPy at the very least (and possibly Numba).

NumPy has lots of C calls, and the functionality has to be implemented entirely with the language features. What you are suggesting is outside the scope of the paper.

> It's an issue with the methodology that the programs are written specifically for this study…

Not correct — the programs were taken from the benchmarks game.

Reply on news.ycombinator.com