Recently, I attended Manuel Chakravarty’s YOW! night talk titled Demystifying Functional Programming, which inspired me to write this post.
From my work, I gained some intuition that trying to teach FP by explaining the theory first didn’t work well. In hindsight, this seems almost obvious. A lot of us were taught math this way and sadly it has left many of us misunderstanding math or even despising it, even though it might be very useful in their chosen field1.
What worked better was to show how elegantly FP solves many problems we were focusing on; one that required a use of parsers or another for which we were using reactive programming to process and analyse large quantities of data in real-time. These were some of the concepts I’ve learned in Haskell and was able to apply in Scala. They were harder to implement in the imperative way, which only complected them and that also made them harder to understand.
My intuition really aligned with the content of Manuel’s talk. With his long-time experience and commitment to working with and teaching Haskell, Manuel discussed what we can do to advance FP from the stage of innovators and early adopters to early majority2, which he summarised as:
Another seasoned Haskeller Gabriel Gonzalez has written some great advice for Haskell beginners3, in which he recommends to:
If you gave Haskell a try, but still find it too intimidating, I would recommend you having a look at Elm. Elm (which itself is written in Haskell) is a very small language in terms of the size of its grammar, which makes it a perfect fit for beginners. Not only is it very good at all the points above, it can also compete with other front-end frameworks like React. The whole notion of languages being general-purpose can be quite misleading4, Elm is intentionally not a general-purpose language5 and it serves its intended purpose very well. You don’t have to take my word for it though, instead, you can watch a talk by Richard Feldman, who’s been using both React and Elm side-by-side in production for over a year.
Cool, you got me, but…
Of course, not everyone learns the same way. As a general recommendation I would say:
Try not to learn too many things at once, keep things simple. This is especially important if you come to FP with prior experience from imperative languages, which doesn’t translate well into FP concepts. You might have heard functional programmers say that when you start, you will have to unlearn things, and this is what they’re referring to. Honestly, you will need patience, because everything might seem slow at first. That’s okay, don’t give up and keep at it!
Try to find someone who already has experience with FP and ask them for help with writing something simple. When you see FP applied to solving a real problem, you are very likely to learn faster. There are people who say they were able to pick up Elm this way within a week, but don’t set your expectations too high. Once again, everyone’s learning path is different. Look for FP meetups in your area, join Elm on Slack, read the comprehensive Elm Guide. Don’t start trying to write a full-blown single page app, there are ways to gradually introduce Elm at work today. Or you can just play around directly from your browser, you don’t even have to install anything.
Lastly, don’t be afraid to make mistakes, for it’s an important part of any learning process.