[Python-Dev] FAT Python (lack of) performance

[Stephen J. Turnbull]

Nick Coghlan writes:
 > On 26 January 2016 at 17:16, Stephen J. Turnbull <stephen at xemacs.org> wrote:

 > > Our universities are doing an awful job at getting "big picture
 > > thinking" across to our students.
 > 
 > That problem isn't specific to Japan - I'm not aware of *anywhere*
 > that does a particularly good job of teaching developers not to get
 > tribal about their programming language choice,

But that's a different issue.  The approach that Naoki describes isn't
"tribal", in fact it's the exact opposite: it's an attempt to base
such decisions on strictly objective measures.

 > and instead evaluate their options based on their specific problem,
 > the team that will be working on it, and the pre-existing problem
 > solving tools available in that ecosystem.

One of which is the language itself, and the team's experience with
it.  "We're a C++/Java/Python/Ruby/Brainf!ck/assembler/COBOL shop"
isn't a bad heuristic in most cases -- outside of research and/or "we
also walk dogs" generalist consultancies -- especially when you're
under pressure from the bean-counting department to reduce costs.
That heuristic is hard to distinguish from "tribalism", though.

AFAICT, in fact, the generalists (including massive entities like IBM
and Google, as well as companies like Red Hat and cooperatives like
Debian) are quite good at the kind of evaluation you describe.

And Python has been quite good at targeting the kinds of improvements
that make it appealing to people who can and do do that kind of
evaluation, in more and more areas.

 > While improving those kinds of metrics isn't a *reason* to do
 > anything, it does count as an added bonus when it comes as a
 > beneficial side effect of working on something else (such as the
 > function specialisation infrastructure underpinning Victor's
 > optimiser project).

Sure, but that's a "have your cake and eat it too" situation.
Nobody's going to complain about that!

If Naoki -- or anybody else -- wants to work on optimizations enabled
by FAT Python, more power to them, I say.  I just would like to see
them reviewed with the goal of making Python a better language for
solving a wide variety of problems, rather than strictly focusing on
benchmarks.  If the benchmarks can be improved without closing off
potential syntax improvements or restricting the domain of algorithms
(cf Terry's comment), wonderful!

I thought Chris's point about efficient algorithms that would be hard
to implement correctly in other languages but are easy to do in Python
*because* of Python's carefully crafted, but not always maximally
speedy, semantics was especially apropos here.  Of course his claim
that Python is faster than C is tongue in cheek, and a caching version
of fibonacci wouldn't be that hard to write in C, and an iterative
version even easier.  But others have pointed out many other syntaxes
(comprehensions, generators, yield from, and so on) that put together
often make efficient computation TOOWTDI.  That, to me, is The Python
Advantage.