This post is part 2 of a series on folds. Folds seem to crop up quite often in functional programing, and this series is my attempt to learn a little about the topic.
In part 1 we found that a fold is a way of abstracting recursive operations over lists. In this post we’ll look at a different way of folding; one that traverses lists in a similar way to a for/foreach loop.
Most software developers I know are really keen to improve their skills. But how do we know we’re improving? How can we tell if our efforts are effective? Without feedback on our progress, it is easy to feel swamped and demoralised by the rate at which stuff we want to learn piles up, compared with the rate at which we feel we’re improving. Setting and working towards goals can help address this.
Yet when I’ve asked other devs, most have great personal, work and non-tech goals, but have something to the effect of “become a better developer” thrown in as well. I’ve been thinking about this a bit recently, so thought I’d jot down a couple of thoughts about goals specifically related to software development.
I recently posted an attempt to explain folds using Haskell, and I got some feedback that the code samples were quite hard to follow for people that hadn’t played with Haskell before. Now the best way that I know of to quickly get started with Haskell is to go through the excellent Learn You a Haskell for Great Good guide. I heartily recommend leaving this post right now and reading it. The whole guide is available free online, but you can also buy print copies of the fantastic reference. Here’s the link again in case you missed it the first time.
Are you still here? Oh. Well, seeing as you don’t seem to want to listen to my advice, you deserve the rest of this post. It features a complete Haskell-n00b sharing his ignorance and misinformation with a reckless disregard for your quest to understand the basics of Haskell in a way that may permanently impair your ability to learn Haskell, understand functional programming, operate heavy machinery, socialise with other humans or be trusted with the weighty responsibility of goldfish ownership.
The aim of this post, despite your reticence to go through an extraordinarily helpful Haskell tutorial, is to get going with the very basics of Haskell insanely quickly and with a minimum of understanding about what’s actually going on. Because that’s just the way I roll. And let’s face it, you deserve it for not taking my advice. ;) (Last chance for redemption.)
I’ve recently been trying to learn some functional programming, and one of the first things to trip me up was the idea of folds. Folds crop up all over the place in both functional and imperative languages, so they’re worth understanding. At their simplest, folds seem to be a short-hand for defining recursions over lists, but I find I start getting lost somewhere between fold types and optimising for languages with lazy evaluation.
This series on folds is my attempt to pull together the little bits and pieces I’ve managed to pick up into a form I can understand. If you’re not familiar with folds, hopefully it will help get you started. If you already know about folds then you probably won’t get much out of this, but if you do read through it I’d love to get corrections via the comments or via email so I can update the post.
In this first post of the series we will try to work out what folds are. We’ll start by looking at some problems we can solve using recursion over lists. We’ll then try and work out what these solutions have in common, and factor that out. Finally we’ll see how this relates to folds, and how we can use folds to solve these problems more succinctly.
After blogging for five years on Blogger, I’ve finally decided to take the plunge and run my own blog. I’ve actually really enjoyed hosting with Blogger; I think it’s a pretty under-rated platform. It’s easy to get started, possible to do all sorts of crazy customisations, and they’ve recently started adding some cool stuff like mobile templates and different dynamic views. So why on earth am I leaving again?
Over the last couple of weeks I think I’ve identified one of the main things I enjoy about programming. For me, it seems to be the puzzle-like aspect of it; finding ways to slot small bits and pieces together to create/achieve something bigger. When I’m working on a problem I can approach in this way I find it much easier to get into a good flow where I’m productive, creative and happy.
This idea started to dawn on me while I was in Joshua Kerievsky’s Refactoring workshop at YOW 2011. We were going through refactoring exercises, but trying to take extremely small steps to keep the tests green. The final goal could be achieved fairly easily by moving a few chunks of code around while keeping the tests broken for a while, but I really enjoyed the challenge of finding small steps that would keep the tests passing all the way to the fin…
A few weeks ago I decided to depart from my usual QWERTY use and try an alternate keyboard layout. Rather than go the moderately rare Dvorak layout, I decided to go full-hipster and try Colemak. This post describes the ensuing hilarity and (mis)adventure.
I type reasonably well with QWERTY: normally between 90 - 110 wpm. I started doing some practice to try and improve my accuracy and technique and noticed a few things. First, my right hand tended to drift all over the keyboard (away from the home position), which would result in me sometimes getting lost and making a mistake. A mistake at 110 wpm means typing aro…
There are lots of benefits to automating common, recurring tasks like builds and deployments. We gain reliable, repeatable results and remove the cost of duplicated effort. However I’ve just come across a related benefit that makes it worthwhile considering automation for less common tasks, and that’s as a form of reliable documentation.
I’m currently battling some driver signing issues. We have some incomplete documentation from a previous occasion we’ve been through a related problem, but no one remembers the exact steps used. Because this previous occasion was reasonably considered a one-off, it was never automated. If it had been, it would now provide reliable, repeatable, unambiguously documented steps for getting me out…
I’ve been thinking through how I use test doubles (mocks, stubs, test spies, etc) recently, and thought I’d write down a snapshot of my current opinions on the subject.
I’ve written about this before, and I still think it is good advice. Test down to your lowest level of abstraction, then integration / contract / acceptance test over the boundary. By mocking a type you don’t own that dependency starts bleeding in to your code and push…
Had a really odd git problem this week, with an even odder solution, so am posting in the hope of helping the next poor dev who has to try and track this down via Google.
We had a branch checked out with 2 new commits on it, and we wanted to squash it into a single commit using git rebase -i (basecommit). This would start the normal interactive rebase, then get into a loop of printing the following error to console:
mv: cannot move '.g...