I recently found and fixed a 5 1/2 year old bug that was caused by a caller assuming that an integer parameter is an absolute quantity, but the function treated it as a delta. (The really funny thing is that the commit which introduced this bug introduced both that function and the incorrect call to it; and then, for the next 5 1/2 years after that, subsequent new uses of the function elsewhere in the code all correctly use its argument!)

The expressions x - y and y - x often have exactly the same type tree, but calculate a different value. Same with f(x, y) and f(y, x) when the parameter types are the same.

To actually catch real bugs such as this with types, you have to make such a fine grained use of types that programming becomes nigh intractable.

If x has type minuend<integer> and y has type subtrahend<integer> then, x - y is well typed, whereas y - x isn't. Problem is, the values come from some other context in which their minuend and subtrahend are meaningless (and, in any case, are not involved).

The kinds of errors that are found by static typing in practice are those that, under dynamic typing, will only sneak into production if the code is not tested at all. I.e. if the code had been executed even once with any inputs, the problem would have showed up.

Plus, if you assume that "dynamically typed" language means "language with no static checks", you're arguing against a strawman of dynamic typing. That is even more ridiculous if you're pitting True Scotsman's state-of-the-art static typing against this dynamic strawman.

(Of course, some dynamic languages in widespread use do more or less look like that strawman; however, the best examples of dynamic typing are languages which are considerably informed about type prior to executing a program, like the SBCL dialect of Common Lisp, for instance.)

You can say that something is a floating point number (a type) but what if that something must be between zero and one? A type can't tell you that.

Typing has its place but the idea that it catches all bugs at compile time certainly isn't true; the cycle of running the app itself, running its tests, is just as important for statically-typed code as dynamically typed.

Languages that have a sophisticated contract system* (like Clojure's Clojure.spec library) have a bit of a leg up in my opinion. You can much more precisely explain and control and test for the specifics of all values flowing through your system well beyond merely what type they are.

-- * Clojure's devs don't refer to spec as a contract system because it is quite a bit more versatile than that, and some are actually using it for compile-time checks, compile-time generative testing, and other nifty things that aren't covered by a "contract" system.

Uh ... no. Type safety is rarely a problem from my personal experience (YMMV) in code dev. The issues I run across have to do with whether or not the code is an accurate reflection of the algorithm in question, or even if the algorithm itself is correct, if core assumptions are correct, dealing with corner cases, etc. Types rarely have anything constructive to add to this mix, regardless of whether or not I am working in a weakly/non-typed language, or strongly typed language.

I personally tend to do something much closer to TDD, and break my code out so I test each part with its own test rig. So I see when I do dumb things that need re-work. Again, typing is pretty much never an issue there.

While this is all anecdotal, I personally have found that enforcing boilerplate type defs actually increases my coding error rate. More LOC gives you more opportunities for errors.

FWIW, Julia (http://julialang.org) is IMO Python done right, and it is strongly typed. But done in such a way as to not actually get in your way most of the time. Like Python it has a great REPL, fantastic FFI, rapidly growing module list, very active development. Unlike Python, it has no issues with whitespace[1], is compiled (JIT for now, though static is planned from what I understand), is very fast, has multiple dispatch and a strong typing system.

The real point the article was making is, programmer time is the most valuable thing to optimize for. I completely agree with this, even though I disagree that Python is the right tool for (most) every job.

There are better tools IMO, which allow me to be far more productive, and spend as little time as possible on worrying about types ... which are rarely ever a concern for me.

I thought his comment about string processing was interesting, though he completely ignored Perl in the mix. I've found string processing in Perl to be almost trivial. Its harder (far more verbose boilerplate) in Python, and gets worse in other languages. Perl6 lets you embed grammars and write parsers without resorting to external modules (Marpa::* in Perl5). Takes building string processing, parsers, etc. to a whole new level, while making you even more productive.

But, as the author had noted, he is a pythonista. Everyone has their biases (including me). I want to code correctly quickly, and not have things that shouldn't get in my way, get in my way. Including type systems, massive boilerplate/odd syntax rules, etc.

[1] It is 2017 ... structure by indentation is somehow, still a thing. It shouldn't be IMO.

That falls down because most static languages have "representational types", not "semantic types". Here's a post of mine on the topic:

https://news.ycombinator.com/item?id=15144364

I do occasionally get problems in Python due to typing issues, but it's pretty infrequent. Nowhere near often enough to care about all that much.