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.
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).
Yes, it’s that time once again… Time for yet another front-end JS library!
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?
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.
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.
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.