Hacker News new | ask | show | jobs
by ReflectedImage 877 days ago
Using static typing in Python is a serious mistake. The point of static typing is to allow an compiler to compile your code for performance reasons and nothing else. People do not normally compile Python code with a compiler.

Static typing significantly increases code length compared to duck typing, significantly increases development times and significantly increases bug count per delivered software feature.

It additionally gives developers the false impression that you can write large projects in Python without splitting the codebase into small micro-services. Hint: You can't, it is always a complete disaster as Python's support for static typing isn't good enough for large projects.

5 comments

> significantly increases bug count per delivered software feature.

Going to need a source for this.

It should be fair obvious that when you use a very verbose very boiler plate heavy coding style like static typing that because the programmer is writing a lot more lines of code per software feature and because the programmers make errors on a per line written basis that the number of the bugs will drastically increase.

You can easily find information on duck typed programs being significantly shorter and that statically typed and ducked typed programs have the same bug count per line. You can also look at the language defective tables showing ducked type Clojure as having the least bugs in commerical software and statically typed C++ having the most bugs in commerical software.

Google is your friend here.

So not only did you pull the original comment's assertions out of your _bag of holding_ but rather than citing sources when asked, you doubled down on "well if you know you know" and claim that the (often relatively small) increases to line lengths of type-annotated programs somehow magically increases the number of bugs, again with no evidence.

If you're not going to bring bold numbers to support bold claims, why should any of us bother listening?

There is nothing bold about the claims, knowing the differences between the various typing systems and their advantages and disadvantages is standard stuff.

I mean you could always try to find some sources to try and prove me wrong if you want?

I don't have a dog in your fight regarding the original point you made related to the number of bugs increasing but the logic in your comment is flawed though.

"I mean you could always try to find some sources to try and prove me wrong if you want? "

That's not really how it works though. If you make a claim, either you back-it up or it's irrelevant.

Case and point: I believe that a flying tea pot created the universe. By your logic I am right and it should be up to you to prove me wrong.

So to conclude this argument, if you are correct, you should prove it as the person who responded to you asked you to do.

Failing that,your comment goes back to being nothing more than your opinion instead of a fact.

We assume in good faith that statements made in comments on social media are true. If this was an academic paper, then perhaps you would be correct. But on social meda, asking for sources for what is basically common programming knowledge is borderline trolling.

If s/he thinks that what I'm saying is wrong so strongly then they can go back that up with something. They will obviously fail terribly because I'm correct but that is their choice.

I have written type-annotated Python for as long as type annotations have been a thing.

"Number of bugs will drastically increase" is simply wrong.

Type checking prevents bugs before they ship.

There are numerous academic studies that show that type checking does not reduce errors in shipped code by an statistically significant amount.

Type checking mostly shows that code can be compiled successfully. The thing it was designed to do.

> There are numerous academic studies that show that type checking does not reduce errors in shipped code by an statistically significant amount.

i've read some of these studies, they don't prove much. it's typically languages with inexpressive type systems like java.

>Type checking mostly shows that code can be compiled successfully. The thing it was designed to do.

what languages are you thinking of when you say things like this? these debates are useless because one person is thinking of the type system of language X and the other person is thinking of language Y. a lot of heat but little light.

Over the years, plenty of people have wanted to show that static typing gives code correctness benefits over dynamic typing. Everyone who tries just falls flat on their faces.
I previously worked at Dropbox, which had server codebase consisting of over 2 million lines of (untyped) Python. While I was there, Dropbox introduced type annotations into the codebase and used it as a testing group for Mypy, which was being developed largely at Dropbox, with both Jukka Lehtosalo and Guido van Rossum on staff.

I can say from that experience that pretty much everything you are claiming is wrong. Developers were enthusiastic about adopting type annotations. We found it made code easier to understand, gave better support from IDEs, made refactors easier, and caught bugs earlier.

Type-checking that codebase with Mypy was a technical challenge, but the Mypy team did a tremendous amount of work scale Mypy through caching and other optimizations. It was still slow, taking minutes at times, but way faster than the complete test suite.

Now, I will be the first to tell you not to write a 2Mloc server in Python, but if you happen to have created one, type annotations are huge boon to making it work.

I've seen both the statically typed Python 1Mloc monolithic and the ducked typed 1Mloc micro-service based approach in practice.

I'm telling you the ducked typed micro-service based approach is the way to go.

But you sort of know that "not to write a 2Mloc server in Python", don't you? If we encourage developers to use static typing they will be writing 2Mloc monolithic servers. That's just the type of code that static typing encourages.

Encouraging static typing in Python is putting them down the path of disaster.

Yes, I said quite clearly not to write a 2Mloc server in Python. Honestly, I would lean towards not writing servers of any size in Python, but if scalability and performance are of low concern, it could be a productive language for certain apps.

"If we encourage developers to use static typing they will be writing 2Mloc monolithic servers."

I don't even know where to begin with this wild assertion. Ill-advised as it was, Dropbox wrote its two million line server long before typed Python even existed. I wasn't around when they started cracking it up (see blog post below), but I strongly suspect the type annotations in the codebase helped rather than hindered that effort.

https://dropbox.tech/infrastructure/atlas--our-journey-from-...

> The point of static typing is to allow an compiler to compile your code for performance reasons and nothing else.

The relevant term is Type Checker. Static Type Checker: Something that checks types statically (i.e. by inspecting the source code without running it). Doesn't necessarily say anything about compilation, execution strategy, or indeed if the user program will ever be run at all.

Static type checking catches <1% of bugs. As a tool for verifying software correctness it's completely and totally in-effective.

The majority of bugs in code are about the behavior of the code rather than the typing. You require unit tests or some other more advanced technique.

A personal anecdote of using javascript and getting a function variable wrong ended up taking 30 minutes to find out what went wrong.

The error won't exactly point me to the source of bug and I was getting vague message that some data was missing .

And there were many instances of same throughout my project experience.

With typescript you will know instantly. The javascript being weakly typed compared to python necessitates use of typescript.

> The point of static typing is to allow an compiler to compile your code for performance reasons and nothing else

Sure, if one doesn't care about their code quality, after all everyone loves to write unit tests for every possible use case.

If you don't test the behavior of your code then it is wrong. Whether the code could in theory be compiled isn't a very good test case.

Static type checking has a measured bug catch rate of <1%. So the quality of any code where the programmer depends on static typing to verify correctness rather than unit tests is very very low.

Measured by whom?
Various academic studies on the topic
Such as?

Looking forward to a set of paper from renowned researchers with SIGPLAN/ACM, IEEE proven credentials in language research.