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

191–200 of 206 posts

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

#191

Post by scarface74 »

notacoward wrote: post #141
barrkel wrote: post #58

Earlier quoted context omitted.

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…

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.

Who uses straight C? C++ and C# have operator overloading. You can overload any of the operators for a class and get sane semantics for addition, subtraction, equality, etc.

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

#192

Post by scarface74 »

flavio81 wrote: post #175
scarface74 wrote: post #169

Earlier quoted context omitted.

Clojure is trying to do that with Clojure.spec and specifications being checked at runtime can get you closer to things you could have automatically proved correct only with languages with dependent types, nothing against statically typed languages but I feel that your sweeping generalizations hurt the point you are trying to make. "Checking at runtime* is exactly the problem. Why would checking at runtime be more re…

>"Checking at runtime is exactly the problem. Why would checking at runtime be more reliable than compile time?* If you use metaprogramming (i.e. Lisp macros, Scheme/Racket macros, Clojure macros), then the only way to have truly reliable checks is at run time. In fact, for debugging and testing, it's much better to have a runtime able to do many things (such as live patching of the code). Contrary to a language like…

Contrary to a language like C or C++, where the compiler produces machine language from the source and then goes out of the picture,

I use C#. When you create a Linq expression, you get type safety and it "compiles to" an expression tree that is converted to its runnable form at runtime -- in my case a Sql statement, a MongoQuery, or C# code. It really comes in handy. Theoretically I could change my backing Store from Mongo/C# driver to Sql Server/EF without changing any of the queries. I do this all of the time when unit testing, I substitute an in memory list for a database table and still get complete type safety.

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

#193

Post by joshuamorton »

pg314 wrote: post #176
joshuamorton wrote: post #154

Earlier quoted context omitted.

As I'll often say to these comments, then you're doing things wrong. Numpy code can be written to never leave the numpy sandbox, and at that point it should be as fast or faster than naive c++ (because you'll be getting SSE and stuff for free). There's a reason almost all deep learning is done in python.

Not all data is a good fit for Numpy: some data is non-numeric or not a homogenous array. > There's a reason almost all deep learning is done in python. The heavy-lifting in e.g. TensorFlow is done in C++. Bindings to Python make sense because it is one of the few sanctioned languages inside Google, and it is widely used outside of Google and easy to pick up.

>The heavy-lifting in e.g. TensorFlow is done in C++. Bindings to Python make sense because it is one of the few sanctioned languages inside Google, and it is widely used outside of Google and easy to pick up.

That's exactly the same as with numpy. I'm not sure what your point is. C++ is also one of the few sanctioned languages inside google, as is Java.

>Not all data is a good fit for Numpy: some data is non-numeric or not a homogenous array.

I'm curious what kind of data you're working with that can't be represented and effectively transformed in a tensor (numpy array).

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

#194

Post by hasenj »

kodablah wrote: post #77

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

Python is optimized for getting interesting things done in a few lines of code. Small scripts you write once and then forget.

For serious projects? IMO python is a disaster.

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

#195

Post by pg314 »

joshuamorton wrote: post #193
pg314 wrote: post #176

Earlier quoted context omitted.

Not all data is a good fit for Numpy: some data is non-numeric or not a homogenous array. > There's a reason almost all deep learning is done in python. The heavy-lifting in e.g. TensorFlow is done in C++. Bindings to Python make sense because it is one of the few sanctioned languages inside Google, and it is widely used outside of Google and easy to pick up.

>The heavy-lifting in e.g. TensorFlow is done in C++. Bindings to Python make sense because it is one of the few sanctioned languages inside Google, and it is widely used outside of Google and easy to pick up. That's exactly the same as with numpy. I'm not sure what your point is. C++ is also one of the few sanctioned languages inside google, as is Java. >Not all data is a good fit for Numpy: some data is non-numeric…

> That's exactly the same as with numpy. I'm not sure what your point is.

I was replying to "there's a reason why...". You didn't specify that reason, so from the rest of your comment I took it to mean that Python (with numpy) was fast and good enough to write deep learning stuff. That doesn't seem to be the case for TensorFlow.

> I'm curious what kind of data you're working with that can't be represented and effectively transformed in a tensor (numpy array).

I'm not intimately familiar with the internals of numpy, but my understanding is that the basic data structure is a (multi-dimensional) array of values (not pointers). That leads to a number of questions.

If you have an array of records (dtype objects), and one of the fields is a string, am I correct that each element needs to allocate memory to hold the longest possible value that can occur for that field? What if that is not known beforehand?

How do you deal with optional fields (e.g. int or null)? Do you need to add a separate boolean to indicate null?

How do you deal with union types, e.g. each record can be one of x types, do you make a record that has a field for each of the fields of those x types? Do those fields take up space?

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

#196

Post by hpcjoe »

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.

It's not just C++ though. If I have to add logic to my code to handle explicit type changes (casting, et al.) for something that, honestly, is not important to my algorithm, then this increases the likelihood that I will make a type/casting/conversion error.

OTOH, a language smart enough to (correctly) infer this (Perl, Julia, etc.) generally won't have a problem with this, and will handle these issues for you. Julia still allows you to be very explicit on type, and force a hard type specialized code. The benefit in this case, with type specialization, is that it can generate far more efficient code for the specific logic.

That latter argument is, to me, the only real benefit of typing systems that I've personally encountered. I know people throw studies around claiming "fewer errors with stronger type systems", but ... to be honest ... I have not experienced this. Rather, in stronger typed languages, I spend more time hunting down type impedance issues than logic issues.

This seems to not be a positive benefit to me. I may be alone in this regard, or not. I don't know.

I do know that, like programming languages, editors, operating systems, this view point (pro/anti strong typing) tends to take on a religious overtone in the sense of people taking a position and digging their heels in over this. Elevating this aspect as an important point in an overall platform decision process (what should we develop in), when, maybe, it shouldn't be.

In an odd way, I've seen this in the industry for a while. There were previous incarnations of this. Like Dijkstra's famous "goto" comments[1]. I don't necessarily agree with this, and I argue that people can write bad code in any language.

Typing systems ostensibly are there to help us write less bad code (all code is bad and buggy, anyone telling you otherwise is trying to sell you some swampland). But once they get in your way, and you start spending inordinate amounts of time dealing with typing issues, you have to ask whether or not they are helping or inhibiting.

Put another way, anything that helps should, actually help, without adding significantly to the burden. Apart from what Julia does, and other dynamic languages do ... that some people write great code in ... I've not seen/used many other systems that strive to get out of your way while working.

Typing systems do not automatically make code better. Absence of typing systems do not automatically make code worse. This is a function of the algorithm, the implementation logic, etc. How disciplined are you as the developer in making sure your code is clear, concise, and actually reflective of the problem you are attempting to solve ... things that help with that are welcome.

[1] http://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pd...

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

#197

Post by LeonidasXIV »

hellofunk wrote: post #86
LeonidasXIV wrote: post #83

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

> And you can do that in any language, regardless of its stance on typing.

Yes and no, because nothing prevents you from passing the wrong kind of value in an untyped language unless, well, you check for the runtime type yourself in the function and reject that. And you can only do that at runtime, at which point you'll not be able to immediately see where you're passing in invalid data accidentally unless you hit this exact branch in your code. So actually just the type tagging is quite useful already.

Also, it looks like more powerful dependently-typed languages like Idris[0] (and probably also Agda and Coq) can encode this information in the type system.

[0]: https://stackoverflow.com/a/28436452

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

#198

Post by Too »

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…

C# with "code contracts" allows you to annotate function arguments with valid ranges which will be statically checked at compile time. It's quite verbose though.

https://docs.microsoft.com/en-us/dotnet/framework/debug-trac...

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

#199

Post by notacoward »

scarface74 wrote: post #191
notacoward wrote: post #141

Earlier quoted context omitted.

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…

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. Who uses straight C? C++ and C# have operator overloading. You can overload any of the operators for a class and get sane semantics for addition, subtraction, equality,…

A lot of the largest and most critical codebases, probably including most of the software you cause to execute every day, is still in C. Also, operator overloading doesn't solve the general problem and creates a few of its own, but thanks for the condescension anyway.

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

#200

Post by agnivade »

> However, this is no longer true, as silicon is now cheap. Like really cheap. Run time is no longer your most expensive resource.

Our client won't spend more money than a t2.medium instance on aws. Nothing we can do about it. In that case, run time does become an expensive resource.

But I get the point that OP is trying to make. Just wanted to mention that not all of us have the comfort of having enough resources on which our app runs.

Post reply on HN