Author here. Surprised to see this toping HN. Appreciate all the feedback. Let me know if you have any questions.
Yes, Python is Slow, and I Don’t Care
71–80 of 206 posts
Re: Yes, Python is Slow, and I Don’t Care
#72"It used to be the case that programs took a really long time to run. CPU’s were expensive, memory was expensive. Running time of a program used to be an important metric." As hardware gets faster we give it new tasks that could not be achieved before. Like rendering high resolution stereoscopic images using physically based shading at 90 FPS on relatively cheap consumer hadware (VR). There are still quite a lot of c…
Yeah, also we have a lot of code that a lot of engineers in our company run. Some of it takes hours instead of a few minutes to run, because it's a bunch of slowness combined. Sure you can say the engineer doesn't have to watch. But sometimes you need this result, and can't do much else until it's there. Doing a few loops at a few hours at a time is very time consuming.
Being lazy about slowness is bad in the long run, if you or your customers waste inordinate amounts of time, because one of your devs didn't want to think.
Sure you should optimize from the bottleneck, look at hot path, measure where optimization makes sense. But using tools that make some stuff 10x faster without much effort is not premature optimization. It's just not being stupid.
Re: Yes, Python is Slow, and I Don’t Care
#73I 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…
"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 case was that the very low line count necessary to write Clojure programs was vastly more influential on bugginess than for languages that were statically typed.
And I suppose that's true: a language that requires you write very little code is going to produce programs that are easier to write (and thus maintain), regardless of whether it is statically or dynamically typed.
Re: Yes, Python is Slow, and I Don’t Care
#74Earlier quoted context omitted.
'Dynamic languages' is too often used as a shorthand, or interchangeable with 'scripting language', as here. There are a ton of more relevant language features when it comes to productivity, automatic memory management being the biggest IMHO. Interpreted vs compiled makes a difference too because your code->launch->test cycle can be so fast. But I agree, I'm a huge Python fan and even though I appreciate not having t…
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.
Uh ... no. Type safety is rarely a problem from my personal experience (YMMV) in code dev. The issues I run across have to do with whether or not the code is an accurate reflection of the algorithm in question, or even if the algorithm itself is correct, if core assumptions are correct, dealing with corner cases, etc. Types rarely have anything constructive to add to this mix, regardless of whether or not I am working in a weakly/non-typed language, or strongly typed language.
I personally tend to do something much closer to TDD, and break my code out so I test each part with its own test rig. So I see when I do dumb things that need re-work. Again, typing is pretty much never an issue there.
While this is all anecdotal, I personally have found that enforcing boilerplate type defs actually increases my coding error rate. More LOC gives you more opportunities for errors.
FWIW, Julia (http://julialang.org) is IMO Python done right, and it is strongly typed. But done in such a way as to not actually get in your way most of the time. Like Python it has a great REPL, fantastic FFI, rapidly growing module list, very active development. Unlike Python, it has no issues with whitespace[1], is compiled (JIT for now, though static is planned from what I understand), is very fast, has multiple dispatch and a strong typing system.
The real point the article was making is, programmer time is the most valuable thing to optimize for. I completely agree with this, even though I disagree that Python is the right tool for (most) every job.
There are better tools IMO, which allow me to be far more productive, and spend as little time as possible on worrying about types ... which are rarely ever a concern for me.
I thought his comment about string processing was interesting, though he completely ignored Perl in the mix. I've found string processing in Perl to be almost trivial. Its harder (far more verbose boilerplate) in Python, and gets worse in other languages. Perl6 lets you embed grammars and write parsers without resorting to external modules (Marpa::* in Perl5). Takes building string processing, parsers, etc. to a whole new level, while making you even more productive.
But, as the author had noted, he is a pythonista. Everyone has their biases (including me). I want to code correctly quickly, and not have things that shouldn't get in my way, get in my way. Including type systems, massive boilerplate/odd syntax rules, etc.
[1] It is 2017 ... structure by indentation is somehow, still a thing. It shouldn't be IMO.
Re: Yes, Python is Slow, and I Don’t Care
#75Unless 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…
Author here. I mostly work with a lot of Java devs. They are hesitant to try python because "java is faster". Some use the static typing excuse, but oddly, the most common reason I hear people wont do python is because its "too slow".
Perhaps I live in a weird bubble, but that's the motivation behind the article.
Re: Yes, Python is Slow, and I Don’t Care
#76Unless 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…
> * Its not statically typed
Yes, that's why we use it.
Re: Yes, Python is Slow, and I Don’t Care
#77The article could be titled: "Yes, Python is Slow To Refactor and Maintain, and I Still Don't Care".
I never understand why dynamic language enthusiasts primarily focus on new code only. You have to discuss all sides of increased or decreased productivity to make a rational argument.
Re: Yes, Python is Slow, and I Don’t Care
#78Earlier quoted context omitted.
'Dynamic languages' is too often used as a shorthand, or interchangeable with 'scripting language', as here. There are a ton of more relevant language features when it comes to productivity, automatic memory management being the biggest IMHO. Interpreted vs compiled makes a difference too because your code->launch->test cycle can be so fast. But I agree, I'm a huge Python fan and even though I appreciate not having t…
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 system* (like Clojure's Clojure.spec library) have a bit of a leg up in my opinion. You can much more precisely explain and control and test for the specifics of all values flowing through your system well beyond merely what type they are.
-- * Clojure's devs don't refer to spec as a contract system because it is quite a bit more versatile than that, and some are actually using it for compile-time checks, compile-time generative testing, and other nifty things that aren't covered by a "contract" system.
Re: Yes, Python is Slow, and I Don’t Care
#79This keeps getting posted, and while it makes some valid points, it's a lot of handwaving. Arguably, other languages can get code out faster depending on the dev, language, etc.
Agreed. Things that are handwaved include:
1) Performance can be a genuine requirement of the product, i.e. if it's not fast enough, it doesn't ship. You can't ship faster and cheaper by sacrificing the thing you need to ship (well, you can, but then you're shipping a different product, not meeting the same requirements sooner; it's no different than cutting a feature).
2) Many processes can't be horizontally scaled in an efficient way, period. Not because the programmer is ignorant of some cool algorithm, but because the problem is fundamentally expensive to parallelize. Maybe you end up getting something like a 20% boost by having twice as many nodes, even after applying all the cool algorithms. And you don't necessarily get that scalability in your code base for free, either.
3) "Speed" in the mobile and embedded spaces is often as much about energy efficiency and thermal management as getting done sooner.
4) The metrics for deciding that Python is faster to develop in only measure small problems. People tend to shy away from Python for bigger projects, and the reasons for this are pretty hotly debated.
Re: Yes, Python is Slow, and I Don’t Care
#80I 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…
> You can't even reliably do a "find usages" of classes using a dynamically typed language.
Let me introduce you to Racket. It started out in life as Scheme, and became something more.
DrRacket, it's IDE, is fantastic. The main reason why? You can trace every function call, and every macro, to its definition with a quick mouse-over, even if said definition is in another file or library, even if said definition is only conditionally created.
There isn't really a reason a dynamic language can't do tracing like that, or mass renames across files... Because some already do.