Harper's an accomplished person in CS and has done great work, but he's not putting a good argument forward here.<p>I've talked to Harper about this post and his opposition to Haskell before. I mentioned that it was leading people to believe they could ignore typed FP, not redirecting to an ML derivative. Harper expressed dismay at this.<p>There are more advanced languages than Haskell, they aren't ML, and PL researchers/experimenters are still working out how to make them work nicely for day to day stuff.<p>First: <a href="http://www.cs.ox.ac.uk/jeremy.gibbons/publications/fast+loose.pdf" rel="nofollow">http://www.cs.ox.ac.uk/jeremy.gibbons/publications/fast+loos...</a> (This isn't a throw-away reference, informal reasoning has worked extremely well in practice. Yes, I'm making <i>that</i> argument as a user of a pure, typed FP language.)<p>unsafePerformIO is primarily used to change thunk-memoization behavior [1]. Also, it says unsafe right on the tin. Nobody uses it in practice in ordinary code. It's not something you have to incorporate when reasoning about code.<p>Giving up reasoning about your Haskell code as if there were semantics-violating unsafePerformIOs lurking in the depths is similar to giving up reasoning about any code because a cosmic ray might flip a bit.<p>Lets consider the rather remarkable backflips Standard ML and OCaml had to perform in order to make FP work with strictness and impurity.<p>You can ignore unsafePerformIO because very very few people ever need it and you'll almost never have a reason to use it. Just don't use it.<p>Similarly, writing total functions is the cultural default in Haskell. The compiler warns on incomplete pattern matches which you can -Werror as well.<p>You can't define your own Typeable instances as of GHC 7.8 - only derive them, so that soundness issue is gone. Typeable itself is not popularly used, particularly as SYB has fallen out of favor. One critical aspect of why I like Haskell and the community around it is the willingness to fix mistakes. Meanwhile, ML implementations still use the value restriction.<p>>the example once again calls into question the dogma<p>Oh please. Haskell is an ensemble, multi-paradigm language with the right defaults (purity, types, immutability, expressions-only) and escape hatches for when you need them.<p>Haskellers appreciate the value of modules a la ML, but typeclasses and polymorphism by default have proven more compelling in the majority of use-cases. There are still some situations where modules (fibration) would be preferred without resorting to explicit records of functions. For those cases, Backpack [3] is in the works. It won't likely satisfy serious ML users, but should hopefully clean up gaps Haskell users have identified on their own.<p>Harper's case is over-stated, outdated, and not graced with an understanding of how Haskell code is written. Informal reasoning works if the foundations (purity, types, FP) are solid.<p>[1]: <a href="https://github.com/bitemyapp/blacktip/blob/master/src/Database/Blacktip.hs#L47-L54" rel="nofollow">https://github.com/bitemyapp/blacktip/blob/master/src/Databa...</a><p>[2]: <a href="http://caml.inria.fr/pub/papers/garrigue-value_restriction-fiwflp04.pdf" rel="nofollow">http://caml.inria.fr/pub/papers/garrigue-value_restriction-f...</a><p>[3]: <a href="http://plv.mpi-sws.org/backpack/" rel="nofollow">http://plv.mpi-sws.org/backpack/</a>