On Thu, Mar 10, 2016 at 11:47 PM, BartC <b...@freeuk.com> wrote: >> have no interest >> in run time speed as they are fully aware that they'll be wasting their >> precious development time, as they know that their code will be waiting >> on the file, the database or the network. What have you failed to grasp >> about that? > > > Tell that to the people who have been working on optimising compilers for > the last couple of decades. Why bother making that inner loop 10% faster, > when the program will most likely be blocked waiting for input anyway? > > You just don't get it. >
Both of you "just don't get" something that the other sees as critically important. Before this thread gets to fisticuffs, may I please summarize the points that probably nobody will concede? 1) Unicode support, intrinsic to the language, is crucial, even if BartC refuses to recognize this. Anything released beyond the confines of his personal workspace will need full Unicode support, otherwise it is a problem to the rest of the world, and should be destroyed with fire. Thanks. 2) Interpreter performance, and the performance of code emitted by a compiler (distinct from "compiler performance" which would be how quickly it can compile code) makes a huge difference to real-world applications, even if MarkL refuses to recognize this. While it doesn't hurt the rest of the world to have a slow implementation of a language, it does _benefit_ the world to have a _faster_ implementation, as long as that doesn't come at unnecessary costs. 3) There is a point at which performance ceases to matter for a given application. This point varies from app to app, but generally is reached when I/O wait time dwarfs CPU usage. A language which has reached this point for the majority of applications can be said to be "fast enough", not because its developers do not care about performance (particularly regressions), and not because further improvements are useless, but because there are other considerations more important than pure run-time speed. 4) Burying the bulk of something away in external API calls is a great way to make the real performance improve, but makes performance *measurement* harder. This matters to benchmarking and to real-world usage in different (almost, but not entirely, contradictory) ways. When people want better performance out of a number-crunching Python program, they have a few options. One is to rewrite their code in C or Fortran or something. Another is to make small tweaks so the bulk of the work is handled by numpy or Cython. A third is to keep their code completely unchanged, but run it under PyPy instead of whatever they were previously using (probably CPython). Generally, rewriting in C/Fortran is generally a bad idea; you pay the price over the whole application, when optimizing a small subset of it would give 99% of the performance improvement. That's why actual CPython byte-code interpretation performance isn't so critical; if we can change 5% of the code so it uses numpy, we keep 95% of it in idiomatic Python, while still having the bulk of the work done in Fortran. CPython has other priorities than performance - not to say that "slow is fine", but more that "slow and dynamic opens up possibilities that fast and static precludes, so we're happy to pay the price for the features we want". ChrisA -- https://mail.python.org/mailman/listinfo/python-list