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

141–150 of 206 posts

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

#141

Post by notacoward »

barrkel wrote: post #58
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…

You sound like someone who hasn't used dynamic languages in anger, or you'd mention some of the things that dynamic languages do well that statically typed languages aren't so great at, to prevent your argument sounding like a straw man. For example: dropping into a debugger (binding.pry / pry_remote in Ruby) to write code interactively in the context of the application, transferring that code to the source, and cont…

I'd take the point about literals a half-step further. It's really nice to be able to throw a string at a function and have that function compare it to a literal value using == instead of strcmp - and oh yeah, someone was just about to reply saying I should always use strncmp for extra productivity loss. Or I can throw a list/dict of any random type around without lots of ceremony. Do I lose type checking? Sure. Then again, those "expected int, got unsigned int" warnings aren't very helpful sometimes. "Must compile without warnings" is a good idea for long-term maintainability of long-term code, but when you're writing a simple script or still experimenting with an algorithm that crap just gets in the way. A minute or two defining and aligning types might not seem to much, but when you have to do it ten times in the course of what was only a one-hour task to begin with it's a pretty significant hit.

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

#142

Post by e12e »

jerf wrote: post #55
traverseda wrote: post #22

There's are still some big gains python could make, if python implementations were better. Micropython is equivalent to a real-time cooperative-multitasking OS. If it had ~~better~~ support for things like cffi, you could implement posix on top of it. I can imagine a laptop that runs gnu+python in the next few years. That's a whole new usecase, simply because that implementation uses a lot less ram. What usecases wou…

"There's are still some big gains python could make, if python implementations were better." At this point, I would find it far easier to believe that you are underestimating the difficulty involved in what it takes to speed up Python than that there are enormous gains yet to be had in speeding up Python. I suspect JS has had more optimization effort expended overall, but Python has still had a ton of work by lots of…

I think the work being done on ruby with the truffle/graal project is interesting in this regard - it's my understanding that ruby is very dynamic too - but it's interesting to see what can be achieved by inclining c to ruby to c etc. It's a crazy stack, compared to something like red (redlang) - but it's amazing how close they are able to get to "magically fast compiler/runtime".

If they manage to combine tracing/warm-up with ahead-of-time compilation to executables... It'll be very interesting indeed.

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

#143

Post by kazinator »

rockostrich wrote: post #34
simonh wrote: post #27

Earlier 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.

I recently found and fixed a 5 1/2 year old bug that was caused by a caller assuming that an integer parameter is an absolute quantity, but the function treated it as a delta. (The really funny thing is that the commit which introduced this bug introduced both that function and the incorrect call to it; and then, for the next 5 1/2 years after that, subsequent new uses of the function elsewhere in the code all correctly use its argument!)

The expressions x - y and y - x often have exactly the same type tree, but calculate a different value. Same with f(x, y) and f(y, x) when the parameter types are the same.

To actually catch real bugs such as this with types, you have to make such a fine grained use of types that programming becomes nigh intractable.

If x has type minuend and y has type subtrahend then, x - y is well typed, whereas y - x isn't. Problem is, the values come from some other context in which their minuend and subtrahend are meaningless (and, in any case, are not involved).

The kinds of errors that are found by static typing in practice are those that, under dynamic typing, will only sneak into production if the code is not tested at all. I.e. if the code had been executed even once with any inputs, the problem would have showed up.

Plus, if you assume that "dynamically typed" language means "language with no static checks", you're arguing against a strawman of dynamic typing. That is even more ridiculous if you're pitting True Scotsman's state-of-the-art static typing against this dynamic strawman.

(Of course, some dynamic languages in widespread use do more or less look like that strawman; however, the best examples of dynamic typing are languages which are considerably informed about type prior to executing a program, like the SBCL dialect of Common Lisp, for instance.)

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

#144

Post by falcolas »

marcosdumay wrote: post #94
hpcjoe wrote: post #74

Earlier quoted context omitted.

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 workin…

I was about to ask you what kind of statically typed languages you were using that gave you this impression. But... "boilerplate type defs". Yeah, C++ typing system sucks. Just don't think this generalizes to other languages.

Well, let's see.

Go: map[string]int64

Java: HashMap

Rust: HashMap

I think Haskell is one of the only statically typed languages which doesn't really care about algebraic typing. And yes, if you're talking about static typing, you get the baggage of dealing with algebraic typing to go with it as a rule. You can't arbitrarily separate the two until more languages follow Haskell's route.

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

#145

Post by AstralStorm »

daemin wrote: post #60
carlmr wrote: post #56

Earlier quoted context omitted.

>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,…

Of course that depends how much more you have to write in one language compared to another. Say you're 10x more productive but have to write 5x code, that sort of cuts down the advantage somewhat.

Who cares about writing a lot of code that is boilerplate really?

That is not where productivity sinks are. They're in build systems, package managers, existence of good libraries and ease of debugging as well as limiting number of accidents while coding.

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

#146

Post by abhirag »

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…

Sounds like an interesting analysis, would love to know where Erlang stands. Terseness definitely is a factor in play but I think at the end of the day it is all about where the priorities lie in language design, some languages really take errors and fault tolerance seriously, Erlang is famous for that and it is dynamically typed, same with Clojure, being a lisp the language design is much less rigid which allows for improvements like core.typed and Clojure.spec

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

#147

Post by AstralStorm »

kazinator wrote: post #143
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.

I recently found and fixed a 5 1/2 year old bug that was caused by a caller assuming that an integer parameter is an absolute quantity, but the function treated it as a delta. (The really funny thing is that the commit which introduced this bug introduced both that function and the incorrect call to it; and then, for the next 5 1/2 years after that, subsequent new uses of the function elsewhere in the code all correc…

This is why we should really push for automatic logic checkers and proper support of programming by contract.

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

#148

Post by AstralStorm »

agentgt wrote: post #113
nerdponx wrote: post #53

Earlier quoted context omitted.

For some data processing tasks Python can be brutally slow, especially text processing. NumPy is only fast because it's written in C and offloads hard numerical calculations to BLAS.

Yes but at least Python has very good native access to libraries. For example I am sure Java is faster at numerical processing than pure Python at least with Python you have the option of writing in native. Python has really good C interop and it maybe considered by some not part of the language but I consider that it is. Yeah you could write native code for Java via JNI but its not easy (granted its been a while) an…

Decent, not very good. Ctypes is slow, cython requires extra boilerplate to become performant. Python/C API is even more annoying than that. (Compared even to something like JNI.)

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

#149

Post by AstralStorm »

mattkrause wrote: post #108
classybull wrote: post #88

Earlier quoted context omitted.

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...

You're violently agreeing with each other. Python itself can be pretty slow. Doing image processing on data stored as list-of-lists-of-integers would be brutally slow. On the other hand, numpy is an import away, and it can be quite fast, especially if it's been built with an optimized BLAS/ATLAS, etc.

By blazingly fast you mean 100x slower than C++ equivalent and only 20x slower is you're very careful to avoid accidental copies.

For reference, MATLAB is about 30x slower with no special care. Pure Java on Hotspot was 5x slower except it dies on big data input due to very slow GC and goes to 50x slow.

Source: handled big audio data from hdf5 database, gigabytes sized. C++ equivalent had no vectorization or magic BLAS or anything.

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

#150

Post by coldtea »

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.

And yet it was common understanding just a couple decades ago. And not just from naive "script kiddies". Read what PG writes about Lisp in ViaWeb for example.

And it's not because we know we have faster to develop static languages, type inference, faster compiles (and also not because of Haskell etc). Those apply to insignificant minorities using Go and Haskell (insignificant compared to the huge hordes using Java, C#, Python, PHP, C/C++, and JS).

It's because of the fad mostly -- JS transpilers and everybody else going for moar types.

>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.

Which is almost irrelevant when it comes to produce something -- you can get it to market faster with those bugs than with the extra rigidness.

Post reply on HN