One of the downsides of improving your craft as a programmer is that to do so you must wade into a vast ocean of opinion. At it’s simplest, you’re going to have to consume and manage conflicting ideas. It’d be nice if there was just one right answer, but those are very rare and hard won. At its worst, though, you get into religious wars.
Religious wars can be validating. On each side are people arguing passionately that the other side is wrong. You’re encouraged to find yourself on one side of the line or the other and once you do it feels right. We’re all tribal creatures and it feels good to find your side.
They can also be terrifically painful. People may call out beliefs that you hold deeply. You may struggle to at once understand someone as successful and smart but also so deeply wrong about something important to you.
You might even just find it painful for prosaic reasons. Unending debates are annoying and waste time. They fill important channels full of the same old noise.
Continue reading “You don’t have to choose a side”
Edit: I changed some wording to avoid potential bad connotations.
You don’t have to wander far into the functional programming world before you run into references to “purity”. Worse, you often hear it as an admonishment:
You should factor your code to use pure functions. Or, this function is complicated because it is impure. At the very edges there are even ways to write entire programs as “pure functions”. Those familiar with that practice have a tendency to lay blame for every fault at the feet of impurity.
Even the word is pretty polarizing. It suggests that your impure, dirty code is full of lurking issues and sits far away from some important ideal. But that’s a tragic point of view. Plenty of “impure” code is still simple, clear, and extremely valuable. The implied judgement is misguided at best.
But before we can talk about the tradeoffs of using pure functional style, we need to understand it. What does it mean for a function to be pure anyway?
Continue reading “A pure function does no funny business”
It’s likely that you’ve encountered functional programming as a way of describing certain kinds of programs, techniques, libraries, or programming languages, but if you haven’t already dug in and seriously attempted to understand these things then you might feel a lot of hesitation.
In some communities—for instance, the React community in frontend development—functional ideas are taking center stage and shaping expectations of what someone in that community ought to know. In others, functional techniques are available, but suggested only for special circumstances such as the
funtools module in Python. Finally, there are today rapidly growing groups which are heavily invested in these techniques such as the Scala, Haskell, Swift, and Elixir communities.
It’s perfectly plausible to write great programs and create great products without ever learning functional techniques, but as these techniques become more popular and widespread it’s easy to feel like you should be learning more about them. Is it really worth the investment?
Continue reading “You should study functional programming to become a better programmer”