Live data from Hacker News

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

hackernoon.com

161–170 of 206 posts

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

#161

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.

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

    case class Probability(value: Double) { require(value = 1, "probability must be between 0 and 1" }

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

#162

Earlier quoted context omitted.

That idea is old enough to have entered the original edition of The Mythical Man-Month. That said, I have never seen any study like this where I didn't have some serious disagreement over methodology or conclusions. (Ok, except for that one on Peopleware.) It is a hard subject, and running a study over "the population of GitHub" is problematic by itself.

In my own subjective experience, I've found the idea to make a lot of sense and probably be true. I've done equal amounts of professional work in C++ and in Clojure, both languages I like a lot (and they are about as different as two languages can be). To accomplish a task in C++ takes probably 10x the code of Clojure. I would say that my bug-hunting time spent is maybe 5x in C++ vs. Clojure. This, despite that C++ i…

That is my impression too. I find that the most relevant metric impacting the bug density is number of lines on this one project, and it's very non-linear.

That puts at advantage both languages that reduce line count, and languages that make it possible to abstract the plumbing into a generic library (if it's not generic, it's part of this one project). I think mostly everybody has that same impression.

Still, we shouldn't pretend that impression is a scientific certainty.

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

#163

Earlier quoted context omitted.

A static type system doesn't protect you from choosing the wrong abstraction, and all the bugs that result from it. But if used properly I think it does help.

How? I don't think I've ever gotten a type I wasn't expecting in any of my python code. It's just not a problem for me. That is, past the first time I run it. I've been known to pass something an x when it wanted a y, but that's a "fail early, fail loud" bug and not an actual problem.

Well the obvious problem is that you have to test all of the code paths before deciding that your code is type safe. Static types do not have that problem.

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

#164
post #134
post #37

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

It's still expensive on client machines because most of the persons in the world are NOT software engineers with 6-digit salaries. They run cheap computers with HDDs and Windows polluted by a ton of 3rd party crap. They don't know how to fix it and silently suffer. I was cleaning a local vet clinic's devices recently – they were literally switching between two computers to not wait 5 minutes of non-responsiveness bec…

A lot of businesses these days prefer web apps. It's not hard to understand why - all the hassle of system maintenance falls to the people who host the app and can afford to know their stuff. If your Windows PC is suffering from rot just replace it with a Chromebook.

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

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

>In Python I need to rescan all of the types into my head until I can understand what the program does. Couldn't that be solved with sane variable naming conventions and docstrings/documentation?

Maybe. But it can be more easily solved on a strongly typed language where you can right click on a method and do "find usages" and it can. E done algorithmically.

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

#166

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. Sure, it can; many common numeric types include specific ranges, the fact that the range 0-1 doesn't match any common floating point type doesn't mean that it isn't one that could be a type.

> many common numeric types include specific ranges Can you give me a mainstream language example?

Every fixed-size numeric type.

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

#167

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

case class Probability(value: Double) { require(value = 1, "probability must be between 0 and 1" }

What's the language and what does "require" do? Is that a compile-time mechanism?

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

#168
post #58

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…

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 continuing on with my next fragment of functionality with a refresh of the web page, no recompiles or restarts required. You can do this with some difficulty and certain caveats in a statically compiled language, but only if things have been set up in just the right way, with automatic dependency recompilation and reloading,

You've been able to do that with ASP.Net MVC for years. You can change your views hit save without having to start over.

But on the back side, why is "restarting" such a heavyweight operation? If I'm iterating over a piece of back end code that takes a while to get to debug, I use the testing framework as a harness to run small bits of code - not a real unit test just an easy way to setup the prerequisites to step through a piece of functionality.

This opens up more avenues for declarative programming; construct a data structure that models your problem more directly, and then write code that interprets the data structure.

Even C++ has a level of reflection these days. But why wouldn't you be able to do that with c# and attributes or Java with annotations?

You want extremely lightweight literals for this, readable with minimal ceremony, including lambdas for when you need an escape hatch, a little pocket of custom code embedded in the bigger data structure. Statically typed languages have little context to infer types for such lambdas, unless they can generalize from the operators applied, but then you have a generic function, not a piece of data.

C# has had type safe lambda for a decade. And as far as a generic function, you can define a lambda/Linq expression that can be reused and that can generate c# IL code at runtime, a MongoQuery when using a the Mongo driver or SQL Expression when using Entity Framework. Ling expressions and the expression trees they generate are very powerful, versatile and typessafe.

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

#169
post #59

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…

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

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 reliable than compile time?

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

#170

Earlier quoted context omitted.

> A type can't tell you that. Yes, it can! --- but you don't necessarily want to confound your program with such a thing. The old adage about the cure being worse than the disease applies.

> Yes, it can! Ok, how? Other than an Ada example, or dependently-typed languages that aren't use in production, can you offer an example?

Perl 6, for instance, supports subset types such as:

  subset Positive of Int where * > -1
OTOH, while some Perl 6 supports some static type checking, subsets of this kind seem to support only dynamic, not static, enforcement.
Post reply on HN