A friend of mine asked this question the other day. “Is it better to be a good person, or religious?” The question turned out to be more thought-provoking than expected. Not because I was stumped. Rather, my first reaction was: “This question doesn’t make sense.” Those aren’t categories a Christian tends to think in.

Function composition is beautiful. It lets us create elegant function pipelines. And when everything lines up, the data flows like maple syrup over pancakes. But what happens when the functions don’t line up? What if some of those functions expect more than one argument? What do we do?

Generators can be powerful tools for efficient data processing. But things get a bit tricky when we add asynchronous calls into the mix. Asynchronous generators, however, come to the rescue by handling scenarios involving promises. They come in handy for a variety of real-world scenarios. And one of those came up recently.

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?

You can go a long time as a JavaScript developer without ever feeling the need for generators. Hence, it’s natural to wonder: What are they good for? Why would you ever need one? What’s the point? But generators can do some neat tricks. And they may even change the way you approach certain problems.

There’s a common myth that using a functional style with JavaScript is always slow. While this is truly a misconception, it has some basis in truth. There are a lot of traps we can fall into while writing functional JavaScript. So what are they? And how do we avoid them?

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?

Javascript has its fair share of ‘wat’ moments. Even though most of them have a logical explanation once you dig in, they can still be surprising. But JavaScript doesn’t deserve all the indignant laughter. And now that BigInt is officially part of the TC39 ECMAScript standard, we have options. I’m going to show you how to take advantage of them.

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?

Fantasy land is great. It opens up a whole world of interoperable functions and structures. And the title, though originally a joke, is quite fitting. But Fantasy land isn’t perfect. And it’s not the only way to do algebraic structures in JavaScript.

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.

Algebraic Structures are something I wish I’d understood better, sooner. I had a hazy idea of what they were, but didn’t know the correct terminology. That was a massive barrier to finding out more. This article is my attempt to stop that happening to others. We’ll look at: What are algebraic structures? How do we use them in JavaScript? Why would we bother? What’s the big deal?

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.