Why it’s so Hard for Imperative Programmers to Learn Functional Languages

I’m not currently using any functional languages like Haskell and Lisp, but I’m certainly comfortable with them. I’m certainly no Haskell guru, but I’m good enough to use higher-order functions, ADTs, monads, etc. While I have a good grasp of functional programming concepts now, I had to travel a long, hard road to get to this point.

Picture if you will a programmer with a C-family background discovering Haskell for the first time. He’s heard some smart people talk about how cool it is, and it says right there on haskell.org that it will substantially boost your productivity, so he momentarily puts down his Java Enterprise Web Framework With a Really Long Name and starts reading a Haskell tutorial.

At first, everything goes well. He’s impressed by the fact that you don’t have to constantly compile code to see the effects of your program. But after using the REPL as a calculator for a few minutes, he decides to check out how you write Hello World. This is where things start going downhill.

He notices that the chapter on I/O is tucked away in the Advanced section. Curiously, he flips to it and discovers, not an explanation of console and file I/O, but a disscussion of type classes, monads, and the like. He wonders if everything will make more sense if he just visits the appropriate chapters, but no luck; Haskell looks like one big incomprehensible mess. Our imperative programmer goes back to his Java Enterprise Framework, and that is the end of that.

It’s very difficult for a programmer used to imperative programming to find a good Haskell tutorial, or a good tutorial on any other functional language for that matter. It’s not that they explain Haskell badly; many of them explain it rather well. It’s just that they explain the wrong parts of Haskell. Procedural programmers are more often interested in how to do I/O and create GUIs rather than in how to use Parsec or write monads.

This is one of the major barriers to adoption of the more esoteric languages; lack of learning material for “normal people”. To rectify this, I thought about how I would write a Haskell tutorial.

I figured I would start off with a discussion about how to use the REPL to develop simple functions, and to test programs. From there, we would talk about how functions are side-effect free. We might take a detour into recursion, and then go on to topics such as monads and type classes. It would just be a Really Good Tutorial.

Then I realized something: in this great tutorial of mine, there were no sections on how to do I/O. There wasn’t even a Hello World program. Therein lies the problem.

The only people who can write a Haskell tutorial are the people who know Haskell. Ironically, someone who knows Haskell won’t be able to write a tutorial for the average programmer. They’ll focus too much on the features that make Haskell cool, rather than how to do practical things with it; which is just what the average programmer wants. Haskell gurus have spent so much time in their theoretical wonderlands, they’ve forgotten what it’s like to be an outsider.

We really need a Haskell, or Lisp, or ML tutorial aimed at the rest of the world, not just at functional gurus. Although I’m certainly not going to write it; I’ve got my own projects to worry about.

About these ads

35 Responses to “Why it’s so Hard for Imperative Programmers to Learn Functional Languages”

  1. damien morton Says:

    Trouble with Haskell is that you pretty much have to leave everything you ever learned behind.

    Model-View-Controler? not a relevant pattern where referential transparency is concerned. What pattern is appropriate for writing GUI apps in Haskell? Who knows! (probably will involve Monads though).

    Lots of good ideas in Haskell. A practical language for doing work? Not so much, unless you are a language theoretician.

  2. Drake Says:

    This is why, after learning LISP, I decided it’s BS. While it does allow me to do some cool things, they are not the types of things I want to do.

  3. Cale Gibbard Says:

    The other thing is that the REPL gives you a user interface. So you really can write interesting and useful software without worrying at all about I/O until the very end, if at all. Of course, most imperative programmers are not very used to that idea, and they want to see I/O right away, before it will permit the clearest possible explanation.

    It’s a bit of a tough situation, but I think I’d take the approach of just trying to explain why I/O can wait a while. :)

  4. Academician Says:

    For Lisp at least, there is Peter Seibel’s Practical Common Lisp. It’s a great practical introduction to Lisp programming. Unfortunately, a similar attempt with OCaml apparently didn’t go so well.

    It would be nice if there was a tutorial for Haskell that took its cues from Peter Seibel. He starts with practical applications right out of the gate.

  5. Alex Says:

    The tutorial (or better, the book) could be in the form of a dialog between an eager C programmer and a Haskell sage.

    This would quash the C guy’s repulsion of having to listen to what he might feel are pompous one-sided proclamations.

    Peppered along the way would be remarks on how Haskell does away with C’s weaknesses and minefields, such as, e.g. inintended side effects.

  6. Tracy R Reed Says:

    I really want to see a Haskell cookbook for system administrators. System administrators do IO. All day long. Piping, processing, grepping, sedding, etc. I just wrote a logfile analysis program (Yes, another. In python this time. I didn’t like swatch/logcheck/logwatch) and I would like to know how to do it in Haskell. But as I am only beginning my journey into functional programming I am probably a couple years away from being able to write my 300 line python program as a Haskell program. I but I am very curious to see how many lines it comes out as. :)

  7. EntropyFails Says:

    In response to Drake, you never learned Lisp. Sorry. You may THINK that you did, but you have much more to learn about that language.

    As for Haskell tutorials, I agree that some more “basic guides” may be nice. But I like to call Haskell “Programming for Smart People.” Smart people, by definition, don’t need simple tutorials. *grin*

  8. Reinier Zwitserloot Says:

    Just a sidenote to your point (which I entirely agree with): If someone is ‘impressed’ that haskell doesn’t ‘require’ compilation everytime you make a change, the programmer being impressed is one of the following:

    Entirely new to programming, OR
    an idiot, OR
    by now, 60 years old at least.

    There are hundreds of environments, IDEs, and smart editors that allow you to test drive languages that have a compile step; from Eclipse, to IDEA, to NetBeans, to beanshell, and that’s just for java. Just enter a line and see what happends, or, make a change to your code, and the running app instantly starts using the new code (it’s called a debugger!), no need to restart anything.

    Perhaps part of the problem of these tutorials is that the ‘cool’ things they describe aren’t actually stunningly new. It’s more about the hegemony and tooling (in haskell’s case, that is), basically the beauty, of how haskell ticks. That’s very VERY difficult to grasp if you’re learning the language, especially if you’re trying to get your hands dirty and write some simple programs, unless you get very excited about modelling mathemetical concepts a lot. As a rule people don’t except if you are a mathematician, or a theoretical computer scientist.

    I theorize this explains why Haskell, LISP, and many other functional languages are run and used by elitists (not neccessarily pompous elitists, that’s more language dependent): The majority of the people that use them are experts at computer science in general, which allows them to appreciate the idea and get through the learning phase.

    Unfortunately, this sometimes gets turned on its head: Because such languages have a proportionally much larger ratio of experts to the mere mortal users, the theory is made that these languages are somehow ‘better’. Programming languages, as a problem domain, is a bit too large to start throwing such terms as ‘better’ about… and it certainly doesn’t help the whole elitist presumption.

  9. danb Says:

    > The only people who can write a Haskell tutorial are the people
    > who know Haskell. Ironically, someone who knows Haskell
    > won’t be able to write a tutorial for the average programmer.

    This is why I wrote my monad pre-tutorial as soon as I finished my first program, after using the language for less than a month.
    (shameless plug: http://www.prairienet.org/~dsb/monads.htm)

    Also, Hal Daume does a decent job in YAHT. He starts with the IO monad at a superficial level, and doesn’t even mention that it’s a monad until later.

  10. casey Says:

    @Tracy: I would like to have a copy of that cookbook. One of the first things I did in Haskell was a recursive descent directory crawler. I ended up borrowing bits from another implementation, the types and IO monad drove me crazy until I ‘got it’. I would love to see new flexible alternatives to the old-school find, grep, etc.

    Its kind of funny, that Microsoft’s experimental command shell for .NET was called Monad :)

    You probably can’t have it both ways though. You either have to oversimplify a language to treat evaluations and actions as the same thing, and deal with all the implications of that leaky abstration, or force the user to take explicit responsibility for the state-changing actions.

    The tutorials need to focus on how and especially why actions get isolated.

  11. JimDesu Says:

    That’s exactly why I stopped with Haskell. It makes fantastically difficult things pretty easy, at the cost of making simple things fantastically difficult (GUIs in my case).

    They could go a long way to fixing the issue if they’d condescend to providing decent standardized record support.

  12. Tom Says:

    you know, Haskell really isn’t that great. Well I don’t really know because I’ve never read a decent article on it. I’m not saying that there aren’t any but there are so many posted on reddit and most of them are so innane. I read one about defining numbers and in the end the author tried to solve for infinity and it just kept printing. Really now, in ANY language if you try to define infinity recursively you are going to get a compile time error or a non halting result. Do imperative programmers post about their new while(true) loop technology and smile smuggly when it works?

    The reason that functional languages fail is that they are single metaphor: everything is a math-like function to be evaluated. No single metaphor language will ever be popular, even if it is the best metaphor.

    The original article does bring up an excellent point: I/O. One of the replies shows why there is no progress and never will be:

    “So you really can write interesting and useful software without worrying at all about I/O until the very end, if at all.”

    nope. That is too high risk a strategy. You can’t just code up your program and then see if it works. You need immediate feedback. I am writing a compiler for a language of my own design. First I wrote the tokenizer. In main I called the tokenize function and then send to output to a file for review. Then the parser, and I wrote out the parse tree. Now I am doing semantic analysis and I found some free software for rendering directed graphs (graphviz from AT&T). I am getting feedback on how I am doing which motivates me greatly. When my final program is written out in binary it will not be the result of some glorious math festival but the final product in an iterative process. So I/O is central to my programming strategy. It allows me to peek into the assembly line.

    yeah also I found this quote quite true: “While it does allow me to do some cool things, they are not the types of things I want to do.”

    why the obsession with folding lists and things? I have never wanted to do that. I’ve wanted to do things that are pretty similar but your generic map and fold functions rarely do exactly the right thing.

  13. Mike Says:

    Uh, no I/O doesn’t preclude you from iterative development. I/O or not, what you’re talking about is a job for the REPL.

  14. Alex Says:

    What’s so hard to figure?

    When some paying jobs using Haskell show up in the mainstream job market all us imperative programmers will take it more seriously and put the time in to learn it. Until functional languages work their way out of the academy they are just one more curiosity in a profession filled with too many things to learn, career ending rat holes, and flavors of the day.

    Hey Prolog may catch on – any day now!

  15. scanlyze Says:

    Why it’s so Hard for Imperative Programmers to Learn Funtional Languages… because they cannot spell “functional”? :)

  16. Doug L. Says:

    Re “funtional” => clearly, Jimmy is simply trying to eradicate the use of “C” wherever he can.

  17. Need an Editor Says:

    the line:

    [ It’s not that they don’t explain Haskell badly; many of them explain it rather well. ]

    doesn’t make sense. should probably read:

    [ It’s not that they explain Haskell badly; many of them explain it rather well. ]

    also, the tagline of your blog needs some work:

    [ People think I’m work when I write in Notepad rather than MS Word… ]

    maybe try:

    [People think I’m workING when I write in Notepad rather than MS Word…] or
    [People think I’m AT work when I write in Notepad rather than MS Word…] or
    [People think I’m AWESOME when I write in Notepad rather than MS Word…]

    not trying to be an ass, i’m just a compulsive backseat editor.. :\

  18. Jimmy Says:

    >[ It’s not that they don’t explain Haskell badly; many of them explain it >rather well. ]
    >
    >doesn’t make sense. should probably read:
    >
    >[ It’s not that they explain Haskell badly; many of them explain it rather >well. ]

    Fixed.

    >Why it’s so Hard for Imperative Programmers to Learn Funtional >Languages… because they cannot spell “functional”?

    Fixed. I need to put these entries through a spell checker :(

    >also, the tagline of your blog needs some work:
    >
    >[ People think I’m work when I write in Notepad rather than MS Word… ]

    This originated as a mistake of mine on IRC; I originally intended for the sentence to read “People think I’m weird when I write in Notepad rather than MS Word”. When someone informed me that I had accidentally come up with the best tagline ever, I went with it ;)

  19. IO doesn’t matter: telling C programmers the key to the Haskell weltanschauung « Data.Syntaxfree Says:

    […] 15, 2007 at 12:21 pm · Filed under Uncategorized Quoth qftblog: At first, everything goes well. He’s impressed by the fact that you don’t have to constantly […]

  20. Superpig Says:

    Tom: not all functional languages are purely functional. Take a language like Ocaml, which has references and exceptions – impure functions, ones that can have side effects.

    Also, why bother writing more (potentially buggy) code to output your lexer’s token list to a file when you could just inspect the tokens that it is generating in the debugger?

  21. Peter Balogh Says:

    You know, Peter Seibel’s book is indeed awesomely apt, and I look forward to understanding enough of Lisp’s rudiments to grok it (am making my way first through gentlelispbook.pdf), but here’s the thing: I love games. Computer games are why I program (though not, sigh, *what* I generally program), and the story of Naughty Dog is largely why I’m determined to learn Lisp in the first place.

    Are there good tutorials on graphics/game programming in Lisp? OpenGL? So far my casual Googling hasn’t exactly set my heart on fire….

  22. Jimmy Says:

    >Are there any good tutorials on graphics/game programming in Lisp? OpenGL?

    I haven’t found any; I haven’t even found a Lisp OpenGL binding (that’s stable and isn’t a total pain to install).

    If you want to do a GUI in Lisp without buying a commercial compiler, your best bet is Ltk.

  23. Jimmy Says:

    Yep: CL-SDL.

    However, it seems to suffer from the same problems that all other Lisp libraries do: lack of documentation, and general incompleteness. A Lisp newbie who saw “CL-SDL specific information coming soon!” as the only sentence under the Documentation section wouldn’t be very comforted.

  24. anthonyf Says:

    Jimmy, try lispbuilder-sdl. The working examples are enough to get you started.

    http://lispbuilder.sourceforge.net/

  25. Jimmy Says:

    Thanks a lot for that, I’m going to look through all those libraries when I get the chance.

  26. BenD Says:

    I think functional programming is where languages are headed but the I/O is a huge stumbling block as you say. I’m only just starting to look into it but Scala looks to be a very promising OO/FP language running on the VM that could be a fantastic start or stepping stone.

  27. Kaveh Shahbazian Says:

    Take a look at F#. It is a dialect of ocaml which runs upon .NET framework. So it is a multi-paradigm language (as ocaml is). I think moving from imperative to functional can happen with such languages. I do not like none-open-source technologies but to be fair F# is somehow cool. Give it a try.

  28. Jimmy Says:

    I tried out F#, but I didn’t like it. Code examples are minimal, and those that do exist use the object-oriented aspects of F#; which are completely different from the ones in OCaml, and have no documentation.

    Maybe things will pick up when APress publishes their F# book.

  29. Gnoletcom Says:

    Please join for discussions on topics about The Virtual Reality.
    Technology development of The Virtual Reality and its perspectives.
    Gnolet.com

  30. erunselew Says:

    Two new studies show why some people are more attractive for members of the opposite sex than others.

    The University of Florida, Florida State University found that physically attractive people almost instantly attract the attention of the interlocutor, sobesednitsy with them, literally, it is difficult to make eye. This conclusion was reached by a series of psychological experiments, which were determined by the people who believe in sending the first seconds after the acquaintance. Here, a curious feature: single, unmarried experimental preferred to look at the guys, beauty opposite sex, and family, people most often by representatives of their sex.

    The authors believe that this feature developed a behavior as a result of the evolution: a man trying to find a decent pair to acquire offspring. If this is resolved, he wondered potential rivals. Detailed information about this magazine will be published Journal of Personality and Social Psychology.

    In turn, a joint study of the Rockefeller University, Rockefeller University and Duke University, Duke University in North Carolina revealed that women are perceived differently by men smell. During experiments studied the perception of women one of the ingredients of male pheromone-androstenona smell, which is contained in urine or sweat.

    The results were startling: women are part of this repugnant odor, and the other part is very attractive, resembling the smell of vanilla, and the third group have not felt any smell. The authors argue that the reason is that the differences in the receptor responsible for the olfactory system, from different people are different.

    It has long been proven that mammals (including human) odor is one way of attracting the attention of representatives of the opposite sex. A detailed article about the journal Nature will publish.

  31. $anchor$basketball Betting,final Four,final Four Betting,final Four Gambling,final Four Sports Book,final Four Sportsbook,march Madness,march Madness Betting,march Madness Gambling,march Madness Sports Book,march Madness Sportsbook,ncaa,ncaa Betting,ncaa Says:

    $anchor$basketball Betting,final Four,final Four Betting,final Four Gambling,final Four Sports Book,final Four Sportsbook,march Madness,march Madness Betting,march Madness Gambling,march Madness Sports Book,march Madness Sportsbook,ncaa,ncaa Betting,…

    $anchor$basketball Betting,final Four,final Four Betting,final Four Gambling,final Four Sports Book,final Four Sportsbook,march Madness,march Madness Betting,march Madness Gambling,march Madness Sports Book,march Madness Sportsbook,ncaa,ncaa Betting,nc…

  32. java programming lesson Says:

    everything about java…

    […]Why it’s so Hard for Imperative Programmers to Learn Functional Languages « Quoted For Truth[…]…

  33. malaysia taman negara Says:

    malaysia taman negara…

    […]Why it’s so Hard for Imperative Programmers to Learn Functional Languages « Quoted For Truth[…]…

  34. this site Says:

    It’s perfect time to make some plans for the future and it is time to be happy. I’ve read this
    post and if I could I desire to suggest you few interesting things or suggestions.
    Maybe you could write next articles referring to this article.
    I wish to read more things about it!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Follow

Get every new post delivered to your Inbox.

%d bloggers like this: