Learning Haskell

7 minute read Published:

Or rather, learning how to learn Haskell

I recently quit my job. I wanted a break from what I was doing, and wanted some time to expand my skillset in my downtime. I have wanted to learn Haskell for around 6 months, and even after having bought the Haskell Book and having read the first 8 or 9 chapters during those 6 months, I wasn’t making much progress, as it was scattered reading. Not doing the chapter exercises meant that information wasn’t going in and sticking as much as it would have had I done them. Not to mention, the lack of exercise completion meant less practice in the Haskell way of thinking meant that every subsequent chapter I read was more difficult as that lack meant unfamiliarity with the concepts. So I figured I would attempt to start over during my break, and this time, complete the chapter exercises as I go.

Reading a book cover to cover while also doing all of the exercises seems to be quite slow going. While I am making good progress on wrapping my head around this new way of thinking, time is obviously of the essence (I would ideally like to learn enough to get a job programming in Haskell, though I know they are scarce, so this is an unlikely outcome - nice to aim for something though). Having only just recently overtook my previous attempt at the book, but with exercises this time, it has been a mixed experience.

On one hand, stopping and going through every single chapter exercise (and some exercises in the chapters) is just as frustrating as it is helpful; there have been occasions where I’m stuck on how to solve or understand a problem for a whole day. This has happened a few times, and while I’m stuck in this trough, it feels like a waste of valuable time, like I should already know this, as I know the conceptes of these things individually but when combined my head explodes and I have to pick up the pieces and put them back together before I can continue. An example of this was the first time I had to wrap my head around the currying of functions syntax (eg func :: (a -> b) -> c - those brackets did a number on me!). It annoyed me that I couldn’t understand it to the point that I stayed up all night until I could. Once I did though, I reached a peak, and unlocked the rest of the book, and allowed myself to continue. That seems stupidly obvious now, and is one of those things that when you learn it, you will never unlearn or forget it; it’s in there for good. Now, I’m not sure if that’s because of the time I spent trying to understand it, or if it was that simple to begin with.

On the other hand, I can certainly feel the benefit of going through the work. In my first attempt of reading, if I didn’t understand something that has already been explained to me I’d shrug it off as it not being explained enough for me to take it in, and that I’ll either come back to it later, or I’ll get more exposure to it down the road that will be enough to give me the understanding that I currently lack. Completing the exercises gives confidence, whether you completed them successfully or not, because you now know with certainty what you understand and are capable of, and what you don’t, and aren’t. This is invaluable stuff, because it’s not often that you know what you don’t know.

Writing anything more than a “Hello world” type app is seemingly quite impossible until you understand most of the concepts in the language. At least to me - I tried breifly during my reading. In fact, the book mentions this at the beginning of the “Building Projects” chapter; it seems like it’s a common occurence for beginners. I’m not just learning Haskell so that I can get a job writing it though, I have project ideas that I would like to try out in Haskell, and although I could start them right now in another language, for better or worse I desperately don’t want to do that because I don’t want to be a generalist anymore. This basically means that it’s not until you get over the steep learning curve that you can start to use your knowledge effectively. I was about to liken it to the learning curve of vim, except that with vim, you can immediately start to utilse what you’ve just learnt - I know all this stuff about Haskell but I still need to know more before I can produce anything at all with it - let alone be productive with it. Given that I can’t be out of work forever, I have to find the optimal balance of learning speed and confidence. This leads me to the conclusion that I have to adjust my process somewhat so that I get over the curve in sufficient time that I have something meaningful enough to show for my time out of work. It’s no good being 100% confident in the ~30% of Haskell that I know - that won’t be enough to land me a job.

One other point to note in my experience so far is that, when I did try to skip ahead to just having a go at building an app with Haskell, did I give it enough effort? I basically wanted to make a server serving an API of data backed by Sqlite. So after a bit of research of not knowing much about the differences of libraries in an unfamiliar language, I landed on trying to connect the two libraries I had decided on together (Servant and sqlite-simple). Looking at their respective example apps I quickly choked on the operators I hadn’t encountered yet. I didn’t Hoogle them, didn’t Google them, I just quit. The second time around, I remembered my first attempt, and decided to Google for a ready made solution to my previous issue, so I could avoid the same (arguable) rabbit hole and attempt solving the problem on at least a business-logic level - I found the example-servant-persistent which brought me a step closer, but still, extending the API to meet my needs is still elusive, and I don’t feel that I would learn anything by brute forcing it into shape without more prior knowledge. I think my attempts here have been pretty poor. I am quite possibly taking too much of an academic approach (textbook), but fear of lack of progress is stopping me to attempt ‘learning by doing’ for too long. I mean, is it a valid achievement to have moulded a template to my own needs without really understanding what’s going on under the hood? I’m genuinely asking. I have read reports about people picking Haskell up after quite short periods of time (couple of weeks to a month of hands-on experience), but these instances have always been people under some team’s/body’s wing, whereas I do not have that luxury. I feel that even if I were learning Haskell with somebody else who was also brand new to it, my progress would be faster, though this is just a gut feeling, I don’t know this for sure.

All in all, it’s really fun going. I am learning some new concepts, and even though I can’t go off and write projects yet I’m gleaning enough from the chapter exercises to give me experience. The book is really well written, and although I have nothing to compare it to, I would still recommend it as it is very accessible. Based on the above discussion, I decided to skip doing the chapter exercises for ch11 and ch12 for now and will come back to them if/when I need to, although the book has already made me feel guilty for that as they have been referenced already in ch13 discussion and exercises which makes me feel like I’m missing out. I have decided to at least do the hangman exercise in ch13 because as well as the experience of working on a project level, the game improvements I make will be valid proof that I am capable of understanding the code at this level, and is a nice stepping stone to show off on my way to getting the necessary experience.