7 ms·

Yikes. That might as well be titled "Why functional languages will never catch on." It took something dead simple (a function that adds 3), and made it insanel

by balloot 13y ago

Yikes. That might as well be titled "Why functional languages will never catch on." It took something dead simple (a function that adds 3), and made it insanely complicated. Why would anyone choose to deal with that?

seldo 13y ago
They chose a deliberately over-simplified example in order to demonstrate the core concepts; I don't begrudge them that (nobody needs a program that prints out "Hello World!"). The audience level of this piece is confusing -- it looks like a friendly, cartoony introduction for a general audience, but it actually assumes you already know Haskell. Basically, you and I are not the intended audience.
- egonschiele 13y ago
  Right. I'm hoping to make monads easier to understand, but you need some knowledge of functional programming to build on. If I had tried catering to the complete beginner, this post would be much longer and not as focused :)
  - seldo 13y ago
    That's fair enough! Perhaps a sentence at the beginning to establish your goal would prevent comments from confused clueless people like myself.
    - egonschiele 13y ago
      Done!
- chii 13y ago
  > They chose a deliberately over-simplified example in order to demonstrate the core concepts; i wish people who are writing guides on these topics pick a non-simplified situation where using this method makes for an easier program (vs using the "traditional method"). The comparison and contrasting of a functional/monadic approach vs a procedural approach in a complex scenario might actually shed more light - at least, for some one who is familiar with the procedural approach.
  - balloot 13y ago
    I would love to see this! One of the fundamental issues I have with functional languages is every example I see is basically "See this thing that's relatively simple and uncomplicated in Ruby/PHP/C/whatever? Here's how to do that in Haskell!" And the Haskell version ends up being extremely unintuitive and complicated. Bottom line is I still don't know for which situations functional languages are a "good" tool.
    - gizmo686 13y ago
      I think the problem is that the Haskell version is actually very simple, to the person writing it. Its a classical problem of teaching, it is extremly easy to forget how something looks to new people.
    - egonschiele 13y ago
      Again, if you tell me where you're stumbling, I can fix it. I see your complaints all over this post and you haven't responded to me once.
  - nandemo 13y ago
    That approach is used at length in Real World Haskell. For example, some code for key-value lookup is shown that deals with a series of Maybe foo values, first with a cascade of guards (think a cascade of if-else's), and later with monad syntax. There are other examples. http://book.realworldhaskell.org/read/programming-with-monads.html http://book.realworldhaskell.org/read/programming-with-monad...
    - lobster_johnson 13y ago
      I enjoyed RWH much more after having learned a lot of the basics. It starts off simple, to be sure, but then quickly jumps into the deep end. For a book that's about real-world stuff it gets into a lot of unnecessary detail, too, that should have been deferred until later "advanced" chapters. I appreciated the hands-on approach to real examples, though. "Learn You A Haskell For Great Good" [1], while much less complete, is the best intro I have found so far. It's also free. [1] http://learnyouahaskell.com/ http://learnyouahaskell.com/
- balloot 13y ago
  I know a bit about Haskell and have played with it. I guess it just seems like functional languages are for those who want to solve super complicated mental exercises when doing tasks that would otherwise be easy using a traditional language. There are very few things in the world of CS/programming where I can't follow along and grok what's going on, especially when laid out in a tutorial form like this. The fact that I was totally lost when reading this is not a good sign when you're trying to get people to adopt your school of thought.
  - egonschiele 13y ago
    Post author here. I'd love to know where you stumbled!
  - tel 13y ago
    This is a pretty common idea, but it's because pure functional programming is, at first, all about getting you to significantly change your programming POV. It's a shift for anyone---in fact, the better you are at understanding C/Ruby/Python/Perl/Java/ObjC/Lua the harder a shift it is. At the end of the day, you adopt a new way of thinking that is incredibly clarifying for all programming. One simple thing is that it allows you to "see" where state, re-entry, evaluation, IO, and failure are happening in a program---things that you are blind to when you're used to languages where the answer is "always". This article isn't even meant to explain why you ought to learn Haskell. It's more like a signpost on your path to mastery, should you begin walking it.
  - chongli 13y ago
    >There are very few things in the world of CS/programming where I can't follow along and grok what's going on, especially when laid out in a tutorial form like this. That's probably because most of the tutorials you've followed have adopted an imperative style of programming. It is easy for you to follow along because it really isn't all that different from what you are accustomed to. Functional programming really is a different beast entirely. It's often said (though I remain skeptical) that it's actually easier to learn functional programming as a non-programmer than to un-learn your imperative programming tendencies. >The fact that I was totally lost when reading this is not a good sign when you're trying to get people to adopt your school of thought. I don't think that's a fair assessment. You could say the same thing about starting from functional programming and switching to imperative; some people actually do this! They find the idea of mutating a variable to be completely counter-intuitive!
- olavk 13y ago
  In other communities, new tools and abstractions are generally "sold" by explaining how they are useful for solving specific problems. Not so in the Haskell community though. The Haskell community has a longstanding tradition of using condescending language ("fmap is from the street, fmap is hip to contexts."), and deliberate childrens-book style metaphors and illustrations in tutorials. The theory seem to be that if monads haven't been adopted by mainstream developers yet, it is just because the presentations haven't been dumbed-down and kiddie-friendly enough yet. (If only they from the onset had called "monads" for "warm fuzzy things" instead, surely developers would not be so scared of them!) The strategy have not yet borne fruit, though.
chousuke 13y ago
The function is not the focus. The article presents three abstractions that allow you to apply regular functions on things to which they are not directly applicable. Maybe is usually used as an example since it's the simplest non-trivial monad (and therefore also an applicative functor). The point of eg. fmap etc. is that you can have regular Int -> Bool functions, and apply them to data with more structure than simple values. a Maybe String is not a String, but you can still transform one to uppercase by doing fmap (map toUpper) mstring. The fun part is that that exact same thing works on a list of strings, an IO String (fmap (map toUpper) getLine), a Tree of Strings, etc... It's fully generic over anything that can implement Functor; the exact behaviour is defined by the particular instance. Applicative is just an extension to the idea, where the function applied itself can have this extra structure, and when combined with an infix fmap you get to do (+) <$> Just 2 <*> Nothing <*> Just 5 -- Nothing (++) <$> getLine <*> getLine -- IO action that reads two lines and concats them To see why this works has to do with currying. Just stare at the types of fmap and <* > long enough and you should see it eventually. a Monad is yet more powerful because it allows a previous computation to affect what follows in an arbitrary manner (Applicative doesn't), allowing things like state, asynchronous execution, continuations, and countless other things. It's such an useful abstraction that Haskell provides the do syntax for using it. Edit: In languages like Java where all types are nullable, if you uppercase a String, but that String is null, your program breaks, even though the type system claims that you have a String when in reality all types are Maybes, and you are forced to always check for nulls manually or just rely on users to not give you nulls, even though it would be trivial for the compiler to check something like that statically if the language were expressive enough to allow it.
- ams6110 13y ago
  So if I understand correctly, the Maybe monad is analogous to SQL's handling of NULL. In SQL, I can invoke the UPPER function on a string, and if that string is a string I get the uppercase version, if it's a NULL I get a NULL in return. I get that, but every time I read about Monads (to the GP's point) it just seems like a very formal academic theory and I keep thinking "so what?" I have not done much with Haskell, maybe it's one of those concepts that seems more natural in practice than it does to try to read about it?
dscrd 13y ago
"functional languages" is a rather wide concept, but I would accept "Why this particular aspect of functional languages will never catch on". Many other aspects have already been assimilated by pratically everyone.
- Tycho 13y ago
  It's sort of like those bizarre outfits you see on catwalks, parts/details of which actually filter through to mainstream clothes eventually.
tikhonj 13y ago
Have you seen how much complexity Java has just for hello world!? It's truly absurd. And, as somebody who's tried teaching Java to complete beginners, I can attest that it isn't intuitive at all. There's no way this Java thing will catch on. Why would anyone choose to deal with it?
- olavk 13y ago
  Haskell and Java are not the only language in the world. The poster might prefer an OO-language without the HelloWorld-overhead as Java. Like, say, Python where hello world is literally print "Hello World" And in the case of Java, it is well known that Java is not intended or used for writing one-lines, so it is not really a relevant criticism. And even if it were, it doesn't refute any criticism of Haskell that you are able to point out unrelated shortcomings in an unrelated language.
  - tikhonj 13y ago
    My point was that it hasn't stopped Java from becoming popular--more popular than Python, even! After all, people do choose to deal with all the wanton complexity of Java. Also, the example of hello world doesn't show much about complexity. After all, in Haskell it's just: main = putStr "Hello World"
nickknw 13y ago
I would say it used a dead simple function as a device to help explain a bunch of other things.

by balloot 13y ago

seldo 13y ago

They chose a deliberately over-simplified example in order to demonstrate the core concepts; I don't begrudge them that (nobody needs a program that prints out "Hello World!"). The audience level of this piece is confusing -- it looks like a friendly, cartoony introduction for a general audience, but it actually assumes you already know Haskell. Basically, you and I are not the intended audience.

egonschiele 13y ago
Right. I'm hoping to make monads easier to understand, but you need some knowledge of functional programming to build on. If I had tried catering to the complete beginner, this post would be much longer and not as focused :)
- seldo 13y ago
  That's fair enough! Perhaps a sentence at the beginning to establish your goal would prevent comments from confused clueless people like myself.
  - egonschiele 13y ago
    Done!
chii 13y ago
> They chose a deliberately over-simplified example in order to demonstrate the core concepts; i wish people who are writing guides on these topics pick a non-simplified situation where using this method makes for an easier program (vs using the "traditional method"). The comparison and contrasting of a functional/monadic approach vs a procedural approach in a complex scenario might actually shed more light - at least, for some one who is familiar with the procedural approach.
- balloot 13y ago
  I would love to see this! One of the fundamental issues I have with functional languages is every example I see is basically "See this thing that's relatively simple and uncomplicated in Ruby/PHP/C/whatever? Here's how to do that in Haskell!" And the Haskell version ends up being extremely unintuitive and complicated. Bottom line is I still don't know for which situations functional languages are a "good" tool.
  - gizmo686 13y ago
    I think the problem is that the Haskell version is actually very simple, to the person writing it. Its a classical problem of teaching, it is extremly easy to forget how something looks to new people.
  - egonschiele 13y ago
    Again, if you tell me where you're stumbling, I can fix it. I see your complaints all over this post and you haven't responded to me once.
- nandemo 13y ago
  That approach is used at length in Real World Haskell. For example, some code for key-value lookup is shown that deals with a series of Maybe foo values, first with a cascade of guards (think a cascade of if-else's), and later with monad syntax. There are other examples. http://book.realworldhaskell.org/read/programming-with-monads.html http://book.realworldhaskell.org/read/programming-with-monad...
  - lobster_johnson 13y ago
    I enjoyed RWH much more after having learned a lot of the basics. It starts off simple, to be sure, but then quickly jumps into the deep end. For a book that's about real-world stuff it gets into a lot of unnecessary detail, too, that should have been deferred until later "advanced" chapters. I appreciated the hands-on approach to real examples, though. "Learn You A Haskell For Great Good" [1], while much less complete, is the best intro I have found so far. It's also free. [1] http://learnyouahaskell.com/ http://learnyouahaskell.com/
balloot 13y ago
I know a bit about Haskell and have played with it. I guess it just seems like functional languages are for those who want to solve super complicated mental exercises when doing tasks that would otherwise be easy using a traditional language. There are very few things in the world of CS/programming where I can't follow along and grok what's going on, especially when laid out in a tutorial form like this. The fact that I was totally lost when reading this is not a good sign when you're trying to get people to adopt your school of thought.
- egonschiele 13y ago
  Post author here. I'd love to know where you stumbled!
- tel 13y ago
  This is a pretty common idea, but it's because pure functional programming is, at first, all about getting you to significantly change your programming POV. It's a shift for anyone---in fact, the better you are at understanding C/Ruby/Python/Perl/Java/ObjC/Lua the harder a shift it is. At the end of the day, you adopt a new way of thinking that is incredibly clarifying for all programming. One simple thing is that it allows you to "see" where state, re-entry, evaluation, IO, and failure are happening in a program---things that you are blind to when you're used to languages where the answer is "always". This article isn't even meant to explain why you ought to learn Haskell. It's more like a signpost on your path to mastery, should you begin walking it.
- chongli 13y ago
  >There are very few things in the world of CS/programming where I can't follow along and grok what's going on, especially when laid out in a tutorial form like this. That's probably because most of the tutorials you've followed have adopted an imperative style of programming. It is easy for you to follow along because it really isn't all that different from what you are accustomed to. Functional programming really is a different beast entirely. It's often said (though I remain skeptical) that it's actually easier to learn functional programming as a non-programmer than to un-learn your imperative programming tendencies. >The fact that I was totally lost when reading this is not a good sign when you're trying to get people to adopt your school of thought. I don't think that's a fair assessment. You could say the same thing about starting from functional programming and switching to imperative; some people actually do this! They find the idea of mutating a variable to be completely counter-intuitive!
olavk 13y ago
In other communities, new tools and abstractions are generally "sold" by explaining how they are useful for solving specific problems. Not so in the Haskell community though. The Haskell community has a longstanding tradition of using condescending language ("fmap is from the street, fmap is hip to contexts."), and deliberate childrens-book style metaphors and illustrations in tutorials. The theory seem to be that if monads haven't been adopted by mainstream developers yet, it is just because the presentations haven't been dumbed-down and kiddie-friendly enough yet. (If only they from the onset had called "monads" for "warm fuzzy things" instead, surely developers would not be so scared of them!) The strategy have not yet borne fruit, though.

chousuke 13y ago

The function is not the focus. The article presents three abstractions that allow you to apply regular functions on things to which they are not directly applicable. Maybe is usually used as an example since it's the simplest non-trivial monad (and therefore also an applicative functor). The point of eg. fmap etc. is that you can have regular Int -> Bool functions, and apply them to data with more structure than simple values. a Maybe String is not a String, but you can still transform one to uppercase by doing fmap (map toUpper) mstring. The fun part is that that exact same thing works on a list of strings, an IO String (fmap (map toUpper) getLine), a Tree of Strings, etc... It's fully generic over anything that can implement Functor; the exact behaviour is defined by the particular instance. Applicative is just an extension to the idea, where the function applied itself can have this extra structure, and when combined with an infix fmap you get to do (+) <$> Just 2 <*> Nothing <*> Just 5 -- Nothing (++) <$> getLine <*> getLine -- IO action that reads two lines and concats them To see why this works has to do with currying. Just stare at the types of fmap and <* > long enough and you should see it eventually. a Monad is yet more powerful because it allows a previous computation to affect what follows in an arbitrary manner (Applicative doesn't), allowing things like state, asynchronous execution, continuations, and countless other things. It's such an useful abstraction that Haskell provides the do syntax for using it. Edit: In languages like Java where all types are nullable, if you uppercase a String, but that String is null, your program breaks, even though the type system claims that you have a String when in reality all types are Maybes, and you are forced to always check for nulls manually or just rely on users to not give you nulls, even though it would be trivial for the compiler to check something like that statically if the language were expressive enough to allow it.

ams6110 13y ago
So if I understand correctly, the Maybe monad is analogous to SQL's handling of NULL. In SQL, I can invoke the UPPER function on a string, and if that string is a string I get the uppercase version, if it's a NULL I get a NULL in return. I get that, but every time I read about Monads (to the GP's point) it just seems like a very formal academic theory and I keep thinking "so what?" I have not done much with Haskell, maybe it's one of those concepts that seems more natural in practice than it does to try to read about it?

dscrd 13y ago

"functional languages" is a rather wide concept, but I would accept "Why this particular aspect of functional languages will never catch on". Many other aspects have already been assimilated by pratically everyone.

Tycho 13y ago
It's sort of like those bizarre outfits you see on catwalks, parts/details of which actually filter through to mainstream clothes eventually.

tikhonj 13y ago

Have you seen how much complexity Java has just for hello world!? It's truly absurd. And, as somebody who's tried teaching Java to complete beginners, I can attest that it isn't intuitive at all. There's no way this Java thing will catch on. Why would anyone choose to deal with it?

olavk 13y ago
Haskell and Java are not the only language in the world. The poster might prefer an OO-language without the HelloWorld-overhead as Java. Like, say, Python where hello world is literally print "Hello World" And in the case of Java, it is well known that Java is not intended or used for writing one-lines, so it is not really a relevant criticism. And even if it were, it doesn't refute any criticism of Haskell that you are able to point out unrelated shortcomings in an unrelated language.
- tikhonj 13y ago
  My point was that it hasn't stopped Java from becoming popular--more popular than Python, even! After all, people do choose to deal with all the wanton complexity of Java. Also, the example of hello world doesn't show much about complexity. After all, in Haskell it's just: main = putStr "Hello World"

nickknw 13y ago

I would say it used a dead simple function as a device to help explain a bunch of other things.