Python's “disappointing” superpowers

This is nearly impossible to precisely study:

- Because correlation != causation, for one thing: 2.5x the number of bugs in static "style" code bases (not sure what that means) does not mean that static type systems lead to more bugs. It could be that users of dynamically typed languages find themselves needing robust automated tests more often, because they can't rely on static typings. This would suggest that in a similarly productive language, your effort would go much further with types than without, even if this measurement is accurate.

- Because measuring bugs is hard: you don't actually know how many bugs a given piece of code contains, you only know how many you found. Statically typed code contains more information about the intent of the code. Not only does this make it easier for machines to analyze, it makes it easier for humans to analyze, too. Ask anyone who does security audits whether they prefer code that has strict static type information or not.

- Because not all bugs are the same; a reputable study would need to go through great pains to classify the different kinds of bugs and determine their severity as well as determine why they happened. Counting bugs as just a number and then comparing them is like counting SLOC. It doesn't tell you anything on it's own!

> Static typing has nothing to do with code correctness, it's purely about code performance.

Uhhh... Says who? Type erasure systems offer no performance benefits at all, since the types are removed before runtime.

There are contradicting studies, that suggest static typing prevents bugs, but there's little point in trying to fight them. None of the studies I've seen feel robust or complete enough, and on top of that, what would really be helpful is a meta-analysis of multiple more robust studies so we can get an idea of the true takeaways.

Until then, there will be some subjectivity.

There's no nice way to say this: I don't trust people who treat issues like this as black and white. To me, it's a sign of immaturity as an engineer. I do of course believe that static type checking is a net win overall and that the evidence to the contrary likely has other factors (like, for example, relying on relatively primitive type checkers that catch less errors, require more handholding, and generally have trouble handling idiomatic code) but like I said, YMMV: everyone has their failure and success stories. To me, if I can find a bug before I even save the file, versus needing to wait until QA catches it, or worse, it lights prod on fire, it's probably a win. As far as this "static code style" business goes, I don't understand it. My code does not look that different when it's JS vs TS. For Python, MyPy still doesn't seem sufficient, so I would not be surprised if strictly using things MyPy supports would make code worse. For us, switching to Go had more benefits than JUST types; of course we wound up having better performance and memory usage too, and the error handling practices, while verbose, definitely put error handling and edge cases front and center.

This would sum up my sentiment as well, just for documentation reasons alone it is wildly beneficial.

People who love dynamic typing seem to think their code is just “understandable” and it almost always isn’t

Here is a study that show Python is more bug-prone and that TypeScript is far more reliable: https://danluu.com/empirical-pl/

That source shows why language studies are so difficult, and why it is hard to draw conclusions. For example, your study doesn't count KeyErrors or NoneType exceptions as type errors, but those count as well. There are other considerations: you're only looking at released projects which might have a ton of tests to balance the fact that they're dynamic. But there is absolutely no way you can say "dynamic languages are less buggy". There's no data for that.

> For your very simple example, your IDE can do that!

No it can't. An IDE doesn't help at all here, because it doesn't know where you passed around that dict, and where it was created. There's no type hints. That dict is now a class, and you have to go find where else you used it. If you don't use any type hints in Python, how would you find all those cases? You have to hunt for it yourself, grok the entire codebase (which you may not have worked in for a while), and then run it a ton of times to make sure you caught every edge case. Refactoring in Python is very time consuming and dangerous compared to typed languages.

I still think python has a ton of headroom to grow. It's maxing out the data science space, and it does reasonably well in the web service space, but they really have not pushed very far into the distributable GUI and CLI space. Dependency, packaging, and distribution have been improving in leaps and bounds still for python, and type-hinting makes large projects manageable.

> Python functions have args and kwargs, which make typing significantly more complex

Not really. It's only complex when they're used with poor design decisions. There are plenty of languages that allow you to do things that aren't a good idea. Python is no exception. Type hinting just makes those shortcomings more readily apparent.

> Callable doesn't even support kwargs

PEP 544 and Protocols have existed for 5 years, and they support keyword only type hinting for callables.