5 ms·

I use python because of Numpy, Scikit and Tensorflow. I don't know of any other languages with libraries as productive as these, so speeding these apps up is a

I use python because of Numpy, Scikit and Tensorflow. I don't know of any other languages with libraries as productive as these, so speeding these apps up is a big win for a lot of people. Also 20% is huge, I look forward to trying it!

wil421 6y ago
The 20% speed up looked like it was for flask and Django. In their benchmarks PyTorch did not have a speed increase.
- austinpena 6y ago
  Likely because pytorch uses C++ under the hood.
throwaway5752 6y ago
Aren't all of those mostly implemented in C or C++ extensions? Not to minimize speeding up the glue code, but I don't know if they will see that large of an improvement.
ehsankia 6y ago
Well that still goes in the "ease-of-use" bucket in my opinion. That being said, those libraries are already highly optimized and all the heavy stuff running on C anyways, so making the Python itself faster won't make that much of a difference in those workflows.
anakaine 6y ago
I'm in 5he same bucket here. My other ecosystem products are built on top of python, so we make use of pandas, numpy, dask, and our vendors own modules (which have taken them 10+ years to put together with a reasonably full team).
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.

wil421 6y ago

The 20% speed up looked like it was for flask and Django. In their benchmarks PyTorch did not have a speed increase.

austinpena 6y ago
Likely because pytorch uses C++ under the hood.

throwaway5752 6y ago

Aren't all of those mostly implemented in C or C++ extensions? Not to minimize speeding up the glue code, but I don't know if they will see that large of an improvement.

ehsankia 6y ago

Well that still goes in the "ease-of-use" bucket in my opinion. That being said, those libraries are already highly optimized and all the heavy stuff running on C anyways, so making the Python itself faster won't make that much of a difference in those workflows.

anakaine 6y ago

I'm in 5he same bucket here. My other ecosystem products are built on top of python, so we make use of pandas, numpy, dask, and our vendors own modules (which have taken them 10+ years to put together with a reasonably full team).

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.