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)
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)