Functional Programming Without Feeling Stupid

If you follow software design trends (yes, such things exist), you may have noticed an increasing amount of buzz about functional programming, and particularly the Clojure language. While functional programming is hard to define, almost everyone mentions pure functions, the lack of side effects and state, and easy parallelisation. As for Clojure, it is all about (a kind of) Lisp running on the Java Virtual Machine (and .NET, and transformed to JavaScript).

I’m somewhat convinced that functional programming is at least worth knowing about and trying out, even if you don’t expect to fully convert. It has been said that learning about the functional paradigm makes you a better programmer in your current imperative language. Functional languages reduce accidental complexity, and that helps you focus.

“Whoop de doo, what does it all mean, Basil?”

If you have a background in imperative languages, you will have an interesting time if and when you start digging into functional programming, because whatever else it is, it’s different. And I’m not talking about syntax only, but most of what you do. If you need to add an item to a list, you construct a new list with the new item appended to the previous list (no, it is not as inefficient as it sounds, because there is great stuff under the hood to handle that). This is because immutability is one of the cornerstones of functional programming. If you can’t change something after it is created, there is no state to mess up. You program with values, not stateful objects.

I see I’m getting myself tricked into presenting a definition of functional programming, when that has been done better elsewhere. For pointers, see Michael Fogus’ 10 Technical Papers Every Programmer Should Read (At Least Twice), including the classic “Why Functional Programming Matters” by John Hughes. But I actually wanted to talk about something else.

“Don’t ever, ever, ever call me stupid, OK?”

Some people may be scared off from trying functional programming, because there is a certain aura of smartness (if not smugness) about it, and that is not always a good thing. If you are a programmer who is working just fine with your existing programming language(s), but you want to get some fresh ideas or have some new doors open in your brain, it can be frustrating and demotivating when things get difficult (as they will with FP). The last thing you want at that point is any implication that you might not be smart enough to understand what you’re trying to learn. That hurts people’s feelings. The post Clojure Makes Me Feel Stupid resonated with me, since I have had similar thoughts. I really like Clojure, even though it occasionally does my head in, but understand that I’m the only one who can even hint that I’m too stupid for it, OK?

UPDATE (four hours after publication): I did some more background reading, and found out that Larry O’Brien wrote about this in 2012 for SD Times, and did not mince words: read Code Watch: Functional programming’s smugness problem]. (Ouch.)

There is also more than a whiff of academia in FP, and sometimes research work just isn’t practical enough to serve as a solid base for software development. Personally I have a slightly scholarly slant, so I’m not put off by references to papers, but practising software developers often are more pragmatically oriented. Clojure in particular seems to take a more pragmatic approach, while Haskell is quite academic and proud of it. Still, it should be possible to learn FP without knowing what a Hindley-Milner type system even is.

I have been reading about functional programming for many years now, and occasionally trying out something. I believe that is the way many others approach it, too, and it doesn’t have to be one or the other (everything functional, or everything OOP/imperative). You need more than one tool in your toolbox.

“What we’ve got here is failure to communicate”

About six months ago I started to learn Clojure in earnest (but I’ve also dabbled with Haskell on the side), and I’m slowly getting up to speed with it. There have been situations where I have felt that I’m just not getting something essential, and it hasn’t yet clicked in my head like object-oriented programming did in the early 1990s. Thankfully the material I’ve been reading has not explicitly said that you need to be super smart, or that Joe Average need not apply, but you can sort of read between the lines. For example, Clojure Programming by Chas Emerick, Brian Carper and Christophe Grand states in its first chapter that “Clojure demands that you raise your game, and pays you back for doing so.” Remember what was Python’s slogan? Yep, “Batteries included.” There’s a difference; I don’t recall any disclaimers for Python about needing to invest a lot more, but the rewards being that much greater. For functional programming, it would be enough to say that you need to think different, not better. I’m not saying you can’t demand someone to up their game, just that the phrasing needs to be gentle (which the authors of Clojure Programming have realized).

In any case, I want to explore this area a little more, and try to present some examples of functional programming that do not require you to “up your game” as much as “think different”. While I don’t claim that my newbie adventures in FP land are the best and idiomatic solutions, they at least represent the thought process of someone from the Kingdom of Nouns who has come to visit, and finds the landscape fascinating. Whether he will stay depends on the locals…

Stay tuned for more. In the meantime, take a stroll through the  Clojure from the ground up series, and/or take a look at The Newbie’s Guide to Learning Clojure. If you already have some FP-fu, why not check out Clojure Programming the book.

By the way, since this post seems to have circulated somewhat, I’m doing something unusual: I’m enabling comments, and if there is more ham than spam, I won’t have to close them again. However, don’t feel offended if you have commented something, and I need to close the comments due to spam. If nothing else, shout out the movie references in the subheadings.

UPDATE 2014-12-12: After nearly a month, I’m closing the comments on all parts of this series, because nothing but SPAM appeared. Still, I’d like to thank Melinda C. for her warm regards, quoted here: “Your passion and compassion are very evident in your speaking. There is not enough words to express my gratitude for your helping to awaken that white passion in my soul.” I didn’t understand all of that, and why she chose to post her comment as “Kobe Bryant 8 Jersey” I will never know. That’s such an odd name, why didn’t she just use her own?

UPDATE: Consider this Part 0 — now read also the others: