Talk:Why Haskell matters
I wikified my old article for easier modification by the community (up until now people had to email me and then i would upload a new version -- time consuming!) --SebastianSylvan 06:48, 9 January 2006 (EST)
Hopefully I'm preaching to the choir here, but I'd just like to clarify that I'm perfectly fine with, and actively encourage, large-scale editing of this (I wouldn't put it on the wiki otherwise!). Just because it at one point was a stand-alone article with me as the author doesn't mean it shouldn't be substantially modified. For instance, the speed-section could be updated with some references to the language shootout, removing some pointless bits, etc. So go nuts! --SebastianSylvan 13:55, 22 January 2006 (UTC)
On the page it refers to Haskell's speed being better than C++ and provides a link to the programming language shootout. I don't find that when I go there. Has something changed? I'd like to see benchmarks where Haskell has performed that well, but I haven't found any. Please let me know --Kylebutt 06:26, 3 February 2007 (UTC)
Kyle, sorry that this is over a year after your question... but I think it means the development speed: It takes a fraction of the time to develop in Haskell. Also, the shootout shows Haskell performing very well on multi-core systems. Not quite to pace with C, but barely behind. Cheers. Cknapp 17:01, 25 November 2008 (UTC)
(Edit: To give this section some context, I found this page while looking for a good introduction to entice someone into trying Haskell. Unfortunately, the content of this page was such that I could not pass it on to them in good faith.)
There are numerous untrue and/or ridiculous claims on this page.
1. "In Haskell, the sequencing task is removed. You only care what the program is to compute not how or when it is computed."
This is clearly not true. Maybe it is "often true", but that's not the same thing.
2. You wouldn't expect "4 = 5" to be a valid assignment in any language, so it's really quite strange that "x = 4; x = 5" is.
If you replace "=" with "<-", does the claim still hold? Oh wait, that's Haskell's "do" syntax. This is an argument about syntax trivialities, not anything substantial.
3. "Furthermore Haskell doesn't allow side-effects, which leads to less bugs."
But it does; they just happen in the IO monad. OpenGL programming isn't magically safer in Haskell than in C++; or, at least, not for this reason alone.
4. "You could argue that Haskell has a much better form of duck typing."
No you can't. You'd need some form of structural record types at a minimum. That's not to say you can't solve the problem another way, but the way you're solving it definitely won't be via duck typing.
5. "Furthermore Haskell will always infer the most general type on a variable."
No it won't, but I can let this one go.
6. "It all amounts to tons of extra work and ridiculously complex declarations just to proclaim the existence of a variable. Furthermore you would have to perform tons of type conversions via explicit casts - definitely not a particularly elegant solution."
This sounds more like a criticism of Java than OOP. I suppose that's why Java is used as an example later in the paragraph.
7. "Programs will not crash unexpectedly, nor produce strangely garbled output."
Yes they will. Maybe less often, but this claim is far too bold.
8. "Haskell does include mechanisms for data encapsulation that match or surpass those of OOP languages."
This whole section is bogus. Neither abstract data types implemented via the module system nor type classes provide the sort of open recursion and dynamic dispatch that you get in an OO language. You can get most of the way there with existentials/GADTs but they aren't mentioned at all in the paragraph (nor are they standard Haskell). Haskell also lacks the subtyping found in virtually all typed OO languages. See http://userweb.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf.
Johnnowak 01:23, 15 April 2010 (UTC)
In addition to the problems Johnnowak mentions, the QuickSort example code is extremely misleading.
1. First off, it's not quicksort. See http://augustss.blogspot.com/2007/08/quicksort-in-haskell-quicksort-is.html
2. Second, on my machine, the Haskell version runs in 10x the runtime and 8x the RAM of the C++ version, a key performance point not mentioned in the text.
3. Third, even laying aside whether the sort is officially "quicksort", and allowing this "Haskell sort" as an illustration, it's important to note that the actual standard quicksort is much simpler to write in C++ than the version shown here. The standard implementation is also even faster (by another factor of 5x, for 50x total) and has lower memory footprint. (http://stackoverflow.com/questions/7717691/why-is-the-minimalist-example-haskell-quicksort-not-a-true-quicksort)
In fact, you can write a standard quicksort in Haskell (as shown on Augustss's blog), and it turns out to have about the same performance and code complexity as the C++ version.
So, all the example seems to show is that Haskell makes it easy to write slow, heavy programs. Which is nice (and competitive with scripting languages, maybe), but not at all the point the article is trying to make.
Drbb 05:49, 4 January 2012 (UTC)