8 ms·

In Praise of Haskell

55 points by tel 13y ago

skwirl 13y ago
This is yet another shallow puff piece on Haskell. Reading it, you would think that the author has only ever used Ruby and Haskell, as he gives the impression Haskell is the only language that supports functional/declarative style programming. In actuality the author is trying to sell Haskell because he sells Haskell IDEs. I'm not knocking Haskell, but let's not pretend that this is a useful piece of journalism.
- iamdev 13y ago
  As someone who has been curious about Haskell, I'm happy to hear someone else say this. The way this article was written feels exactly like the "ruby fever" of 5 years ago.
  - zwieback 13y ago
    Or all the other fevers we've suffered through. Haskell seems like an attractive language but I wish boosters wouldn't advocate their languages as the fix to the problems of large-scale software engineering issues when there's little or no evidence for their claims.
    - chongli 13y ago
      Well, the problem with this is that the evidence is locked up in company trade secrets. A lot of the big commercial users of Haskell are in finance and all their code is under lock and key.
    - cschneid 13y ago
      There was a cool talk on "The Haskell Chat" episode two [1] that goes over how haskell is used in a large team, some members with expert haskell knowledge, some as just technical end-users of the libraries. I found it really interesting to see how a large team can deal with a real haskell project. [1]: http://www.haskellcast.com/episode/002-don-stewart-on-real-world-haskell/ http://www.haskellcast.com/episode/002-don-stewart-on-real-w...
  - chongli 13y ago
    "ruby fever" of 5 years ago The difference is that Haskell is a very principled language. All of the claims and excitement are actually backed up by mathematical proofs. Pure functions really do make your code easier to maintain. And no, it's not the case that Haskell is the only language which allows you to write pure functions. People who try to claim that are being silly and dishonest. Haskell's advantage is that its type system allows you to know at a glance whether or not a function is pure.
    - tmhedberg 13y ago
      While I fully agree that pure code is far easier to maintain than impure code, and the advantages of Haskell are numerous, I think it is a bit strong to state that such claims are backed up by mathematical proofs. Ease of maintenance is a fundamentally subjective claim that cannot be proven, but must be borne out by individual experience (as it has been for you, me, and many others).
      - chongli 13y ago
        Ease of maintenance is a fundamentally subjective claim that cannot be proven, but must be borne out by individual experience (as it has been for you, me, and many others). I disagree. You can make objective measurements of maintainability. You can look at cyclomatic complexity and reusability (both wins for pure functions). You can test how often changes lead to bugs and how often the errors are caught. There are many instances of Haskell code where there is only one sensible implementation of a function, given its type. Hell, some Haskell libraries have even been formally verified though admittedly that is done with external packages. I will agree on one thing, though: you do run into trouble when you throw around the word all (or indeed any absolute) without actually meaning it.
        bunderbunder 13y ago
        > You can look at cyclomatic complexity and reusability (both wins for pure functions). Yes, those are both wins for pure functions. But even there you need an asterisk, because side effects do have their place - the fact of the matter is, the primary task of most real-world software can be summed up as "manipulating mutable state". In light of that I don't think you can necessarily jump from the observation that there are many situations where pure functions are easier to work with than impure ones to the conclusion that pure functions are inherently more maintainable. But even if that were granted for the sake of argument, it's not much of a win for Haskell. The ability to create pure functions is a feature of every language that has been invented during the lifetime of probably every person reading this post, and therefore not really a differentiating feature of Haskell. Nor is lack of ability to create impure functions a feature that can be claimed of Haskell, because that simply isn't true. Haskell's real differentiator in that department is just that you've got to jump through hoops to do it. And if your business rules are inherently impure, then it's not clear to me how a language that tries to ghettoize impurity makes them easier to implement.
- cia_plant 13y ago
  Yeah, definitely just more propaganda from "Big Haskell IDE".
  - scarmig 13y ago
    There's no threat more pernicious to America. Soon we'll have an Haskell IDE individual mandate and from there it's just a slippery slope.
  - deleted 13y ago
    [deleted]
  - skwirl 13y ago
    The author is the CEO of a company that sells the first (and only?) commercial Haskell IDE. I point this out because the author (from his background) clearly knows about the subject matter, while reading the content of the article would lead you to believe the author was a novice to software development and computer science. The shallowness of the article combined with the background of the author can be reconciled if you understand the article as an advertisement.
clux 13y ago
What's not to like? Cabal, which unsurprisingly is not mentioned. Dependency hell makes it stupidly difficult to rely on other people's code on a large scale. I'd rather write uglier code in JavaScript if it means having access to other people's packages immediately and without complications.
- otikik 13y ago
  Also, after a week I still didn't understand its type system completely. It may be that I am simply too dumb, or that I didn't find the right resources, but 'easy to learn' this language is not.
  - carterschonwald 13y ago
    If you're stuck, asking questions on the Haskell irc channel on freenode is a great way to get feedback. Learning new things is a social process, not something to be done in a padded room. :-)
  - pnathan 13y ago
    The type system is considerably more sophisticated than most languages we're accustomed to.
  - platz 13y ago
    I'm learning too. Btw, which resources are you using?
  - tieTYT 13y ago
    The problem is you only waited a week. Haskell is so different from the most popular languages you should approach it like you're learning programming for the first time.
  - chongli 13y ago
    Rome wasn't built in a day! Learning a new language in a week is not an easy thing to do. The reason other languages seem a lot easier to learn (Python, Ruby, etc.) is that those languages are all fundamentally similar to one another; Haskell is not.
iamdev 13y ago
The example provided is too contrived. By that logic, here's a way to "match" haskell with php: $a = range(2,100,2); $b = array_slice($a, 5);
- freyrs3 13y ago
  Haskell's version is type safe. PHP, not so much.
  - iamdev 13y ago
    Thanks for pointing that out. The author didn't emphasize that point, and it makes sense now. Is it me, or was it a bad example for where Haskell "really shines"? I don't like the "use Haskell cause it has these really cool functions" approach. Feels so superficial.
    - scarmig 13y ago
      I think the strongest argument for Haskell is what you can make it not do, not what you can make it do. Having strong and concise type guarantees is great. Haskell's a great example of that. So is Ocaml.
    - nahiluhmot 13y ago
      It wasn't so much a bad example so much as it was a trivial one. Perhaps a more powerful one (that displays the advantages of lazy evaluation and higher-order functions) would be the function to generate an infinite list of Fibonacci numbers. fibs :: [Integer] fibs = 0 : 1 : zipWith (+) fibs (tail fibs) Even still, it's difficult to get the feel of actually using the language from one function taken from a freshman year CS class.
      - cgh 13y ago
        How about demonstrating the power of laziness by generating the power set of a set? (Taken from Learn You a Haskell). powerset :: [a] -> [[a]] powerset xs = filterM (\x -> [True, False]) xs ghci> powerset [1,2,3] [[1,2,3],[1,2],[1,3],[1],[2,3],[2],[3],[]] Edit: I read LYaH some time ago but this example stuck with me because it's both wonderful and mind-blowing.
seliopou 13y ago
I have and will continue to maintain that it's Haskell's operational challenges that are holding it back from wide adoption, at least on the web. In a lazy language, your cost model is all out of whack. When your program consumes resources, you can't unambiguously identify the line of code that caused your program to consume those resources. That's because a function application itself does nothing. Needing the result of the application is what causes work to be done. And that function application could be floating through your program as a thunk for who knows how long until its result (probably a partial result at that) is forced. So who's to blame for the work? The function application or the code that forced its result? Who knows. The typical solution to this problem in production Haskell systems, by the way, is to run the application with profiling turned on.
- jfoutz 13y ago
  Avoid success at all costs!
- carterschonwald 13y ago
  There Is some preliminary work to add a "Strict language" mode that can be selectively enabled per module. Johan Tibbel has some experimental support worked out, and hopefully it can be polished enough to make it Ito ghc 7.10 in the next year.
DanielBMarkham 13y ago
One important thing in the article that was a bit obfuscated: modern OOP languages introduce a staggering amount of dependency and complexity. Things like TDD are then layered on top to try to ensure solid code is being built. In a pure functional environment, you don't have those dependency issues. Your problems boil down to types -- do you have the correct fields and definitions in your inputs? -- and transforms -- are your symbolic transformations what is desired? In practice, pure FP is the closest I've seen to stuff that "just works". While FP can be a huge pain in the ass mentally, it beats the heck out of the spaghetti dependency issues in OOP. [insert long discussion here about whether pure FP can actually scale in a large organization]
- taeric 13y ago
  Is it irony that the post right below this is complaining about Cabal and "dependency hell?"
  - platz 13y ago
    I think the package system needs work, yes, but I'm not sure this is the fault of "Haskell the Language". Although I've read some blogs that complained that ML gets this right, and Haskell makes it harder with it's typeclasses
    - taeric 13y ago
      I think for a lot of folks, the differences between languages and the surrounding toolset is very diminished. That is, there seems little gain in making this distinction.
  - nightski 13y ago
    No because that dependency hell is up front (Haskell ecosystem likes being explicit). Whereas in dynamic languages you just install it all and hope it doesn't crash (and your unit test coverage is sufficient).
    - 13y ago
thinkpad20 13y ago
Unless someone had literally never seen anything on Haskell before, this kind of article adds absolutely nothing new to the discussion. It's all been said before, and more often than not it's been said by FP Complete. It reads like an infomercial, and it's frankly embarrassing reading it.

55 points by tel 13y ago

This is yet another shallow puff piece on Haskell. Reading it, you would think that the author has only ever used Ruby and Haskell, as he gives the impression Haskell is the only language that supports functional/declarative style programming. In actuality the author is trying to sell Haskell because he sells Haskell IDEs. I'm not knocking Haskell, but let's not pretend that this is a useful piece of journalism.

iamdev 13y ago
As someone who has been curious about Haskell, I'm happy to hear someone else say this. The way this article was written feels exactly like the "ruby fever" of 5 years ago.
- zwieback 13y ago
  Or all the other fevers we've suffered through. Haskell seems like an attractive language but I wish boosters wouldn't advocate their languages as the fix to the problems of large-scale software engineering issues when there's little or no evidence for their claims.
  - chongli 13y ago
    Well, the problem with this is that the evidence is locked up in company trade secrets. A lot of the big commercial users of Haskell are in finance and all their code is under lock and key.
  - cschneid 13y ago
    There was a cool talk on "The Haskell Chat" episode two [1] that goes over how haskell is used in a large team, some members with expert haskell knowledge, some as just technical end-users of the libraries. I found it really interesting to see how a large team can deal with a real haskell project. [1]: http://www.haskellcast.com/episode/002-don-stewart-on-real-world-haskell/ http://www.haskellcast.com/episode/002-don-stewart-on-real-w...
- chongli 13y ago
  "ruby fever" of 5 years ago The difference is that Haskell is a very principled language. All of the claims and excitement are actually backed up by mathematical proofs. Pure functions really do make your code easier to maintain. And no, it's not the case that Haskell is the only language which allows you to write pure functions. People who try to claim that are being silly and dishonest. Haskell's advantage is that its type system allows you to know at a glance whether or not a function is pure.
  - tmhedberg 13y ago
    While I fully agree that pure code is far easier to maintain than impure code, and the advantages of Haskell are numerous, I think it is a bit strong to state that such claims are backed up by mathematical proofs. Ease of maintenance is a fundamentally subjective claim that cannot be proven, but must be borne out by individual experience (as it has been for you, me, and many others).
    - chongli 13y ago
      Ease of maintenance is a fundamentally subjective claim that cannot be proven, but must be borne out by individual experience (as it has been for you, me, and many others). I disagree. You can make objective measurements of maintainability. You can look at cyclomatic complexity and reusability (both wins for pure functions). You can test how often changes lead to bugs and how often the errors are caught. There are many instances of Haskell code where there is only one sensible implementation of a function, given its type. Hell, some Haskell libraries have even been formally verified though admittedly that is done with external packages. I will agree on one thing, though: you do run into trouble when you throw around the word all (or indeed any absolute) without actually meaning it.
      - bunderbunder 13y ago
        > You can look at cyclomatic complexity and reusability (both wins for pure functions). Yes, those are both wins for pure functions. But even there you need an asterisk, because side effects do have their place - the fact of the matter is, the primary task of most real-world software can be summed up as "manipulating mutable state". In light of that I don't think you can necessarily jump from the observation that there are many situations where pure functions are easier to work with than impure ones to the conclusion that pure functions are inherently more maintainable. But even if that were granted for the sake of argument, it's not much of a win for Haskell. The ability to create pure functions is a feature of every language that has been invented during the lifetime of probably every person reading this post, and therefore not really a differentiating feature of Haskell. Nor is lack of ability to create impure functions a feature that can be claimed of Haskell, because that simply isn't true. Haskell's real differentiator in that department is just that you've got to jump through hoops to do it. And if your business rules are inherently impure, then it's not clear to me how a language that tries to ghettoize impurity makes them easier to implement.
cia_plant 13y ago
Yeah, definitely just more propaganda from "Big Haskell IDE".
- scarmig 13y ago
  There's no threat more pernicious to America. Soon we'll have an Haskell IDE individual mandate and from there it's just a slippery slope.
- deleted 13y ago
  [deleted]
- skwirl 13y ago
  The author is the CEO of a company that sells the first (and only?) commercial Haskell IDE. I point this out because the author (from his background) clearly knows about the subject matter, while reading the content of the article would lead you to believe the author was a novice to software development and computer science. The shallowness of the article combined with the background of the author can be reconciled if you understand the article as an advertisement.

clux 13y ago

What's not to like? Cabal, which unsurprisingly is not mentioned. Dependency hell makes it stupidly difficult to rely on other people's code on a large scale. I'd rather write uglier code in JavaScript if it means having access to other people's packages immediately and without complications.

otikik 13y ago
Also, after a week I still didn't understand its type system completely. It may be that I am simply too dumb, or that I didn't find the right resources, but 'easy to learn' this language is not.
- carterschonwald 13y ago
  If you're stuck, asking questions on the Haskell irc channel on freenode is a great way to get feedback. Learning new things is a social process, not something to be done in a padded room. :-)
- pnathan 13y ago
  The type system is considerably more sophisticated than most languages we're accustomed to.
- platz 13y ago
  I'm learning too. Btw, which resources are you using?
- tieTYT 13y ago
  The problem is you only waited a week. Haskell is so different from the most popular languages you should approach it like you're learning programming for the first time.
- chongli 13y ago
  Rome wasn't built in a day! Learning a new language in a week is not an easy thing to do. The reason other languages seem a lot easier to learn (Python, Ruby, etc.) is that those languages are all fundamentally similar to one another; Haskell is not.

iamdev 13y ago

The example provided is too contrived. By that logic, here's a way to "match" haskell with php: $a = range(2,100,2); $b = array_slice($a, 5);

freyrs3 13y ago
Haskell's version is type safe. PHP, not so much.
- iamdev 13y ago
  Thanks for pointing that out. The author didn't emphasize that point, and it makes sense now. Is it me, or was it a bad example for where Haskell "really shines"? I don't like the "use Haskell cause it has these really cool functions" approach. Feels so superficial.
  - scarmig 13y ago
    I think the strongest argument for Haskell is what you can make it not do, not what you can make it do. Having strong and concise type guarantees is great. Haskell's a great example of that. So is Ocaml.
  - nahiluhmot 13y ago
    It wasn't so much a bad example so much as it was a trivial one. Perhaps a more powerful one (that displays the advantages of lazy evaluation and higher-order functions) would be the function to generate an infinite list of Fibonacci numbers. fibs :: [Integer] fibs = 0 : 1 : zipWith (+) fibs (tail fibs) Even still, it's difficult to get the feel of actually using the language from one function taken from a freshman year CS class.
    - cgh 13y ago
      How about demonstrating the power of laziness by generating the power set of a set? (Taken from Learn You a Haskell). powerset :: [a] -> [[a]] powerset xs = filterM (\x -> [True, False]) xs ghci> powerset [1,2,3] [[1,2,3],[1,2],[1,3],[1],[2,3],[2],[3],[]] Edit: I read LYaH some time ago but this example stuck with me because it's both wonderful and mind-blowing.

seliopou 13y ago

I have and will continue to maintain that it's Haskell's operational challenges that are holding it back from wide adoption, at least on the web. In a lazy language, your cost model is all out of whack. When your program consumes resources, you can't unambiguously identify the line of code that caused your program to consume those resources. That's because a function application itself does nothing. Needing the result of the application is what causes work to be done. And that function application could be floating through your program as a thunk for who knows how long until its result (probably a partial result at that) is forced. So who's to blame for the work? The function application or the code that forced its result? Who knows. The typical solution to this problem in production Haskell systems, by the way, is to run the application with profiling turned on.

jfoutz 13y ago
Avoid success at all costs!
carterschonwald 13y ago
There Is some preliminary work to add a "Strict language" mode that can be selectively enabled per module. Johan Tibbel has some experimental support worked out, and hopefully it can be polished enough to make it Ito ghc 7.10 in the next year.

DanielBMarkham 13y ago

One important thing in the article that was a bit obfuscated: modern OOP languages introduce a staggering amount of dependency and complexity. Things like TDD are then layered on top to try to ensure solid code is being built. In a pure functional environment, you don't have those dependency issues. Your problems boil down to types -- do you have the correct fields and definitions in your inputs? -- and transforms -- are your symbolic transformations what is desired? In practice, pure FP is the closest I've seen to stuff that "just works". While FP can be a huge pain in the ass mentally, it beats the heck out of the spaghetti dependency issues in OOP. [insert long discussion here about whether pure FP can actually scale in a large organization]

taeric 13y ago
Is it irony that the post right below this is complaining about Cabal and "dependency hell?"
- platz 13y ago
  I think the package system needs work, yes, but I'm not sure this is the fault of "Haskell the Language". Although I've read some blogs that complained that ML gets this right, and Haskell makes it harder with it's typeclasses
  - taeric 13y ago
    I think for a lot of folks, the differences between languages and the surrounding toolset is very diminished. That is, there seems little gain in making this distinction.
- nightski 13y ago
  No because that dependency hell is up front (Haskell ecosystem likes being explicit). Whereas in dynamic languages you just install it all and hope it doesn't crash (and your unit test coverage is sufficient).
  - 13y ago

thinkpad20 13y ago

Unless someone had literally never seen anything on Haskell before, this kind of article adds absolutely nothing new to the discussion. It's all been said before, and more often than not it's been said by FP Complete. It reads like an infomercial, and it's frankly embarrassing reading it.