Learning Haskell for fun
December 01, 2022
My journey will include two books, Get Programming with Haskell, (Get Haskell) a Manning publication by Will Kurt that’s been sitting on my bookshelf for a little over a year. Also, the site (and book), Learn you a Better Haskell, (Learn You) (https://learnyouahaskell.com/). So far I have switched back and forth between both books as they complement each other. Kurt’s book takes the approach to introducing a new concept in each “Lesson” and at the end includes exercises that the reader can try and find answers to in the Appendix. It has lessons grouped into larger sections that cover a theme (FP concepts, Types). Learn You is a slightly more irreverent style that doesn’t provide reader exercises but has the benefit of being free online to read. For the most part, the books introduce the concepts in the same order, with the notable difference that Will Kurt’s book introduces Higher-order functions in the first section of the book as part of a Functional programming introduction/overview, while Learn You saves HOF’s as a later topic. Learn You introduces Types much earlier, whereas Kurt’s book saves those for a whole section. Both books are excellent so far. I’ve read Section 1 of Kurt’s book (Functions, Lists, Lambdas, Recursion, Higher-Order Functions) and the first 6 chapters of Learn You (Functions, Lists, Types, and Typeclasses, Syntax [guards, pattern matching], Recursion, HOF’s). For some of the concepts, it’s helped to read two different authors explain Haskell, as the code tends to be terse, yet dense. I’m not quite sure I’m comfortable with the differences in “let”, “where” and pattern matching yet. I’m looking to December when I can explore these concepts with the Advent of Code.
Probably one of the biggest mental shifts is the idea of managing state in functional programming. Most developers are likely used to updating objects, values, and arrays by adding, deleting, or otherwise manipulating different variables throughout their code. Functional programming encourages the concept of immutability. That is, if a function or block of code accepts a parameter or references a variable, it doesn’t change that variable to some other value. That’s considered a side effect of the function and is not allowed. The goal of each function is to accept parameters and return a value, and if the function is called 20 times with the same parameters, 20 times it should return the same value, regardless of the time of day/month/year, the values of any other variables currently in scope, or the machine the code is running on. Haskell, and functional programming in general, believes in building upon small functions, chaining them together, and by structuring your code in simple functions, you have confidence in the code working every time. Get Haskell has a ‘capstone’ project where Kurt tries to re-create OO concepts that did not quite land for me. My sense was that the project was to explore how a typical OO developer might start thinking in Haskell terms, but the example involved creating new robots as they took damage and the number of robot states created over 3 rounds did not seem like a good display of what Haskell can do?
I hope to explore some more detailed parts of Haskell as I go. Partial Application, Pattern Matching, and Types deserve more space than I want to devote to one singular blog post. I have dipped my developer toes into FP over the years, but never fully committed. Learning Haskell is giving me a new sense of understanding FP and the benefits it could have on my design and structure of projects.
Written by Allen Reinmeyer who lives and works in Perrysburg, OH You should follow him on Twitter