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

Python's “disappointing” superpowers

lukeplant.me.uk

Post reply on HN
Print view View original

231–240 of 264 posts

Re: Python's “disappointing” superpowers

#231

Post by dkarl »

deshpand wrote: post #224
sa46 wrote: post #200

Earlier quoted context omitted.

10x seems extreme. ESR went from 14k lines in Python to 21k in Go. http://www.catb.org/~esr/reposurgeon/GoNotes.html

I didn't mean to exaggerate. I think part of the improvement was the luxury of refactoring which should generally reduce the bloat. And, as someone else said, part of the issue is C++/Java, not static typing. When I move from Java to Python, I also get the luxury of organizing code into fewer/meaningful source files. I find this more readable, than having to switch to different files constantly. I have not had a chan…

It's funny, both Java and Python emerged in the 1990s, yet Java feels incredibly crusty and awkward in 2023. I wouldn't choose Java as a fair representative of statically typed languages in 2023, but Python still feels like a reasonable choice for a non-Lisp dynamic language.

Re: Python's “disappointing” superpowers

#232

Post by random314 »

taeric wrote: post #194
random314 wrote: post #193

Earlier quoted context omitted.

Dude, you have already made up your mind, so I am not going to do any homework for you that you yourself aren't performing. You are not my boss, or anyone's boss here

Amusingly, you don't know my actual stance. Which is probably closer to pro static types than to dynamic. My criticisms in this thread is that the static type brigade does not hinge on evidence. It is typically hollow claims and getting angry at dynamic languages for being obviously bad for lack of helping.

You are not going to find any kind of hard evidence for anything when it comes to software engineering.

If you have some experience in software engineering you should already know that.

Based on the "hard evidence" in this thread you are either ignorant or a time wasting pedant.

Re: Python's “disappointing” superpowers

#233

Post by dkarl »

jchw wrote: post #86
ImprobableTruth wrote: post #32

Metaprogramming does not require dynamic types, but this post seems to equate them. As far as I can see all this could be done in e.g. Java (and probably is). IME this kind of "magic" very quickly loses its appeal when you have to debug it. The author's idea of libraries wrapping this stuff up so users don't have to care about it just doesn't pan out at all in my experience.

I also strongly dislike the idea that static type systems are only being added to Python because spoilsports from other languages are forced to use Python and don't want to. Not true. That's especially strange considering Python is one of the only traditionally dynamic languages that has mostly led it's own static typing system, joined mainly by just PHP in that regard. Why does it not support features like kwargs? D…

> I had a bug where I changed the return type of a function to be a tuple

> If a given programming language community winds up bleeding members who are moving on due to the lack of better static type checking systems, then the people left will invariably be much more likely to be against static type systems.

This reminds me of one of the things I hate most about the Python library ecosystem: libraries attempt to camouflage type errors resulting from changes like this. Something that should be an immediate runtime error turns into a subtle production bug. I discovered an error of this kind just this week while doing what I often have to do when refactoring someone else's code in Python: reading and distrusting every single damned line.

Which led to reading the source code of a third-party library, where I discovered something that I've seen often enough that I'm starting to think it's some kind of norm in Python libraries:

A function is documented to take a list of Foo. But if the value you pass is not a list, it doesn't throw an error. If the value is None, it uses []. If the value is a set or a generator or a tuple, it uses list(value). If the value is none of those things, it uses [value]. Now that it has a list, it looks at the values in the list, and for any value that isn't a Foo instance, it does its best to handle it. For example, if it's a str, it passes the value to the Foo constructor.

This might feel helpful for beginners and non-professionals just trying to get something to work on a single data set, testing everything by hand, but it amounts to passive-aggressive betrayal when you're trying to maintain a large codebase with multiple contributors. In the case I discovered this week, instead of an immediate runtime error prompting the programmer to make a trivial fix in their code, we had a feature subtly degraded in production for months. Very "helpful."

Re: Python's “disappointing” superpowers

#234

Post by lostmsu »

ReflectedImage wrote: post #214
lostmsu wrote: post #189

Earlier quoted context omitted.

Firstly, usability bugs like this are still bugs. Secondly, think how that issue surfaced in the first place. Somebody used TensorFlow in their Python code, and their Python code produced unexpected result and/or crashed. Judging by the fix, it is highly unlikely to have produced one of the errors from the above list. As a ML practitioner I can also tell you it likely means somebody had to spend a significant amount…

That not a bug that static typing would catch as it is not a type bug.

What do you mean it is not a type bug? You've seen the fix with your own eyes. In the static language that fix would never have been needed, because the consumer would never have made the mistake that caused the miscalculation in the first place. Of course it is a type bug!

This is along the lines of

  def is_valid_email(email): return str(email).contains('@')
  
  class Person:
    ...
    def __str__(self): return $"{self.name} "
  
  print(is_valid_email(Person(name='Peter @ Work', email=None)))

Re: Python's “disappointing” superpowers

#235

Post by lostmsu »

ReflectedImage wrote: post #220
lostmsu wrote: post #170

Earlier quoted context omitted.

> has on average 2.5x the number of bugs This claim is not supported by the linked article. In fact, the main claim (only 2% of bugs are type errors) of the linked article also does not make any sense. It is based on the assumption, that typing errors only ever cause TypeError, AttributeError, or NameError in Python, which is, ironically, false, because Python is a dynamic language. To give a concrete example, I went…

The article says that dynamically typed code and statically typed code has a similar number of bugs per line. It also says that a software feature only needs 1/2.5 lines if you are using dynamic typing. That means dynamic typing reduces bugs by 2.5x compared to static typing per software feature.

None of these are anywhere in the linked article: "2.5" "similar"

Re: Python's “disappointing” superpowers

#236

Post by jchw »

ReflectedImage wrote: post #216
jchw wrote: post #186

Earlier quoted context omitted.

> Yeah but typing related bugs which is what static type checkers catch only account for 3% of bugs. You're stating this as if it's fact and also universal, but I strongly doubt it. Even defining "type-related bug" is hard, because there's a ton of bugs that are not type-related but are much easier to avoid if you're using a good static type checker. For example, stringly-typed values, or switch statement exhaustiven…

3% is the right order of magnitude and if it is +10% more than that that wouldn't make any difference. Static typing would still be twice as bad as dynamic typing when it comes to code correctness. "What if you already know the majority of your bugs, as logged today, could be prevented by a type checker?" You would be a very bad programmer, since the vast majority of bugs are logic bugs. "why does C do static typing"…

> You would be a very bad programmer, since the vast majority of bugs are logic bugs.

I don't work alone. Most of the time, I work on projects that predate my involvement, and are old enough to have accumulated cruft.

But I think I found the disconnect. This right here is the key:

> since the vast majority of bugs are logic bugs

You might think that there is no way a type checker could prevent a logic bug. You're wrong. It is clear to me now that when you say 3%, you are talking not about the type of bugs that static type checkers are capable of preventing, but only errors that are explicitly related to types. Because if you model your code with types as you go, types do prevent all kinds of logic errors. When you write code with strong typing, it can prevent impossible state machine transitions, ensure that you handle all cases of a set of possibilities, ensure that you follow API contract obligations, and more.

Exactly how much a given type system is capable of inferring and decoding varies. TypeScript is definitely the state of the art for type erasure systems built on script languages, and what it is capable of encoding is pretty impressive.

Maybe, maybe, the amount of bugs that you can attribute to typing issues is 3% if we're only regarding Python TypeErrors; but, a proper type checker goes far beyond that.

Re: Python's “disappointing” superpowers

#237

Post by ReflectedImage »

lostmsu wrote: post #234
ReflectedImage wrote: post #214

Earlier quoted context omitted.

That not a bug that static typing would catch as it is not a type bug.

What do you mean it is not a type bug? You've seen the fix with your own eyes. In the static language that fix would never have been needed, because the consumer would never have made the mistake that caused the miscalculation in the first place. Of course it is a type bug! This is along the lines of def is_valid_email(email): return str(email).contains('@') class Person: ... def __str__(self): return $"{self.name} "…

You can't get a NaN from a None value in Python. (Duck typing still has rules)

The error you have posted isn't a Python error.

Looking a bit deeper, the error occurs in C++ code. C++ is a statically typed language, last time I checked.

Re: Python's “disappointing” superpowers

#238

Post by ReflectedImage »

lostmsu wrote: post #235
ReflectedImage wrote: post #220

Earlier quoted context omitted.

The article says that dynamically typed code and statically typed code has a similar number of bugs per line. It also says that a software feature only needs 1/2.5 lines if you are using dynamic typing. That means dynamic typing reduces bugs by 2.5x compared to static typing per software feature.

None of these are anywhere in the linked article: "2.5" "similar"

There is more than one study on the topic. But you can just take a look at the graphs.

Take a look at the "Programming effort" graph and the "Program length" graph.

Re: Python's “disappointing” superpowers

#239

Post by ReflectedImage »

jchw wrote: post #236
ReflectedImage wrote: post #216

Earlier quoted context omitted.

3% is the right order of magnitude and if it is +10% more than that that wouldn't make any difference. Static typing would still be twice as bad as dynamic typing when it comes to code correctness. "What if you already know the majority of your bugs, as logged today, could be prevented by a type checker?" You would be a very bad programmer, since the vast majority of bugs are logic bugs. "why does C do static typing"…

> You would be a very bad programmer, since the vast majority of bugs are logic bugs. I don't work alone. Most of the time, I work on projects that predate my involvement, and are old enough to have accumulated cruft. But I think I found the disconnect. This right here is the key: > since the vast majority of bugs are logic bugs You might think that there is no way a type checker could prevent a logic bug. You're wro…

"a proper type checker goes far beyond that"

But if it can't catch 60% of all errors and it can't. Then it's worse than dynamic typing.

This isn't complicated. If you are excluding performance, then static typing is inferior to dynamic typing. It's that simple. No ifs, no buts.

I do write statically typed code but that's for performance critical code. Since I've got good experience of both, I understand the differences very well.

I assure you that using static typing in a scripting language like Python is a mindnumbingly stupid thing to do.

Re: Python's “disappointing” superpowers

#240

Post by ReflectedImage »

albertopv wrote: post #210
taeric wrote: post #158

Earlier quoted context omitted.

This is almost always framed in a way that shows large systems need the extra rigidity of some static systems. And that dynamic systems are only about rapid prototyping. I think that is a bit of a false framing. To wit, any system of 100k LOC will be hard to get into. Even harder to make changes in. There is no getting around that. None. Even worse if you have many entities flying about these 100k LOC. Each change to…

Dynamic languages large code based are, in my 14yo experience, much much harder. Today no one a serious project with javascritpt, AFAIK everybody use typescript. Why?

JavaScript is a badly designed language. It was created on the fly over several decades by browser makers. People prefer to code in absolutely anything else.

WASM will probably kill TypeScript shortly.

Post reply on HN