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.

Edit by someonelse: Sorry, I really cannot let this statement leave it here uncommented: Apart from that I get the impression that you misunderstood the concept of monads, the replacement of "=" with "<-" has nothing to do with syntax trivialities. The "->" in the "do syntax" is syntactic sugar for the submission of a value as the result of a computation to the argument of another function, and has little to do with the definition of a value as a language primitive via "=". JHannes

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)

To encounter some of those points of Drbb:

1. I don't understand why people tend to say this isn't quicksort: The quicksort algorithm of Tony Hoare consists of just three simple steps, 1. pick an pivot element form the list, 2. put all elements, smaller than the pivot element in front of the pivot and all elements larger behind (equal can go either way), 3. recursively sort the two created sublists in the same way. And this is exactly what the algorithm does. All further restrictions and ways of partitioning etc. are already variants of quicksort, and of those exist enough to fill books with. Thus implementing quicksort in a sequenced way as shown in the blog entry (link above) isn't really in the sense of implementing an easy and readable alrorithm nor does it have any benefit.

2. This statement says absolutely nothing, first of all it would be interesting what program/algorithm was measured and second if it was implelemted in the exactly same way in both languages (which I doubt). There exists a bunch of more reliable benchmarks of Haskell (http://shootout.alioth.debian.org/u64q/haskell.php) that indeed show Haskell isn't much slower than the fastest GPLs nowadays. But the main point of the author was actually to say, that a much less development time is mostly more important than slightly faster execution time.

3. Keep in mind that the Hakell version is polymorph. There may be easier ways to implement this in C++ without any additional libraries, but those may just be posted here.

I absolutely disagree that Haskell programms are slow and heavy, and I don't think this is the impression the reader of this article gets.

JHannes 10:56, 22 March 2012 (UTC)