You are utterly missing the point. Of course any code that can be written in a type-safe manner in Haskell can be written in another language to perform the exact some machine operations. The point is that the compiler guarantees that this code will never break as long as the code compiles. In less type-safe languages you simply don't have these guarantees, no matter how careful you are, eventually someone will come along and break an assumption that kept the original code working.
You shouldn't consider this to be a break. Sure, it's crappy API design--lots of people have pointed out that `head` should return a `Maybe` because an empty list doesn't have a head--but triggering an error in a partial function is not a break. Taking the head of an empty list is no more a break than dividing something by zero.
I can't see any reasonable definition of "break" for this context for which that is valid; its exactly the same kind of breakage that strong type checking reduces the incidence of in Haskell compared to dynamic languages -- runtime errors resulting from a function call not being able to complete without error for all inputs that the language will allow to be passed to it.
> Taking the head of an empty list is no more a break than dividing something by zero.
I agree; both are clearly examples of things that can cause a program to break.
Good point, but in general I think it's fair to say that if Java's type system prevents the type of breakages that are possible in ruby 50% of the time, Haskell prevents 99.9% of such breakages.
I'm talking about maintenance, obviously you must make sure the code does the correct thing initially. I have maintained a 100k LOC Rails app for 7 years with near 100% test coverage. And guess what? Stuff breaks. 99% of the stupid breakages I have experienced would have been impossible in Haskell.
