Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python numbers every programmer should know

mkennedy.codes

Post reply on HN
Print view View original

171–180 of 191 posts

Re: Python numbers every programmer should know

#171

Post by pjmlp »

zelphirkalt wrote: post #110
passivegains wrote: post #68

Earlier quoted context omitted.

this is absolutely true, but there's an additional nuance: yes, python is fantastic, yes, it's easy and forgiving, but there are other languages like that too. ...except there really aren't. other than ruby and maybe go, every other popular language sacrifices ease of use for things that simply do not matter for the overwhelming majority of programs. much of python's popularity doesn't come from being easy and forgiv…

Omg, switching to C++ for pupils programming beginners ... "How to turn off the most students from computer programming?" 101. Really can't get much worse than C++ for beginners.

Back in the 1990's, C++ used to be taught at high school students and first year university students.

Re: Python numbers every programmer should know

#172

Post by pjmlp »

fud101 wrote: post #132
IshKebab wrote: post #116

Earlier quoted context omitted.

Someone says "let's write a prototype in Python" and someone else says "are you sure we shouldn't use a a better language that is just as productive but isn't going to lock us into abysmal performance down the line?" but everyone else says "nah we don't need to worry about performance yet, and anyway it's just a prototype - we'll write a proper version when we need to"... 10 years later "ok it's too slow; our options…

I don't know a better open source language than Python. Java and C# are both better (platforms) but they come with that obvious corporate catch.

You can still get to use Scala, Kotlin, Clojure, F#, all with better performance than Python, and similar prototyping capabilities.

Re: Python numbers every programmer should know

#173

Post by pjmlp »

amelius wrote: post #21
willseth wrote: post #20

Every Python programmer should be thinking about far more important things than low level performance minutiae. Great reference but practically irrelevant except in rare cases where optimization is warranted. If your workload grows to the point where this stuff actually matters, great! Until then it’s a distraction.

Yeah, if you hit limits just look for a module that implements the thing in C (or write it). This is how it was always done in Python.

I rather have a JIT that avoids the "rewrite in C", unless there is no way around it, after heroic optimizations.

Re: Python numbers every programmer should know

#174

Post by mrguyorama »

HenriTEL wrote: post #156
Scubabear68 wrote: post #113

Earlier quoted context omitted.

No. Python’s issue is that it is incredibly slow in use cases that surprise average developers. It is incredibly slow at very basic stuff, like calling a function or accessing a dictionary. If Python didn’t have such an enormous number of popular C and C++ based libraries it would not be here. It was saved by Numpy etc etc.

22ns for a function call and dictionary key lookup, that's actually surprisingly fast.

In that time the java app parsed 50 strings for object hierarchies (using a regex that isn't cached) and extracted values from a request object to a processing object, handled errors, and logged results.

3 times.

This is the naive version of that code, because "I will parallelize it later" and I was just getting the logic down.

Turns out, when you use programming languages that are fit for purpose, you don't have to obsess over every function call, because computers are fast.

I think people vastly underestimate how slow python is.

We are rebuilding an internal service in Java, going from python, and our half assed first attempts are over ten times faster, no engineering required, exactly because python takes forever just to call a function. The python version was dead, and would never get any faster without radical rebuilds and massive changes anyway.

It takes python 19ns to add two integers. Your CPU does it in about 0.3 ns..... in 2004.

That those ints take 28 bytes each to hold in memory is probably why the new Java version of the service takes 1/10th the memory as well.

Re: Python numbers every programmer should know

#175

Post by IshKebab »

gcanyon wrote: post #118
IshKebab wrote: post #116

Earlier quoted context omitted.

Someone says "let's write a prototype in Python" and someone else says "are you sure we shouldn't use a a better language that is just as productive but isn't going to lock us into abysmal performance down the line?" but everyone else says "nah we don't need to worry about performance yet, and anyway it's just a prototype - we'll write a proper version when we need to"... 10 years later "ok it's too slow; our options…

What language is “just as productive but isn't going to lock us into abysmal performance down the line”? What makes that language not strictly superior to Python?

Typescript, C#, Go, Rust.

I'd say they are almost strictly superior to Python, but there are some minor factors why you might still choose Python over those. E.g. arbitrary precision integers, or the REPL. Go is a bit tedious and Rust is harder to learn (but productive once you have).

But overall they would all be a better choice than Python. Yes even for startups who need to move fast.

Re: Python numbers every programmer should know

#176

Post by fud101 »

pjmlp wrote: post #172
fud101 wrote: post #132

Earlier quoted context omitted.

I don't know a better open source language than Python. Java and C# are both better (platforms) but they come with that obvious corporate catch.

You can still get to use Scala, Kotlin, Clojure, F#, all with better performance than Python, and similar prototyping capabilities.

Those are non-mainstream languages, I think the point stands. You would need to prove the case for Scala or Kotlin tbh, Scala is hideously complex and Kotlin like Python suffers from becoming too bloated, accumulating features and syntax that are either not required or difficult to remember. Clojure and F# are nice and all but very niche.

Re: Python numbers every programmer should know

#177

Post by maccard »

pjmlp wrote: post #171
zelphirkalt wrote: post #110

Earlier quoted context omitted.

Omg, switching to C++ for pupils programming beginners ... "How to turn off the most students from computer programming?" 101. Really can't get much worse than C++ for beginners.

Back in the 1990's, C++ used to be taught at high school students and first year university students.

I just went and checked my university - they’re still teaching c++ to first year uni students in 2025

Re: Python numbers every programmer should know

#178

Post by pjmlp »

fud101 wrote: post #176
pjmlp wrote: post #172

Earlier quoted context omitted.

You can still get to use Scala, Kotlin, Clojure, F#, all with better performance than Python, and similar prototyping capabilities.

Those are non-mainstream languages, I think the point stands. You would need to prove the case for Scala or Kotlin tbh, Scala is hideously complex and Kotlin like Python suffers from becoming too bloated, accumulating features and syntax that are either not required or difficult to remember. Clojure and F# are nice and all but very niche.

Python being complex isn't an issue for beginners, apparently.

Kotlin owns the mobile development market with 80% Android market share.

Scala was the AI before Python with Hadoop, Spark and friends.

Lisps might be niche, yet they were Python's flexibility, with machine code compilers, since 1958.

Re: Python numbers every programmer should know

#179

Post by HenriTEL »

mrguyorama wrote: post #174
HenriTEL wrote: post #156

Earlier quoted context omitted.

22ns for a function call and dictionary key lookup, that's actually surprisingly fast.

In that time the java app parsed 50 strings for object hierarchies (using a regex that isn't cached) and extracted values from a request object to a processing object, handled errors, and logged results. 3 times. This is the naive version of that code, because "I will parallelize it later" and I was just getting the logic down. Turns out, when you use programming languages that are fit for purpose, you don't have to…

Python is slow but in my experience (that mostly relates to web services and data processing) I found that I/O was by far the biggest bottleneck. Waiting for the database, another http service or local storage, which often takes more than 1ms anyway.

Re: Python numbers every programmer should know

#180

Post by lifeisstillgood »

fragmede wrote: post #164
lifeisstillgood wrote: post #117

Earlier quoted context omitted.

Absolutely But hidden in this is the failing of every sql-bridge ever - it’s definitely easier for a programmer to read customers(3).balance but the trade off now is I have to provide class based semantics for all operations - and that tends to hide (oh you know, impedance mismatch). I would far prefer “store the records as plain as we can” and add on functions to operate over it (think pandas stores basically just i…

customers[3]['balance'] seems like a reasonable middle ground, no?

It depends - most likely that’s storing as a language specific data structure (dict in python then serialised to disk). At this point we’re walking into harder to turn around decisions and might as well do it properly. It still really “it depends” …
Post reply on HN