Yes, Python Is Slow, and I Don’t Care
hackernoon.com
Yes, Python Is Slow, and I Don’t Care
1–9 of 9 posts
Re: Yes, Python Is Slow, and I Don’t Care
#2There seems to be an unstated assumption that dynamic types cause slower code, but aid productivity. But I find static types greatly help me reason about a program, and when doing python, I resort to extensive documentation of function arguments and return values, as a poor substitute for static types.
Re: Yes, Python Is Slow, and I Don’t Care
#3a discussion, https://news.ycombinator.com/item?id=14024486
Re: Yes, Python Is Slow, and I Don’t Care
#4Python is actually pretty fast for some things. The string and I/O operations are all written in decently fast C, so some types of problems are actually a good fit for python, speed wise. It won't beat a well written java programming, but you can come a long way with very little code.
Pointless things like this comes to mind: https://github.com/juditacs/wordcount/blob/master/README.md
Two persons in the #guile irc channel tried hard to make a guile version run faster than the python3 version, and after a long time got it on par with it, and guile2.2 is usually about 3-5x faster than python in my completely unscientific benchmarks.
Re: Yes, Python Is Slow, and I Don’t Care
#5your users care
Re: Yes, Python Is Slow, and I Don’t Care
#6Go is just as fast, easy, and clean to write and is leagues faster.
Re: Yes, Python Is Slow, and I Don’t Care
#7There seems to be an unstated assumption that dynamic types cause slower code, but aid productivity. But I find static types greatly help me reason about a program, and when doing python, I resort to extensive documentation of function arguments and return values, as a poor substitute for static types.
I am a strong believer in static typing. But I enjoy dynamic types in, for example, Lisp for solving certain problems.
When working on a large codebase maintained over years and years, I appreciate static types -- especially when it comes to using refactoring tools, like in Eclipse or similar IDEs.
Re: Yes, Python Is Slow, and I Don’t Care
#8>It’s more important to get stuff done than to make it go fast.
Hmpth. Why must I choose? Python is very poorly - even perversely - designed from a performance perspective. I suspect the only reason we use it is because it was an early offering amongst "human-factors-oriented languages", and it now has the momentum. But there's no intrinsic conflict - there exist languages now that are arguably intrinsically better along every conceivable metric.
Re: Yes, Python Is Slow, and I Don’t Care
#9There seems to be an unstated assumption that dynamic types cause slower code, but aid productivity. But I find static types greatly help me reason about a program, and when doing python, I resort to extensive documentation of function arguments and return values, as a poor substitute for static types.
Yea seriously. I'm kind of surprised to see this here: outside of places that are absolutely performance-critical, my complaint and most of the complaints about Python that I hear from people who know what they're talking about is that doing a medium to large project in it is a lot more difficult from the perspective of code readability. This gets multiplied by a million if you're working with engineers who aren't super great, or who are overall great but have a couple bad habits. I'm currently in a Python codebase with ~4 engineers on it, and even with this relatively small team Python is permissive enough to let them do some pretty horrifying things. Dealing with these choices usually cost us far more eng time than the two minutes spent to design something well would have cost them.
I like the language overall, in part because it allows mediocre engineers to become quickly productive and you can't always hire 100% excellent engineers. But this main downside is in fact a downside.