Yes, Python is Slow, and I Don’t Care • Hacker News Board

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

#111

Post by Jtsummers » Fri, Sep 08, 2017, 2:42 PM UTC

hellofunk wrote: post #104

Jtsummers wrote: post #98

Earlier quoted context omitted.

http://www.adaic.org/resources/add_content/standards/05aarm/... Compile-time and run-time floating point numbers constrained by precision and range. It's been a long time so I'm just going to include the examples in that document: type Coefficient is digits 10 range -1.0 .. 1.0; type Real is digits 8; type Mass is digits 7 range 0.0 .. 1.0E35; subtype Probability is Real range 0.0 .. 1.0; These will be checked (to th…

Cool, but I don't know much about Ada, and would like to see an example for a statically-typed "range checker" in a more mainstream language used actively today. C++ templates can do a lot of magical stuff at compile time but such techniques are well beyond the reach of most developers. I can't think of any typed language I've used or seen in active modern professional work where you could validate a value as part of…

Not without extra-compiler tooling like other static analysis tools, you're probably correct. I haven't had a chance to use much Ada, it's always been a pleasure for me to work in because I get to use things like the above to make my code so much clearer.

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

#112

Post by taway_1212 » Fri, Sep 08, 2017, 2:44 PM UTC

TuringTest wrote: post #102

golergka wrote: post #92

Earlier quoted context omitted.

You're describing tools usable in writing new code. What static languages thrive in, however, is maintaining old code that was written by somebody else.

Which is the reason why it makes sense to write new applications in a dynamic language, and later port critical parts of it to more static compiled ones.

s/port critical parts of it to/dump everything and rewrite from scratch in

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

#113

Post by agentgt » Fri, Sep 08, 2017, 2:47 PM UTC

nerdponx wrote: post #53

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…

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) and for reasons I can't remember why but JNI is slow (probably moving stuff on and off the heap... I can't recall).

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

#114

Post by scbrg » Fri, Sep 08, 2017, 2:47 PM UTC

__s wrote: post #61

> without getting stuck in the weeds of the small things such as whether you should use a vector or an array Yes, instead get into the weeds of tuple vs list Not included in the graph of time-to-solve-problem static languages: statically typed languages with type inference

Given that they have exactly the same interface, that choice is really easy. You go with one until it turns out to be insufficient, and then you switch to the other and not a single line of code has to change, except at the point where you create the thing.

Incidentally, the same is true in many situations in Python, and that is (IMO) one of its strengths.

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

#115

Post by bluedino » Fri, Sep 08, 2017, 2:49 PM UTC

Many times when Python is blamed for being slow, it's the programmers fault. Python is great that you can 'regular' people writing code in it quickly. The problem is, these regular people don't always understand algorithms or things like caches, threads, databases...

A lot of these users can just say "My department needs a $40,000 24 CPU server with maximum RAM from MicroWay/SuperMicro, we need to run our codes faster", when they are just trying to brute force things.

They understand the problem domain but don't have the programming skills to use a computer to efficiently solve it.

But, these guys are all a step ahead of the ones who are stuck in the mindset of "C is the only language fast enough for my work", while not even understanding pointers and basic syntax and getting stuck on silly things like text processing, which could be done in minutes in Python.

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

#116

Post by dom0 » Fri, Sep 08, 2017, 2:50 PM UTC

icebraining wrote: post #13

"It doesn't matter than Python is slow, besides we can use compiled libraries to speed it up" "People saying it doesn't matter that Python is slow are deluding themselves and preventing Python from getting faster like JS did" "Python is inherently harder to optimize than JS since it has " "Smalltalk/Lisp/etc are also very dynamic yet are much faster" "The slowness of Python is harming the planet by being inefficient…

> "Python is inherently harder to optimize than JS since it has "

Python is not a very dynamic language in the sense that you actually can't change a lot of stuff (and a number of the things you can change just segfault CPython). I think JS is more dynamic, for example. Or Ruby.

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

#117

Post by monkmartinez » Fri, Sep 08, 2017, 2:51 PM UTC

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…

Will you please share the languages you thunk are up and coming?

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

#118

Post by e12e » Fri, Sep 08, 2017, 2:53 PM UTC

hellofunk wrote: post #87

icebraining wrote: post #84

Earlier quoted context omitted.

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

> Yes but there are no mainstream or production-ready dependently typed languages, so I didn't mention that.

(For a number-type that is limited to eg be between 0.0 and 1.0):

Ada?

http://www.adahome.com/rm95//rm9x-03-05-07.html

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

#119

Post by bane » Fri, Sep 08, 2017, 2:55 PM UTC

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…

Python is very developer productivity friendly, but degrades performance in weird ways and the methods to increase performance don't always make lots of obvious sense and often are the "idiomatic" way.

I haven't looked into the guts myself, but I'd bet that for similar or equivalent operations, the way the different syntaxes are handled under the hood are wildly different. e.g. function calls are much faster than method calls on objects.

Optimized pure python can look very ugly and non-idiomatic.

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

#120

Post by cup-of-tea » Fri, Sep 08, 2017, 2:55 PM UTC

carlmr wrote: post #65

ageofwant wrote: post #36

Earlier quoted context omitted.

You only pay the the price while debugging. In your static language you pay the price continually. You are wasting orders of magnitude more time fighting your language's type system every day, you have to read reams of boilerplate code that are unrelated to the problem at hand, each extra line increases the attack surface and complexity of your code.

>You are wasting orders of magnitude more time fighting your language's type system every day I program C# a lot, I never fight the type system. It helps me. It tells me while coding that something is wrong. In Python I'll catch this as well...eventually, when I run the code. A type error in C# would be a runtime error in Python. That's very inconvenient. The static types are also documentation showing intent. It's h…

When I write a new function in Python I immediately evaluate it in a running REPL and test it. There's no eventually about it. A function either works or it doesn't.