|
Haskell's great contributions to its users are quite often advantages conferred by the type system. A number of the libraries mentioned (e.g. ad, lens, mtl, QuickCheck, MTL, among others) are made either possible or efficient by Haskell's ability to work with static types in a sophisticated and nuanced way. Users of dynamically typed languages talk about "fighting" the type system—and yes, there can be a bit of that, espencially early on—but once you become a proficient Haskell user, you learn to use the type system and the guarantees provided you by the language to enforce properties you want to be true, and thereby effectively use the compiler as a pre-emptive, exhaustive testing mechanism for the correctness of your code. A good Haskell programmer will set up types in such a way that the logic errors of their program will be translated into type errors, so an incorrect program cannot even be compiled. So, I suppose, the target audience of Haskell is people for whom program correctness is a stronger motivation than, say, the speed gains of C/C++ or the development time increases of dynamic languages[1] or the like. (EDIT: To avoid the charge of excessive language zealotry, I should clarify that I don't think program correctness is the overriding factor in all cases, and consequently I don't think Haskell is the correct tool in all situations, as well.) [1]: I personally don't find Haskell particularly slow to develop in—in fact, I find it much faster and easier to develop in than the dynamic languages I know—but I do use it literally daily, and, to be frank, a new programmer will likely find it tricky and confusing until familiarity sets in. Similarly, Haskell can—used correctly—have spectacular performance, sometimes matching C and beating out C++, but again, it takes experience and understanding to milk the best performance out of Haskell. |