Forgot your password?
New user?
Why I Believe that Haskell Sucks
Document Actions
I've been dealing with Darcs lately, and it has convinced me that real-world programs should not be written in Haskell.
Ok, this is going to be quick, because I don't feel like expounding on this much. Here are some of the reasons that Haskell is not a good language for real-world applications.
- The syntax has significant readability problems.
- Who ever thought it a good idea to allow users to define their own operators? Operators that will be, by the very nature of the allowed characters, entirely opaque as to their actual purpose. What the heck am I supposed to think that
<+>means? Wouldn't it be so much better for the programmer simply to give that function a name and call it? - What the heck is
$? I don't mean, "What does it mean?"--I know what it means. What I'm asking is, "Why does it have to exist in the language?" Why can't we just be satisfied with "foo (bar baz)" instead of "foo $ bar baz"? Is the unambiguous and somewhat obvious rule of parentheses too mundane for the Haskell programmer? - Perhaps it's just Darcs' style, but is it impossible to import a function from a module in such a way that the function is still prefixed with with the modulename? O, that I could easily tell from the function call itself what module a function is defined in!
- And for my greatest personal pet peeve, who in the WORLD thought
whereclauses were a good idea? It is jarring, plain and simple, for me to be reading code and to see a variable name that I've seen before appear out of nowhere, only to be introduced below the place where it's referred to. What was wrong withlet? Honestly?
- Who ever thought it a good idea to allow users to define their own operators? Operators that will be, by the very nature of the allowed characters, entirely opaque as to their actual purpose. What the heck am I supposed to think that
- The semantics have significant predictability problems.
- In no other strict functional language have I seen so many issues with space leaks. The fact that Haskell is lazily evaluated leads to an unpredictability of runtime behavior that simply doesn't happen in a strictly evaluated language. I don't believe that the flexibility lazy evaluation offers is worth the unpredictability it entails.
Anyone up for rewriting Darcs in SML? :)
You are so right.
Posted by
neptune235
at
18:35 October 26, 2005
Haskell is a huge pain. I am having to learn it as part of a college class. I have experience with Python, Java, etc and Haskell is one of the most esoteric languages I have ever seen. Its like the Latin of programming languages...Extremely intellectual and esoteric, not very practical. thereofore like Latin, professors love it. But the lack everyday software at sourceforge written in Haskell after it has been taught in college courses for 7 years tells me that I'm not alone in my perceptions.
I disagree also.
Posted by
ant_morgan
at
18:24 February 11, 2006
Here here to the first comment.
I few things I'd like to add, the $ operator makes a lot of code much clearer, have a look at some ffi code, most of which will start with an unsafePerformIO $ do. Wrapping the whole do construct in parenthesis would be silly. It's not that haskellers consider parenthesis mundane, but rather want to give an option for removing them when it _aids_ readability rather than not have that option. Haskell does not want to be like LISP. If you don't like it don't use it.
As for strictness, you can use seq or indeed the new bang notation to induce it so easily. On the other hand it's much harder to induce, or rather emulate, laziness in a strict language. Some of the abstractions it offers (infinite lists being chief amongst them) are IMO invaluable.
Your obviously not really familiar with the language if you've never seen a qualified import, but your criticism are not just unfair but IMO mostly baseless.
I few things I'd like to add, the $ operator makes a lot of code much clearer, have a look at some ffi code, most of which will start with an unsafePerformIO $ do. Wrapping the whole do construct in parenthesis would be silly. It's not that haskellers consider parenthesis mundane, but rather want to give an option for removing them when it _aids_ readability rather than not have that option. Haskell does not want to be like LISP. If you don't like it don't use it.
As for strictness, you can use seq or indeed the new bang notation to induce it so easily. On the other hand it's much harder to induce, or rather emulate, laziness in a strict language. Some of the abstractions it offers (infinite lists being chief amongst them) are IMO invaluable.
Your obviously not really familiar with the language if you've never seen a qualified import, but your criticism are not just unfair but IMO mostly baseless.
Now then, to address your specific complaints.
The fact that it is possible to define your own operators doesn't mean that you must use that. It's possible to do ugly things in every language. There are plenty of useful purposes for defining your own operators (for instance, a shell-like pipe can be simulated in Haskell this way).
As for $, it is syntactic sugar and is useful when there are several nested function calls (to eliminate lots of levels of parens), or is frequently used with functions composed with (.). Of course it is syntactic sugar. Why does C have to have typedef? Can't we just be satisfied with types as they were? And what is this crap with printf? Can't we just use write(2) and be done with it? Some find it useful, I think it is nice, you can ignore it if you wish.
If you want to import a function such that you must prefix the module name when you call it, simply use "import qualified" instead of "import". It is also possible to explicitly specify which functions you wish to import from a module. There are even more powerful variations on that; see the various online docs for more info.
As for where, sometimes it makes sense, sometimes it doesn't. Sometimes what is defined there is a detail that isn't really important to understanding what the function does. It's a matter of style. (Note that Haskell is hardly alone in letting you reference things earlier in a file than where they're defined; you can even do that in Python in some circumstances.)
As for space leaks, these are no more present in Haskell than in Python, Java, or ML. You can write code that uses vast amounts of memory in any language. Try processing a 2GB file as a single string in Python, or writing an algorithm that generates a 3-billion-member list. These will eat up huge amounts of space in those languages, and very little in Haskell. You're trying to write a lazy algorithm in a strict language.
If you try to write a strict algorithm in Haskell, you will get similar space problems. David Roundy has done a lot of that sort of thing in darcs, and now that he understands Haskell better, is fixing them. (darcs 1.0.4 has many of those fixes checked in.) Also, some of the reason darcs uses a lot of RAM is just because he loads a lot of things into RAM, and is not related to his choice of language.
To me, Haskell is what Python should have evolved to. As a long-time Python programmer, I have been very, very pleased with Haskell and am currently working on porting my code to it (and write new code in Haskell at every opportunity). I have already written a Python interface layer (MissingPy), which can use Python *dbm modules; a LDAP binding; a library of pure-Haskell utility functions; etc. Others have done similar things. It is very much a language that is practically useful.
Here are some Haskell-related links, some I've written, some others have written. <a href="http://changelog.complete.org/node/339">Why I Love Haskell in One Simple Example</a>, <a href="http://www.haskell.org/complex/why_does_haskell_matter.html">Why does Haskell Matter</a>, <a href="http://www.freesoftwaremagazine.com/free_issues/issue_05/haskell/">Haskell: A Very Different Language</a>.