I have seen my share of "innovations" come and go, but I too fail to see the empirical evidence that most bugs/errors are caused by type mismatch. In fact, I would even go as far as to argue that in my experience the benefits of typed languages (and the class of bugs they prevent) do not outweigh the usually larger code size (and often even additional complexity).

Maybe I've just tried the wrong languages, but I was never convinced of the great improvements usually promised. At the same time, I have seen other people twist and jump through hoops, while vigorously holding on to their conviction how all that is an improvement.

Sure, some errors will move from run time to compile time with typed languages. But if those are a systemic problem in your code, you probably have even bigger things to worry about (the ones you already keenly pointed out).

From a cynical point of view, I can understand why corporate entities would love typed languages (for the increased code size and complexity), but that's another story.

For the (pretty obvious) logical error of claiming that you have to believe that most errors are caused by type mismatch to consider stating typing beneficial.

A value of the wrong type passed forward because it's almost the right type can cause errors that make their way into production.

I hear you say "so unit test your code!", and to that I reply, we're a c# shop that has only recently started pushing some of our code to the client. If you can convince management that we should shift our paradigm to allow for the time to write tests that don't add much to the sprint we're in, I can send you their email address.

The fact is, a large portion of unit tests solve the same problems that strong types solve.

1.) The fact that I even got involved meant the issues were particularly hard to track down

2.) These errors seem to be more of a time sync within a larger team/project than many realize

Typically these were caused by either scope issues and/or some context object that's been riding dirty all day. In the case of the latter hunting down the code that did the naughty can be particularly soul crushing.

By having types, you open the door to formally describing the building blocks of your system. This lets you create very specific, well understood, pure pieces that then are composed together to bring about your desired functionality.

Why rely on documentation that a compiler cannot statically verify, as opposed to a type (annotation or otherwise) that can?

I think you're correct regarding your "most errors are caused by" comment, and no programming paradigm will ever get rid of these - you can always find a way to write bad code. And you are also correct that there are type zealots out there who create beautiful prisons they call abstractions. But at the end of the day, types are a tool, and while I'd highly recommend learning them, I also recognize some projects and teams will never make use of them.

If you eliminate a class of errors by doing so, isn't that still less errors overall?

Static types are documentation. Better yet they're documentation that can't go stale without a computer yelling at you that it's wrong.

> Static types are documentation. Better yet they're documentation that can't go stale without a computer yelling at you that it's wrong.

Absolutely, and I'd go further:

"Most errors, in my experience, are caused by bad architecture, poor documentation, and poor communications strategies between MVC, etc"

Good static types (a la Hindley-Milner) encourage good architecture, serve is documentation that cannot go stale, and encourage good communication strategies between different parts of a codebase.