Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Yes, Python is Slow, and I Don’t Care

hackernoon.com

Post reply on HN
Print view View original

81–90 of 206 posts

Re: Yes, Python is Slow, and I Don’t Care

#81

Post by nhumrich »

jayflux wrote: post #14

I get the point this guy is making, but if you need something parallel for a cpu bound task, throwing more hardware at the problem isn't the most efficient solution if you can just use more cores. For example adding another quad core when the first cpu is only using one core anyway is inefficient and expensive. Right tool for the right job I suppose.

Python does multiprocess very well. You can easily use all cores on your machine. Pythons main "disadvantage" is threading because of the GIL. But each process gets its own GIL. So when you multi process, your not limited to one core.

Re: Yes, Python is Slow, and I Don’t Care

#82

Post by Newtopian »

carlmr wrote: post #56
scarface74 wrote: post #20

I was all ready to savage his opinion after reading the headline but I agree looking at my architecture that I designed for the company I work for, CPU isn't the bottleneck. Every time I try to increase performance by multi threading as much as possible, the databases start screaming. On the other hand, the idea that dynamic languages are more productive than static languages are laughable. Statically type languages…

>On the other hand, the idea that dynamic languages are more productive than static languages are laughable. Statically type languages prevent a lot of bugs and allow for a lot of automated provably correct refactorings that simple cannot be done with a statically typed languages. You can't even reliably do a "find usages" of classes using a dynamically typed languag Exactly, I get quick and precise code completion,…

If you annotate your types in python with the appropriate type hinting comments I find I get quite satisfactory code completion and error detection from my IDE (pycharm). Perhaps not as much as VisualStudio might do for me with C#, true, but then again I don't use them for the same thing either.

Each task has it's set or preferred tools, to write a quick command line tool to bridge a gap between two systems and automate our workflow a bit further python is just perfect for me and much more productive than C#. However to create a system with a team of dozens spanning the whole skill gamut I feel much more comfortable having the compiler as an active member of my team policing the architectural vision for us. In which case C#/Java will win hands down.

If however speed and responsiveness are prime worries then I'll roll up my sleeves and bring C/C++ in. sure my productivity will take a hit, it will likely be harder to maintain as well but if this effort makes the difference for my customers in their productivity then it's well worth the investment.

Often times the final system will be a mix of all these technologies, each used where it's strength shines to maximise their impact.

Yet the technology is worthless when faced with inadequate code structure and system architecture. Coupled convoluted code will be a PITA no matter the language used.

Re: Yes, Python is Slow, and I Don’t Care

#83

Post by LeonidasXIV »

hellofunk wrote: post #78
rockostrich wrote: post #34

Earlier quoted context omitted.

But with a statically typed language, you don't need to go through that code -> launch -> test cycle as often because everything is type-safe.

You can say that something is a floating point number (a type) but what if that something must be between zero and one? A type can't tell you that. Typing has its place but the idea that it catches all bugs at compile time certainly isn't true; the cycle of running the app itself, running its tests, is just as important for statically-typed code as dynamically typed. Languages that have a sophisticated contract syste…

> You can say that something is a floating point number (a type) but what if that something must be between zero and one? A type can't tell you that.

Of course it can. The idea behind a decent type system is to make illegal states unrepresentable. You define a type which contains a value between 0 and 1 (lets name it `probability`) and make a function `float -> probability` which checks the range. That way, everytime you'll see `probability` in your code, you will know it is in the right range.

The problem with spec is that it can only verify what it sees on run time, whereas a static type system by definition has 100% coverage over your entire program.

Re: Yes, Python is Slow, and I Don’t Care

#84

Post by icebraining »

hellofunk wrote: post #78
rockostrich wrote: post #34

Earlier quoted context omitted.

But with a statically typed language, you don't need to go through that code -> launch -> test cycle as often because everything is type-safe.

You can say that something is a floating point number (a type) but what if that something must be between zero and one? A type can't tell you that. Typing has its place but the idea that it catches all bugs at compile time certainly isn't true; the cycle of running the app itself, running its tests, is just as important for statically-typed code as dynamically typed. Languages that have a sophisticated contract syste…

what if that something must be between zero and one? A type can't tell you that.

Actually, it can, using dependent types :) I'm a Python fan, but Type-Driven Development with Idris has been a very interesting read.

Re: Yes, Python is Slow, and I Don’t Care

#86

Post by hellofunk »

LeonidasXIV wrote: post #83
hellofunk wrote: post #78

Earlier quoted context omitted.

You can say that something is a floating point number (a type) but what if that something must be between zero and one? A type can't tell you that. Typing has its place but the idea that it catches all bugs at compile time certainly isn't true; the cycle of running the app itself, running its tests, is just as important for statically-typed code as dynamically typed. Languages that have a sophisticated contract syste…

> You can say that something is a floating point number (a type) but what if that something must be between zero and one? A type can't tell you that. Of course it can. The idea behind a decent type system is to make illegal states unrepresentable. You define a type which contains a value between 0 and 1 (lets name it `probability`) and make a function `float -> probability` which checks the range. That way, everytime…

You are talking about a function (at runtime), not a type, verifying the range. And you can do that in any language, regardless of its stance on typing.

Re: Yes, Python is Slow, and I Don’t Care

#87

Post by hellofunk »

icebraining wrote: post #84
hellofunk wrote: post #78

Earlier quoted context omitted.

You can say that something is a floating point number (a type) but what if that something must be between zero and one? A type can't tell you that. Typing has its place but the idea that it catches all bugs at compile time certainly isn't true; the cycle of running the app itself, running its tests, is just as important for statically-typed code as dynamically typed. Languages that have a sophisticated contract syste…

what if that something must be between zero and one? A type can't tell you that. Actually, it can, using dependent types :) I'm a Python fan, but Type-Driven Development with Idris has been a very interesting read.

Yes but there are no mainstream or production-ready dependently typed languages, so I didn't mention that. But I wouldn't be surprised if dependent typing really is going to be the distant future of programming languages. Perhaps not too distant.

I also wouldn't be surprised if Clojure tends to do surprising things in this area with taking Clojure.spec more to the compilation stage; some of the most interesting research into type systems has actually be done by lispers (i.e. Typed Racket, Core.Typed) and there is active interest in it among the Clojure community.

Re: Yes, Python is Slow, and I Don’t Care

#88

Post by classybull »

pg314 wrote: post #54
agentgt wrote: post #29

Unless we are talking like circa 1999 I don't think I have heard a complaint yet that Python is slow. I'm curious who or where the author heard that from (not specifically the people themselves but the domain they are in). What I have heard complaints about Python are (and I don't agree with all these points): * Its not statically typed * The python 2/3 compatibility * It has some design flaws: GIL, variable assignin…

> I'm curious who or where the author heard that from (not specifically the people themselves but the domain they are in). In the telecom domain, I've dealt with data big enough that Python wasn't really feasible. Think 100 of millions of records in CSV format that need to be parsed and processed. Doing that in Python is going to be painful.

Python is insanely fast at data processing and analysis because it has very fast libraries.

As a matter of fact, don't know if you've heard, but data processing it kind of like.. Python's thing...

Re: Yes, Python is Slow, and I Don’t Care

#89

Post by dahart »

agentgt wrote: post #29

Unless we are talking like circa 1999 I don't think I have heard a complaint yet that Python is slow. I'm curious who or where the author heard that from (not specifically the people themselves but the domain they are in). What I have heard complaints about Python are (and I don't agree with all these points): * Its not statically typed * The python 2/3 compatibility * It has some design flaws: GIL, variable assignin…

I'd agree with all the complaints you list, and I love Python, but it is definitely kinda slow. I'd put the speed of python below several of the items on your list in terms of priorities I care about.

I've done a lot of image processing in Python using libraries like PIL, numpy and opencv. Doing per-pixel operations is extremely easy in PIL - improving my dev time, but CPU wise the slowest of the bunch. I love prototyping that way, but I have to move to numpy or opencv or another language to speed it up. A recent program to do a slightly complicated color transform on a 512x512 image was taking me over 60 seconds with PIL. It was 5-10 seconds in JavaScript, and less than 1 second using numpy.

Re: Yes, Python is Slow, and I Don’t Care

#90

Post by marcosdumay »

hellofunk wrote: post #73
abhirag wrote: post #59

Earlier quoted context omitted.

"the idea that dynamic languages are more productive than static languages are laughable." -- being statically typed or dynamically typed comes with its own set of tradeoffs and what a person is more productive in is a highly subjective matter. Lispers are more productive in Lisp than Haskell and vice versa. "Statically type languages prevent a lot of bugs and allow for a lot of automated provably correct refactoring…

I recently saw an analysis of frequency of bugs per language according to a breakdown of Github repositories, using issues and branches as a way to quantify bug reports. It was very interesting to see that Clojure projects were among the least buggy of all languages represented. The report looked at a variety of factors to explain "bugginess", including typing and LOC, among other things. The conclusion in Clojure's…

That idea is old enough to have entered the original edition of The Mythical Man-Month.

That said, I have never seen any study like this where I didn't have some serious disagreement over methodology or conclusions. (Ok, except for that one on Peopleware.) It is a hard subject, and running a study over "the population of GitHub" is problematic by itself.

Post reply on HN