Does Curry Help?
But as time has passed, the world has changed, and so have I. Is it still a good idea to lean on this technique to squeeze more expressivity out of your code?
I’m not so convinced.
“This isn’t Haskell”
When I originally presented currying as a possible addition to our toolbox at work, my colleague William (not his real name) adamantly insisted:
This isn’t Haskell!
Equally stubbornly, I argued that we should pilfer good techniques wherever we find them, no matter how obscure the source is. It took me a while to realise how right he was.
Simple might matter more, but easy still matters
In his talk ‘Simple made easy’, Rich Hickey prises apart the notions of simplicity and ease.
“Simple”, he proposes, means that concerns aren’t tangled up together. “Easy”, that something close to your current understanding.
But perfectly simple code - code that doesn’t needlessly intertwine any concerns - gains your team little if it’s outstandingly difficult to work with. What you need is a balance; simple enough to prevent bugs and survive evolving requirements, easy enough for your team to understand it without a crash-course in new techniques.
Symptoms and their causes
Haskell has a type system capable of catching many bugs at compile-time. When I’m stuck, I often compile programs I know are broken - and let the compiler error guide my next steps.
Supplying a curried function with too few arguments is an easy mistake to make, and it can often only cause an error at a much later stage in the code.
Embedded in the more complex code of most applications, it’s easy to cause yourself - or a fellow developer - to waste a handful of hours searching for the origins of a mysterious function.
A couple of months ago Josh Habdas commented on the original article:
Taking [ES2015] arrow functions into consideration the boilerplate shown to access the data in the examples would be simplified markedly
He’s not wrong.
Why Curry Help’s grand finale was sleek, no doubt. It represented using Promises and some utility functions to extract a list of a users’ post titles.
In a previous post, I explored how much boilerplate you can remove with arrow functions, and applying that new language feature here replaces most of the benefit that we got from curried functions in the first place:
Was I wrong?
Am I back-peddling faster than a contestant in a moonwalk race? Yup, pretty much.
And while I still try to push the envelope, over the last 2 and a half years, I’ve seen the value of meeting people much closer to where they are.
Got thoughts or questions? I'm here to help at email@example.com