As a student primarily experienced with imperative and object-oriented languages, my first few hours learning Haskell at university were a bit of a struggle. There's a real shift involved in terms of how you approach problem solving and concepts like pure functions, side effects, currying, higher order functions etc. were very new to me and took me a while to properly grasp and begin using.

I did eventually get the hang of it, and now happily write production code in Scala that uses a lot of these techniques. I think it can result in incredibly elegant code.

But I'm curious: is there is a way to make the initial struggle easier? I've seen some suggestions that students should start with a functional language - but I don't think it's reasonable to assume all of the students won't have prior knowledge of working in an imperative language.

  • $\begingroup$ IMHO, the struggle exists because students start from an imperative PL. This order is incorrect from a theoretical viewpoint: imperative programming is a special case of functional programming, as you know from learning Haskell. This is the reason for the suggestion that “students should start with a functional language”. $\endgroup$ – beroal Jun 29 '17 at 14:07
  • $\begingroup$ The paradigm of functional programming, as it is commonly understood, is a bunch of concepts. You mentioned some of them. For example, sum types belong there too. Every concept require its own approach. Considering them together as one monolithic thing is not useful. The “paradigm” concept is doing a disservice here. $\endgroup$ – beroal Jun 29 '17 at 14:07
  • 1
    $\begingroup$ After seeing students struggle with ideas as simple as variables, assignment and indirection, I have only two thoughts to offer: 1) every kind of abstract learning is a struggle 2) if you want someone to excel at something, start them as early as possible. Great skaters start as soon as they can walk, great pianists as soon as they can reach the keyboard. $\endgroup$ – user737 Jul 1 '17 at 14:43

Any true paradigm shift requires literally re-wiring the brain. Thinking functionally is not the same as thinking procedurally (for example). The neural pathways of the brain need to be connected appropriately for the new paradigm to become natural. When you were a kid you were, if typical, used to walking and running. Then you probably got a bicycle (or a skateboard if you are young enough). You tried, you fell down, you tried again. Your brain got used to the subtle balancing required. Swimming - same deal. Differentiation - same deal. Haskell - same deal.

As an instructor, the above implies that you should provide guided practice at the beginning - a skateboard park for the mind. If your students solve a lot of simple problems (not syntactical, but logical) they will skin their knees on these but if they are well chosen will get the skills. In scheme, reversing a list with only head and tail is simple enough. Doing it in linear time takes a bit more skill, but the technique is both cool and satisfying. Writing the code wires the brain. And, like riding a bicycle, it is hard to un-learn it once you get it, since the brain is now different.

So, make it possible for the students to fall a lot, but to get up without getting discouraged.

To add a bit of specificity to this. Assuming you know the paradigm well yourself, what are its 100 most important techniques? Can you come up with a 10-30 minute exercise for each of them? Try to have each exercise focus on just one thing (mostly anyway). These are your Etudes. Can you come up with 10 exercises for each of the 100 techniques, even if they vary only slightly?

Acknowledgement: At SIGCSE 2004, Owen Astrachan (of Duke) convinced Microsoft Research, through Jane Prey, to give every attendee the book The Art of Changing the Brain by James E Zull.

  • $\begingroup$ Reminds me of the Star Trek episode quote: "Brain and brain! What is brain!?" $\endgroup$ – user737 Jul 1 '17 at 14:33

Your Answer

