Functional-Light JavaScript By Kyle Simpson
Last night, I finished reading Functional-Light JavaScript by Kyle Simpson. I know that Kyle - commonly known as "Getify" in the JavaScript community - has published a number of books over the last few years (ex, You Don't Know JS); but, this is the first one that I've read. And, it's really good! Kyle has an effortless writing style and a knack for breaking down complex concepts into bite-sized pieces which he can then use to construct an increasingly-sophisticated and multi-faceted mental model in the mind of the reader. Before I opened this book, Functional Programming read like gibberish. And now, I can actually follow along. This may not sound like progress; but, it's actually a huge leap forward.
| |
|
|
||
| |
 |
|
||
| |
|
|
The subtitle of this book reads, "Balanced, Pragmatic FP in JavaScript." And, Kyle is exactly that: balanced and pragmatic. Nothing about this book smacks of Dogma or the wholesale belief that Functional Programming is the one true way to write JavaScript. If Kyle preaches anything here, it's that code is for the people, not for the machines:
I've come to believe something very deeply in recent years, so much so you could almost call it a religious belief. I believe that programming is fundamentally about humans, not about code. I believe that code is first and foremost a means of human communication, and only as a side effect (hear my self-referential chuckle) does it instruct the computer. (Kindle Location 104)
Throughout the book, Kyle comes back to this Truth, and reminds us that Functional Programming is not an end-game in and of itself; rather that Functional Programming is only a step in the direction of more readable, more trustable, more intuitive code. And, that the decisions we make in our application should always be held against that measuring stick.
This is where I will differ from many formal FPers: just because you can apply FP to something doesn't mean you should apply FP to it. Moreover, there are many ways to slice a problem, and even though you may have learned a more sophisticated approach that is more "future-proof" to maintenance and extensibility, a simpler FP pattern might be more than sufficient in that spot.
.... Remember, every single line of code you write has a reader cost associated with it. That reader may be another team member, or even your future self. Neither of those readers will be impressed with overly clever, unnecessary sophistication just to show off your FP prowess. (Kindle Location 327)
I have to say that I was particularly pleased that he even brought up the concept of readability with ES6's new Fat-Arrow function syntax:
No question this is more terse, sparse even. But I personally feel that whatever it may gain in symmetry with the mathematical notation, it loses more in overall readability with the functions all being anonymous, and by obscuring the scope boundaries, making deciphering closure a little more cryptic. (Kindle Location 1181)
In a time where programmers are blurring the line between "Code Golf" and "Production code", seeing his side-by-side comparison of traditional Function syntax with ES6 Fat-Arrow syntax (a presentation technique that he uses throughout the first half of the book), is eye-opening. It becomes painfully evident how much clarity a well-selected Function name can bring to the readability of code. And, how much is lost when we programmers do some such nonsense like:
var a = b => c => d => "Wat?!";
Of course, it all comes down to what you are familiar with. To me, this reads like Greek. But, I am sure there are many JavaScript programmers who would look at the above line and, without thinking, just accept the fact that it's several curried functions that result in a final Function that has access to the closed-over variables "b" and "c" as well as the incoming argument "d".
Kyle reminds us that reading code like this is not second-nature. But, that it can become second-nature because so much of Functional Programming is about "pattern matching". And, that, as we become more familiar with FP, we start to see concepts more than character tokens.
... readability is not just about fewer characters. Readability is actually most impacted by familiarity. (Kindle Location 252)
.... A functional programmer sees every function in their program like a simple little Lego piece. They recognize the blue 2x2 brick at a glance, and know exactly how it works and what they can do with it. When they begin building a bigger, more complex Lego model, as they need each next piece, they already have an instinct for which of their many spare pieces to grab. (Kindle Location 2091)
To this point, Kyle is completely transparent about the fact that moving towards Functional Programming is not an easy journey. And, while he whole-heartedly believes that it is a worthwhile journey, he is upfront about the inevitable slog through the "trough of despair". He opens the book with this warning; and then, closes it with very same sentiment.
I've found converting to FP is a slow iterative process rather than a quick binary flip from one paradigm to another.... Even after teaching FP and writing this book, I can still say that the formalism of terms and notation in FP is very, very difficult for me to process. I've tried, and tried, and I can't seem to get through much of it. (Kindle Location 295)
.... But don't stop when you dip toward that trough of despair and disenchantment. What's waiting on the other side is a way of thinking about and communicating with your code that's more readable, understandable, verifiable, and ultimately, more reliable. (Kindle Location 7099)
And now that I've painted a more-than-sufficient picture of Kyle's pragmatic tendencies and non-dogmatic viewpoint, may I say that he goes on to clearly and effectively explain what Functional Programming is and how it works. In fact, I found his explanation of Currying and Partial application to be the best that I've come across. Not to mention the fact that he actually makes functions like "identity" and "unary" seem like they are valuable. Oh, and now I finally understand the .pipe() operator in RxJS, which is super helpful for my Angular studies.
And thank you, thank you, thank you to Kyle for celebrating how important name-selection is! His pontification on the ambiguity of the .filter() method allows for the filterIn() and filterOut() articulations to land with a true wallop!
Before I read Functional-Light JavaScript by Kyle Simpson, I knew nothing about Functional Programming (FP). And, to be honest, seeing it show up in my team's application would, at times, make me downright angry. But, having now read this book, I can sincerely feel that anger starting to soften. To be clear, I haven't even reached the "trough of despair and disenchantment" yet. And I have miles to go before I sleep. But perhaps one day, I'll learn to enjoy FP, whose code is lovely, dark, and deep.
ASIDE: I have tremendous respect for Kyle Simpson as a developer, open-source maintainer, author, and speaker. But, I wanted to give him a special shout-out for his desire and effort to create a more cognizant, more inclusive industry. And, if you haven't seen him discuss Privilege Awareness, I would strongly urge you to watch The Economy of Keystrokes.
Reader Comments
I ?? all things Kyle Simpson and Ben Nadel. Great review!
@Chris,
?? = (Heart)
I got this book because of this post. I am only in chapter 3 so far, but this is some great stuff that I am clearly lagging behind in. It is a great book thus far. Thanks Ben!
@Jim,
That's so awesome! I'm glad to hear it. I'd be curious to know if there is anything in particular that jumps out at you. For me, it was basically "all of it" :D But, a huge stumbling block for me is feeling like I have to keep a "runtime in my head" of all the intermediary values and what they mean.
Thought, I suppose that gets easier as those "intermediary values" just become "known patterns".