History is proof that removing a dangerous feature can greatly improve the quality of code. Today, we have a slew of dangerous practices that compromise the robustness and maintainability of software. Nearly all modern programming languages have some form of null references, shared global state, and functions with side effects—things that are far worse than the GOTO ever was.

How can those flaws be eliminated? It turns out that the answer has been around for decades: purely functional programming languages.

Suppose you learn some functional JavaScript, and it’s wonderful. But, for some reason, your team doesn’t get it? What do you do? To understand what’s going on, we need to step back and get a little perspective…

We did an episode on functional programming in Go with Aaron Schlesinger back in 2019… But that was before generics were a thing. Let’s revisit the topic and discuss the pros and cons now that we have generics. What’s changed? What hasn’t?

Functional programming is powerful in many ways, but it can be difficult for devs to learn because the jargon stops them in their tracks. If that’s been your experience, this glossary of terms and examples might help. Pair that with listening to Eric Normand talk about FP in simple terms with us on The Changelog and JS Party and you’ll be well on your way.

Take a tour of Python’s functools module and learn how to use its higher-order functions to implement caching, overloading, creating decorators and in general how to make your code a bit more functional.

This week Jerod is joined by Paul Biggar the creator of Dark, a new way to build serverless backends. Paul shares all the details about this all-in-one language, editor, and infrastructure, why he decided to make Dark in the first place, his view on programming language design, the advantages Dark has as an integrated solution, and also why it’s source available, but NOT open source.

In this game, your goal is to create a sequence of functions which transforms the colored cubes into the desired pattern.

It starts off pretty easy, but there’s plenty of challenge once you get past the first few levels. A wonderful companion to our recent FP episode of JS Party with Eric Normand (a must-listen if you’re FP curious, IMHO).

Eric Normand (long-time FP advocate and author of Grokking Simplicity) joins Jerod and KBall for a deep conversation about Functional Programming in JavaScript. Eric teaches us what FP is all about, details the functional side of JS, and reviews the good/bad/ugly of React.

Oh, and join us in the #jsparty channel of our community slack where we’re giving away three FREE e-book copies of Eric’s new book! 🎁

Yes, it’s that time once again… Time for yet another front-end JS library!

Since Moon is so simple at its core, where it creates an abstraction to allow drivers to handle input and output, it only weighs 2kb minified and gzipped. On top of that, it is specifically optimized for JavaScript engines to perform fast virtual DOM diffing and DOM operations.

Often times “simple” is a proxy for “only solves my immediate use-case, but I will continue to link up JS solutions that bring good ideas to the table, and pure functions are a good idea for many reasons.

Like so many of Dan Abramov’s posts, this blew my mind. He is incredible at breaking down complicated concepts and making them understandable, as well as showing the reasons behind the concepts. Should you read this post? I’d say yes, but Dan would say:

If you’re the kind of person who likes to learn about programming ideas several years before they hit the mainstream, it might be a good time to get curious about algebraic effects. Don’t feel like you have to though. It is a bit like thinking about async / await in 1999.

“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?

A fascinating read on how transducers work, building them up from scratch from reducers using JavaScript, then showing how to uses built-in transducers from Ramda. And if all that sounds like gobbledygook, you’re not alone - but read this article and it will start to make sense. :)

Author James Sinclair on why bother learning this challenging concept:

A solution that would give us the elegance of using small, simple functions. But also the efficiency of doing our processing in a single pass through the array. What is this magical solution? It’s a concept called a transducer.

Quick and easy explanations of immutable data structures, pure functions, and first-class functions. Pairs nicely with Go Time #87.

I’m blown away by the clarity of explanation in this post, and came away with it excited to start using Reduce way more. Definitely worth a read to level up your game.

Reduce is the Swiss-army knife of array iterators. It’s really powerful. So powerful, you can build most of the other array iterator methods with it, like .map(), .filter() and .flatMap(). And in this article we’ll look at some more amazing things you can do with it. But, if you’re new to array iterator methods, .reduce() can be confusing at first.

Panelists Mat Ryer and Johnny Boursiquot are joined by guest panelist Aaron Schlesinger to ask/answer questions like; What is functional programming? Can you do functional programming in Go? Can we apply any learnings from functional programming languages as we write Go code today?

Daniel Brain makes the case for “functional-ish” JavaScript… code that utilizes functional programming concepts without going all-in on functional.

But functional programming does not need to be all-or-nothing, and in my view it’s better to be a little more pragmatic. That is to say, if you don’t do anything else, try writing code that’s functional-ish.

This definitely matches my personal approach. Fully functional still kinda blows my brain, but layering in functional approaches has dramatically improved my code. What about you? Would love to hear some functional or functional-ish “war stories”.

This is an absolute mindbender if you’re not already deeply in the functional world, but this post by James Sinclair is also a readable & fascinating look at how to incrementally move from a try/catch error management approach to a fully functional approach.

In this article, we’ll assume you already know about function composition and currying. If you need a minute to brush up on those, that’s totally OK. And a word of warning. If you haven’t come across things like monads before, they might seem really… different. Working with tools like these takes a mind shift. And that can be hard work to start with.

Go already supports many features that functional programmers might want: closures, first-class functions, errors as values, etc. The main feature (and in fact only feature for now) that Fo adds is type polymorphism via generics. Generics encourage functional programming techniques by making it possible to write flexible higher-order functions and type-agnostic data structures.

People have been asking for Generics in Go since the beginning of time. (2009)

At this time, Fo should be thought of primarily as an experiment or proof of concept. It shows what Go looks like and feels like with some new language features and allows us to explore how those features interact and what you can build with them.

Perhaps Fo’s author is hoping that enough traction/excitement around this project will convince the Go team to add Generics to the language.

Joël Quenneville:

Our world is full of uncertainty. This uncertainty bleeds into our programs. A common way of dealing with this is null/nil. Unfortunately, this leads to even more uncertainty because this design means any value in our system could be null unless we’ve explicitly checked it’s presence.

Imagine how many developer-hours are wasted globally each year dealing with null/nil. The number would probably astound us.

The major advantage of guard clauses is to suss out invalid inputs (often nils) at the perimeter of your program/module/function, so the rest of your code doesn’t have to concern itself with these uncertainties. But Maybe there’s another way…

In Elm, all values are guaranteed to be present except for those wrapped in a Maybe. This is a critical distinction. You can now be confident in most of your code and the compiler will force you to make presence-checks in places where values are optional.

Click through to learn the mechanics of it all.

Eric Normand joined the show to talk about Functional Programming. We talked about FP vs OOP vs Imperative, why FP is popular again, the advantages and disadvantages of Functional Programming, and teaching Functional Programming concepts.

Evan Czaplicki, creator of Elm, and Richard Feldman of NoRedInk joined the show to talk deeper about Elm, the pains of CSS it solves, scaling the Elm architecture, reusable components, and more.

José Valim joined the show to talk about Elixir. We learned about the early days of José’s start as a programmer. José took us back to the beginning of Elixir and shared why Erlang got him so excited, we broke down features of the language, we talked about functional programming, concurrency, developing for multi-core systems, we talked about the Elixir community, the future of Phoenix, Ecto, and more.

Richard Feldman from NoRedInk joined the show to talk about Elm and Functional Programming. Elm labeled itself “the best of functional programming in your browser” and boasts “no runtime exceptions.” We talked about the language, whether or not it’s really faster than React, JavaScript fatigue, and the best ways to get started with Elm.

Dan Abramov, creator of Redux, joined the show to talk about his path to becoming a programmer, his introduction to open source, React, JavaScript, functional programming in JavaScript, his thoughts on looking outside of your bubble to other ecosystems and borrowing/sharing what you can.