[alpaca128]

Static types aren't training wheels, though. They're seatbelts. Without it the same type checks still have to be done, but this time by humans. And experience doesn't make them much more reliable at manually doing tedious checks.

[diragon]

>Without it the same type checks still have to be done, but this time by humans.

Nah, they don't have to be done. Most programmers using dynamic languages just don't think about types until they need to be thought. That implies there's more resources/energy available to think about the actual problem, which often has almost nothing to do with types. Then if you're using something like Common Lisp/SBCL, you can define the types afterwards where they are most critical.

Doing all this well in a dynamic language requires more discipline obviously, since you cannot even release software in a stricter static language if it fails to pass the type checking phase. But it is faster, sometimes significantly faster. Sometimes it may even happen that the coder could not have finished the task in a stricter language, which would imply that the the dynamic language was infinitely faster.

[yxhuvud]

Static types can also be a straitjacket. Type systems have improved greatly over time though, so the balance is shifting. The world is not stuck at the point in time (2003) when the article was written, and type systems in general use have improved a lot with both more flexibility, protective power and less bloat.

[go_elmo]

It is just a part of automation to have a static type system, instead of having to do it manually which is the worst task for humans (tedious and error prone). Everyone having to use some python code consisting out of 4 half-baked libraries can confirm - it is a nightmare, at least for me!