Steve Schafer wrote:
Neil Bartlett wrote:
It also highlights some of the misconceptions that still exist and need to be challenged, e.g. the idea that Haskell is too hard or is impractical for real work.
Haskell _is_ hard, although I don't think it's _too_ hard, or I wouldn't be here, obviously. Haskell is hard in the sense that in order to take advantage of its ability to better solve your problems, you have to THINK about your problems a lot more. Most people don't want to do that; they want the quick fix served up on a platter. And even the "intermediate" camp, the ones who are willing to invest some effort to learn a better way, are only willing to go so far.
I agree, but I think it should be pointed out that primarily it is not Haskell which is hard, it is Programming which is. Haskell only reflects this better than the mainstream imperative languages. The latter encourage and support operational reasoning, i.e. creating and understanding programs by mentally modeling their execution on a machine. This form of reasoning appeals to 'common sense', it is familiar to almost all (even completely un-educated) people and is therefore easier acessible to them. Haskell (more specifically: its purely functional core) makes such operational reasoning comparatively hard(*). Instead it supports and greatly simplifies denotional resp. equational reasoning(**), i.e. to understand a program as an abstract formula with certain logical properties; an abstract entity in its own right, independent of the possibility of execution on a machine. This way of thinking is less familiar to most people and thus appears 'difficult' and even 'impractical' -- it requires a mental shift to a more abstract understanding.(***) What the hard-core 'common sense' type can't see and won't accept is that denotational reasoning is strictly superior to operational reasoning (at least with regard to correctness), if only because the latter invariably fails to scale with the exploding number of possible system states and execution paths that have to be taken into account for any non-trivial program. As Dijkstra once said, the main intellectual challenge for computer science resp. programming is: how not to make a mess of it. Those who don't want to think will invariably shoot themselves in the foot, sooner or later. Their programs become a complex, unintelligible mess; the prefered choice of apparently 'easier' or 'more practical' programming languages often (but not always) reflects an inability or unwillingness to appreciate the intellectual effort required to avoid building such a mess. Cheers Ben (*) The downside of which is that it is also quite hard to reason about a program's efficiency in terms of memory and CPU usage. (**) At least the 'fast and loose' version of it, i.e. disregarding bottom and seq. (***) Many Haskell newcomers have described the feeling of being 'mentally rewired' while learning programming in Haskell. IMO this is a very good sign!