Mainly the boilerplate other languages force upon you. Whenever i look at Java Code i start to chuckle.

Its so much more information that you need to load into your head.

To quote a picture from the post: https://www.paypal-engineering.com/wordpress/wp-content/uplo...

And its not like you need static typing everywhere just in some places its better to enforce it for your own sanity. Type hinting looks like a good way to solve this problem in python.

That image isn't really a fair comparison (in that C++ / Java aren't the only statically typed languages.)

I imagine a statically typed Python dialect would only have an extra 15 or so lines, and the benefits would be numerous.

I love python as much as anyone, but having to keep a reference manual handy just to use someone's library because they had the audacity to use a variable is not my idea of a fun time.

EDIT: I'm probably exaggerating too much.

Would I use Python in a large, complicated, multi-developer project? Yes, I would. And my only real complaint would probably be that I like static typing so much that I'd miss it.

> I imagine a statically typed Python dialect would only have an extra 15 or so lines

Actually you can have a statically typed Python if you want. Have a look at http://docs.cython.org/src/quickstart/cythonize.html

All type declarations are optional. It compiles modules to versions completely interoperable with the rest of Python code. They're importable, behave as you'd expect, etc.

Consider Haskell. It's about as anti-boilerplate as they come. And with automatic type inference.

I've never had to spend all my time doing that. I am making the case that type errors (passing a hash instead of an int, etc) are NOT one of the major causes of errors in software development.

I'm apt to screw up other things, but that's not one of them.

> I am making the case that type errors are NOT one of the major causes of errors in software development.

That's symptom of a bad typing system. I'm with a moderately sized Haskell codebase right now and type errors represent the biggest share of errors on it by a huge margin - several times bigger than runtime bugs.

Haskell makes programming into a duel with the type system specifiers.

Yes, it does. That duel replaces a chase on unknown and strange runtime bugs.

Sometimes it's a win, other times it isn't.

I prefer to think of it as a dialectic.

Shouldn't you be writing tests anyway?

NB I'm not being flippant - I've been using Python for a couple of years and appreciate the lack of boilerplate compared to many other languages and if there are "type" problems my unit tests, which I will be writing anyway, find them. Using an IDE like PyCharm does a good job of warning you about type problems at development time so I don't have a lot of run time type problems.

Yeah, you should, but you don't have to check trivial things like "is this a list?"

Well, I wouldn't write a unit test for that - I would write a unit test for the high level observable behavior and if I get it wrong that something is a list then it'll break and my unit test will fail.

I think that's closer to functional testing than unit testing though...

The idea is that writing code + writing tests in a dynamically typed language is easier and faster just writing code in a statically typed language. (Of course it depends on the languages in question, the programmers and a number of other factors)