To hear some people talk about functional programming, you'd think they'd joined some kind of cult. They prattle on about how it's changed the way they think about code. They'll extol the benefits of purity, at length. And proclaim that they are now able to “reason about their code”—as if all other code is irrational and incomprehensible. It's enough to make anyone skeptical. Still, one has to wonder. There must be a reason these zealots get so worked up. What are they so excited about?
What happens when you learn functional programming and you start writing better code… but the rest of your team hates it? Do you give up? Write code you know is inferior? Do you quit and get a new job? What if quitting isn't an option? What do you do then?
To hear some people talk, you'd think function composition was some kind of sacred truth. A holy principle to meditate upon whilst genuflecting and lighting incense. But function composition is not complicated. You probably use it all the time, whether you realise it or not. Why, then, do functional programmers get all worked up about it? What's the big deal?
Property-based tests give us more confidence in our code. They’re great at catching edge-cases we may not have thought of otherwise. But this confidence comes at a cost. Property tests take more effort to write. They force you to think hard about what the code is doing, and what its expected behaviour should be. It’s hard work. And on top of that, running 100+ tests, is always going to take longer than running 3-5 example-based tests. This cost is real, and it raises the question: How do we keep ourselves from over-specifying or writing unnecessary tests?
Property-based testing helps us write better tests, with less code, and greater coverage. This leads to more confidence in our code, and fewer bugs in our applications. But, as always, there's a price. Property tests take more effort to write, and they take longer to run. Still, I'm convinced that the trade-off is worth it. In this article, we'll run through an example of how to write property tests using fast-check.
Lots of people treat the ternary operator with suspicion. At first glance, ternaries appear unnecessary. Nothing more than a tool for the overly clever to trim some characters from their code. A favourite hack for coders who don’t care about readability. And sure, it’s all too easy to turn ternaries into an indecipherable mess. But what if we’re missing something? What if there's more to ternaries than meets the eye?
Remote work is a mixed bag. Some aspects are wonderful. The lack of commute and extra flexibility is great. But there are drawbacks. Being remote comes with radical changes to how we communicate. Things that were effortless and unconscious in person become tiresome when we’re remote. And right now, so many of us are trying out this remote experiment together. But as time goes on, maybe the novelty is starting to wear off.
Did you know there’s an algebraic structure for functions? That may not surprise you at all. But it surprised me when I first found out about it. I knew we used functions to build algebraic structures. It never occurred to me that functions themselves might have an algebraic structure. The structure is fascinating, but functions can be rather abstract. So we'll look at some concrete things we can do with React functional components.
Staring at a blank screen can be scary. And writing is hard work. Don’t let anyone tell you different. It takes extended periods of concentration to write anything significant. And that's a rare commodity these days. And even if you manage to beat your attention into submission, the craft of writing is still complex. It can be tough to know where to start. What if my writing turns out to be boring? What if nobody reads it? What if people hate it? Or worse, they start reading and get so bored they quit?
Algebraic data types and algebraic data structures sound similar. It’s like they ought to be the same thing. But they’re not. They both have ‘algebraic’ in the name, so it’s confusing. I got them mixed up at times. Others have too. But, they’re different concepts. Understanding the difference will help if you’re trying to learn functional programming.
Type classes are not the same thing as algebraic structures. But you'll find many people use the terms interchangably. And that can be confusing. It confused me for a long time. In this article we look at what type classes actually are. And we’ll also look at why programmers from other languages are so enthusiastic about them.
It's hard learning functional programming on your own. But it ought not to be. You don't need a PhD to understand functional programming. The concepts are abstract, yes. But that doesn't make them incomprehensible. It shouldn't be this difficult. This is the first in a four-part series on things I wish someone had explained to me about functional programming.
“Higher-order function” is one of those phrases people throw around a lot. But it's rare for anyone to stop to explain what that means. Perhaps you already know what a higher-order function is. But how do we use them in the real world? What are some practical examples of when and how they're useful? Can we use them for manipulating the DOM? Or, are people who use higher-order functions showing off? Are they over-complicating code for no good reason?
Trees come up a lot in web development. As in, more than you would expect. They pop up all over the place. But trees can be tricky. If you're like me, you know that there ought to be a way to process them neatly. You might want to change all the values, or make some calculation on the tree. But the way to do it isn't always obvious. And utility libraries like Ramda or Lodash don't come with tree-traversing functions. So, what do we do?
Transducers are very cool. They give us a lot of power. But they are also a bit abstract. And that makes them hard to explain. But they also embody the dream of functional programming. We write tiny, simple functions. Then we piece them together with flexible tools that work for lots of different data structures. And we end up with powerful, performant programs.
The array reduce method is really powerful. But people often run into trouble as soon as they step beyond the basic examples. Simple things like addition and multiplication are fine. But as soon as you try it with something more complicated, it breaks. Using it with anything other than numbers starts to get really confusing. I think this is because the examples in most tutorials mask some of what's going on. This article looks at some of the more interesting things you can do with .reduce() that better show how it works.
As functional programmers, we like to piece our programs together out of small pieces. Our main tool for this is composition. We take an input, process it through a function, then pass it on to another function. And this all works great so long as all our functions take exactly one argument. Which never happens. So what do we do? In general, we turn to a set of tools called combinators. This article focusses on a particular combinator called lift.
Currying is one of the most formidable weapons in our functional programming arsenal. Combined with composition, it’s extremely powerful. But is currying useful if you’re doing object destructuring with your function parameters?
If you start learning about functional programming, it won't be long before you come across the idea of pure functions. And as you go on, you will discover functional programmers appear to be obsessed with them. “Pure functions let you reason about your code,” they say. “Pure functions are less likely to start a thermonuclear war.” “Pure functions give you referential transparency”. On and on it goes. And they have a point. Pure functions are a good thing. But what do you do with the impure bits of your code?
What is art for? What is the point of it? It’s not like food, clothing and shelter. We don’t die without art. At least, not straight away. Take away air, or water, or food, and we die. But we seem to be able to last much longer without art. Art doesn’t appear to be essential for life. In fact, it even seems frivolous at times. Its utility is not obvious. Yet, we humans keep making it. And the better our physical needs are met, the more art we seem to make.
Have you ever visited different types of churches and listened to how they pray? Growing up, I had the privilege of visiting several churches. They were all different. And the people in them prayed with different styles.
Nobody wants to deliver late, over-budget software. I don’t know a single software developer who wakes up in the morning and thinks “I’d like to do a rubbish job today. How can I cost my employer more money?” And yet, so many software projects don’t go well. And with every new project, there seems to be more and more pressure to go faster. So, if we’re in the business of making software, what do we do? How do we go faster without compromising quality?
Have you ever started writing some code that seemed so simple? But then you had to validate the input? And handle an edge case? Oh yeah, and that weird thing the server sometimes does? And somehow this oh-so-simple piece of code turned into a mess? This article looks at how we can reduce the complexity introduced by conditionals.
I’ve been working a lot with a legacy code-base lately. And this one is particularly troublesome. It has all the hallmarks of a rush job. The code is brittle. There are no tests. Things often seem to break at random. And to my embarrassment, I wrote most of it. So, I've been thinking about how I ended up here. How did the code get so intertwined and brittle? And how do I prevent it in future?
Is it OK for a Christian to write fantasy stories? The bible is pretty clear that people should not use magic. Why would it be OK to write about magic? And isn't the whole idea of writing fantasy stories frivolous anyway? Wouldn't our time be better spent serving the poor and telling people about Jesus, or even reading the bible? I would argue that not only is it OK, but if you are a Christian with the inclination to write fantasy stories, it’s helpful if you do.
How to you make yourself do things that you don’t feel like doing? When it’s a cold winter morning and you have to get up in the dark to go to work, how do you make yourself leave the warm bed? If you’ve just started a diet, how do you resist the doughnuts your work colleague decided to share? How do you make yourself strap on the running shoes and go jogging? Doing things you don’t feel like doing is hard work---it takes willpower. But where do you get the motivation?
‘One weird trick’ is a cheesy title, I know. Originally I was using it as a draft placeholder title for a joke. But the more I thought about it, the more it seemed appropriate because it's true. Test Driven Development is one weird trick that will change the way you code forever. It will make you a more badass developer.
A friend of mine asked me for some advice before he got married. This was my response.
Sometimes TDD can seem like a drag. Are you writing mocks that are several times more complicated than the code you will test? Does your test suite take minutes (or hours) to run? Does refactoring your code fill you with dread because of all the tests to rewrite? If any of this sounds familiar then it may be time to try a new strategy.
I really like Star Wars, and I enjoyed The Force Awakens. I think that when you dig below the surface, the ways in which it agrees and disagrees with Christianity are different from what you might expect. In the end, the Star Wars movies are just that: a bunch of movies. But, as I've said before, if we watch in the right way, movies can point us to something deeper and more meaningful—a new and better hope.
In the last article, we saw how functional programming can be used with arrays. In this article we examine higher-order functions—functions for making functions.
In the previous article, we saw how functions can be used to make certain code abstractions easier. In this article we apply these techniques to arrays and lists.
Over Easter, our pastor challenged us to live like Jesus is actually risen. Someone I know (quite rightly) asked the question “but what does that look like?” My response is that part of the answer is righteousness, but that might need some explaining.
First of all, I write this to myself as much as anybody. Now, with that said…
I am concerned about how Christianity is perceived by those who don’t call themselves ‘Christian.’ It’s not that Christians are ridiculed in the media (we’ve always been ridiculed), but rather, what people assume I mean when I call myself a Christian is so very different from what I actually mean that I’m almost hesitant to use the word.
For a recent project I needed to process some code in parallel. A colleague pointed me to the
pcntl_fork() function, and it turns out it’s not quite as scary and complicated as I thought. So I turned the simple use case into a generic function.
These are some notes to myself on how I would like to approach my work, at least, an ideal for who I would like to be as a Christian web developer. I write this mostly to organise my own thoughts, but I am publishing it just in case there are others who might find it helpful.
You can find a reasonably sensible example of how to perform parallel processing with PHP using the `popen()` function at wellho.net. Sometimes though, the requirement to pass all the parameters to your function via command line arguments can be limiting.
Why would Christians watch movies at all? They are full of violence and bad language and plenty of other things we try to avoid. They are made by people who have completely different world views than our own, and disagree with most of the beliefs we hold most dear. Why would we fill our heads with all this simply for the sake of *entertainment*?
Drush is a tool that allows you to perform common Drupal tasks from the command line.
Why is communication so difficult?
Sometimes I will talk to somebody, and think that I’m expressing
myself really clearly when I’m not. I seem to make perfect sense. Yet
when I hear what the other person says in response, it is obvious that
they heard something quite different from what I thought I said.