It's possible I'm an idiot, but I suspect my co-workers would fare worse, and it damns the language in my book.
No, you're definitely not an idiot. Haskell's type system is a completely different language, semantically speaking, from its language of terms. This type language is much more like a logic programming language than a functional one. Type variables are unified by the type inference engine, a concept with which most people are unfamiliar. Type constructors are easily mistaken for data constructors (they often use the same name). A lot of Haskell tutorials gloss over these details which is unfortunate.
Please don't get discouraged. Once you start to grok the type system you'll be amazed at how powerful it is. It's pretty incredible how well it works at inferring all the types and catching countless errors. The oft-cited claim that Haskell programs "just work" once they pass the type-checker is true in the vast majority of cases. The amount of work it saves you by not having to write (and maintain) unit tests is staggering.
I'm familiar with the argument that strict typing catches bugs, but some bugs are trivial and a few are very tricky. Based on my experience with languages besides Haskell (which I don't know), I suspect that the kinds of bugs computers catch automatically aren't likely to be bad ones. The bad ones are runtime errors and logic errors, and I guess there are two kinds of these: ones that come from sloppy coding, and ones where you made an error in thinking. The type-checker might help with the sloppy ones. But I think the best language defense against those is to be concise and readable, so the logic is easy to see and you don't lose the forest for the trees.
That's just the thing: Haskell's type system catches many, many bugs that would be runtime errors in most other languages. It can even provide static guarantees against extremely tricky bugs such as race conditions!
sloppy coding
Everybody is guilty of sloppy coding some of the time. Having a powerful sanity check against it is extremely helpful.
ones where you made an error in thinking
Haskell can actually help here, too. Its rigid purity forces you to think more carefully before you act and its powerful expressiveness enables you to build highly composable abstractions that are simply not possible in other languages.
Edit: Check out this talk on someone's personal experience with static typing in real projects at work:
I very rarely have much trouble finding bugs that I made myself. The hardest bugs are the ones somebody else had a hand in. I'm sure everyone wishes they could force their coworkers to be more careful. :)
No, you're definitely not an idiot. Haskell's type system is a completely different language, semantically speaking, from its language of terms. This type language is much more like a logic programming language than a functional one. Type variables are unified by the type inference engine, a concept with which most people are unfamiliar. Type constructors are easily mistaken for data constructors (they often use the same name). A lot of Haskell tutorials gloss over these details which is unfortunate.
Please don't get discouraged. Once you start to grok the type system you'll be amazed at how powerful it is. It's pretty incredible how well it works at inferring all the types and catching countless errors. The oft-cited claim that Haskell programs "just work" once they pass the type-checker is true in the vast majority of cases. The amount of work it saves you by not having to write (and maintain) unit tests is staggering.