4 ms·

20% faster is nothing. You want at least a magnitude faster to justify the cost and risk of switching. The Python language is already 30 years old, and it wasn

by hhas01 6y ago

20% faster is nothing. You want at least a magnitude faster to justify the cost and risk of switching. The Python language is already 30 years old, and it wasn’t even the cutting-edge in imperative language design (<koff>Smalltalk, Lisp</koff>) back then. It’s positively antiquated now. I’ve never understood this tunnel-vision obsession with endlessly chasing ever-diminishing returns. It’s Zawinski's Law of Software by way of Greenspun’s Tenth Rule, and a fundamental failure of courage. Learn the lessons from both the good and bad of what’s been done before, and move on. A better long-term answer would be to design a much faster, more efficient language for running Numpy, Scikit, and Tensorflow, then port those libraries over to that. If that language turns out to be good for other things too, then great. If not, let a thousand flowers bloom. There is a much larger learning opportunity here, to get a whole lot better at migrating extant code bases from an old, popular, dead-ended language to a new, upcoming one. But it’s like finding your way to Carnegie Hall: it takes practise, practise, practise.

newen 6y ago
I agree. Almost all arguments in favor of Python is about sunk cost. Not much about the actual language is appealing compared to modern languages.
- hhas01 6y ago
  Ah, sunk costs. Where the future goes to die. And I say this as a 20-year Python user myself, ’cos while it has scratched many itches and continues to do so, I am not the least bit sentimental about it. The best compliment would be to kill it with something far better, that steals all its good parts and replaces the rest.
- coldtea 6y ago
  >Almost all arguments in favor of Python is about sunk cost. Not much about the actual language is appealing compared to modern languages. Well, I, for one, use Python because "the actual language is appealing compared to modern languages".
- dragonwriter 6y ago
  > Almost all arguments in favor of Python is about sunk cost. I think you are confusing ecosystem and other established advantages with sunk costs, they are different things. It's true that (from the perspective of the people who built them), those advantages are the products of sunk costs, but the argument is about the ongoing value delivered, not the sunk cost involved in delivering it. > Not much about the actual language is appealing compared to modern languages. Even if that was true, many of the actual languages competing with Python are less modern by any measure, and in any case so what? Does it matter when choosing a langauge if an advantage is produced by the abstract design of a language, it's ecosystem, or the peculiarities of the available implementations? Advantages are advantages, value is value. Sure, if you are considering how to promote a “modern” language against Python, it's important to distinguish whether your current barrier is the design of your language or Python’s ecosystem to know how to direct your efforts, but if you aren't a tool evangelist and instead are choosing a language for a project, I don't see that it matters why Python is a net advantage, as long as it is.
  - hhas01 6y ago
    “the argument is about the ongoing value delivered” Which is an admirable sentiment… but the title of this thread is not “Python: still doing useful work” but “Python: now 20% faster”, and being ridiculously self-congratulatory about this when the correct response is to laugh at the silly pointless frivolity of it. Trying to make Python fast is a fool’s errand, because Python is slow by design. A useful argument would be that Python is faster overall at solving various real-world problems than current alternatives; but that’s not the popular argument being made, because the population fixates on minutiae instead of overall perspective.
    - dragonwriter 6y ago
      > Which is an admirable sentiment… but the title of this thread is not “Python: still doing useful work” but “Python: now 20% faster” No, it's actually, “Pyston v2: 20% faster Python". But...so what? > and being ridiculously self-congratulatory about this when the correct response is to laugh at the silly pointless frivolity of it For the same reasons Python is often a valuable choice, a faster Python is a valuable option. > Trying to make Python fast is a fool’s errand, because Python is slow by design. Python is not slow by design, though it's slow because it's not fast by design. But that doesn't mean it's not useful to have a faster Python, only that there are likely to be limits and trade-offs involved in doing that. > A useful argument would be that Python is faster overall at solving various real-world problems than current alternatives; but that’s not the popular argument being made Yes, actually, it is. It's not the message of the Pyston v2 release blog entry, but then that blog entry isn't making an argument in the debate that you seem to want everything to be about.
attractivechaos 6y ago
Interesting that you are down voted. I agree with you that 20% faster is really nothing in comparison to the many new languages. I was saddened by the path Python3 chose. If compatibility was already broken at the time, they should have designed something with performance in mind from the beginning. The V8 javascript engine was there. We knew things could get >10X faster with JIT. Python is too big to die, but it is an inferior programming language in many ways.
- hhas01 6y ago
  “Interesting that you are down voted.” Doesn’t bother me; I’ve got points to spare. What downvoters haven’t got, it seems, is any arguments.
mlyle 6y ago
> 20% faster is nothing. You want at least a magnitude faster to justify the cost and risk of switching. Eh. If newer versions of cpython end up 20% faster, eventually most things will end up running on those newer versions. It may take years for almost everything to drift to newer versions, but there's a noticeable performance benefit we all realize over time. > Learn the lessons from both the good and bad of what’s been done before, and move on. A better long-term answer would be to design a much faster, more efficient language for running Numpy, Scikit, and Tensorflow, then port those libraries over to that. If that language turns out to be good for other things too, then great. If not, let a thousand flowers bloom. Python's great at running numpy, scikit, and tensorflow. It's not the bottleneck, because these are largely native libraries-- achieving something "much faster" and "more efficient" for this are doubtful. The benefits of Python are that it A) has a huge ecosystem, B) it's relatively polished and expedient to write code in, and C) there's a ton of people who know it. These are not easy things to create somewhere else, and there's no guarantee that the set of tradeoffs you choose will leave you in a better place afterwards. The biggest downside of Python is that if you want to get a lot of concurrency or performance for Python code (instead of things like numpy, scikit, and tensorflow), you get pushed into the edges of the Python ecosystem, where you only get a portion of A's advantage (but still largely realize B & C).

by hhas01 6y ago

newen 6y ago

I agree. Almost all arguments in favor of Python is about sunk cost. Not much about the actual language is appealing compared to modern languages.

hhas01 6y ago
Ah, sunk costs. Where the future goes to die. And I say this as a 20-year Python user myself, ’cos while it has scratched many itches and continues to do so, I am not the least bit sentimental about it. The best compliment would be to kill it with something far better, that steals all its good parts and replaces the rest.
coldtea 6y ago
>Almost all arguments in favor of Python is about sunk cost. Not much about the actual language is appealing compared to modern languages. Well, I, for one, use Python because "the actual language is appealing compared to modern languages".
dragonwriter 6y ago
> Almost all arguments in favor of Python is about sunk cost. I think you are confusing ecosystem and other established advantages with sunk costs, they are different things. It's true that (from the perspective of the people who built them), those advantages are the products of sunk costs, but the argument is about the ongoing value delivered, not the sunk cost involved in delivering it. > Not much about the actual language is appealing compared to modern languages. Even if that was true, many of the actual languages competing with Python are less modern by any measure, and in any case so what? Does it matter when choosing a langauge if an advantage is produced by the abstract design of a language, it's ecosystem, or the peculiarities of the available implementations? Advantages are advantages, value is value. Sure, if you are considering how to promote a “modern” language against Python, it's important to distinguish whether your current barrier is the design of your language or Python’s ecosystem to know how to direct your efforts, but if you aren't a tool evangelist and instead are choosing a language for a project, I don't see that it matters why Python is a net advantage, as long as it is.
- hhas01 6y ago
  “the argument is about the ongoing value delivered” Which is an admirable sentiment… but the title of this thread is not “Python: still doing useful work” but “Python: now 20% faster”, and being ridiculously self-congratulatory about this when the correct response is to laugh at the silly pointless frivolity of it. Trying to make Python fast is a fool’s errand, because Python is slow by design. A useful argument would be that Python is faster overall at solving various real-world problems than current alternatives; but that’s not the popular argument being made, because the population fixates on minutiae instead of overall perspective.
  - dragonwriter 6y ago
    > Which is an admirable sentiment… but the title of this thread is not “Python: still doing useful work” but “Python: now 20% faster” No, it's actually, “Pyston v2: 20% faster Python". But...so what? > and being ridiculously self-congratulatory about this when the correct response is to laugh at the silly pointless frivolity of it For the same reasons Python is often a valuable choice, a faster Python is a valuable option. > Trying to make Python fast is a fool’s errand, because Python is slow by design. Python is not slow by design, though it's slow because it's not fast by design. But that doesn't mean it's not useful to have a faster Python, only that there are likely to be limits and trade-offs involved in doing that. > A useful argument would be that Python is faster overall at solving various real-world problems than current alternatives; but that’s not the popular argument being made Yes, actually, it is. It's not the message of the Pyston v2 release blog entry, but then that blog entry isn't making an argument in the debate that you seem to want everything to be about.

attractivechaos 6y ago

Interesting that you are down voted. I agree with you that 20% faster is really nothing in comparison to the many new languages. I was saddened by the path Python3 chose. If compatibility was already broken at the time, they should have designed something with performance in mind from the beginning. The V8 javascript engine was there. We knew things could get >10X faster with JIT. Python is too big to die, but it is an inferior programming language in many ways.

hhas01 6y ago
“Interesting that you are down voted.” Doesn’t bother me; I’ve got points to spare. What downvoters haven’t got, it seems, is any arguments.

mlyle 6y ago

> 20% faster is nothing. You want at least a magnitude faster to justify the cost and risk of switching. Eh. If newer versions of cpython end up 20% faster, eventually most things will end up running on those newer versions. It may take years for almost everything to drift to newer versions, but there's a noticeable performance benefit we all realize over time. > Learn the lessons from both the good and bad of what’s been done before, and move on. A better long-term answer would be to design a much faster, more efficient language for running Numpy, Scikit, and Tensorflow, then port those libraries over to that. If that language turns out to be good for other things too, then great. If not, let a thousand flowers bloom. Python's great at running numpy, scikit, and tensorflow. It's not the bottleneck, because these are largely native libraries-- achieving something "much faster" and "more efficient" for this are doubtful. The benefits of Python are that it A) has a huge ecosystem, B) it's relatively polished and expedient to write code in, and C) there's a ton of people who know it. These are not easy things to create somewhere else, and there's no guarantee that the set of tradeoffs you choose will leave you in a better place afterwards. The biggest downside of Python is that if you want to get a lot of concurrency or performance for Python code (instead of things like numpy, scikit, and tensorflow), you get pushed into the edges of the Python ecosystem, where you only get a portion of A's advantage (but still largely realize B & C).