Developers, along with many Test Solution Developers, have to decide whether they want to jump on the functional programming bandwagon. I’m not here to extol the virtues of functional programming. What I am here to look at is something I hear particularly from many people, which is that functional programming tends to make programs less clear. This does have particularly relevance to me since I do like code with a high degree of clarity regarding its intention.

First, there’s a book I highly recommend called Functional Thinking by Neal Ford. It’s a fantastic book and it’s where I got my examples that I showcase in this book. These examples are also freely available in the GitHub repository for the book. If you want to use the code in this post (and from the book), you’ll need Java 8, Scala, Groovy, and Clojure installed.

My focus here is on determining if going with a functional approach sacrifices the clarity of code. However, I will also say this. Sometimes proponents of functional programming techniques do not do themselves any favors. In a somewhat related book to the one I just mentioned, Joshua Backfield in Becoming Functional says this:

Requirements and expectations today are difficult, so being able to closely mirror mathematical functions allows engineers to design strong algorithms in advance and rely on developers to implement those algorithms within the time frame required. The closer we bind ourselves to a mathematical underpinning, the better understood our algorithms will be. Functional programming also allows us to apply mathematics on those functions. Using concepts such as derivatives, limits, and integrals on functions can be useful when we are trying to identify where functions might fail.

Yeah, that’s great and all. Maybe it’s even true. But it does absolutely nothing for me in terms of deciding how much and to what extent I should care about functional programming based on what it can do for me. (That said, I actually do recommend Joshua’s book.) What I like to see are what trade offs I have to make when I switch from one language or one concept to another. One of the most important for me is clarity of expression in code. I had some concerns about this related to functional examples I’ve seen. So let’s delve into this a bit.

Word Frequency – Imperative vs Functional

In his book, Neal Ford attempts to contrast between the traditional programming style — imperative loops, essentially — and a functional approach. This is in service to an implementation of a word-frequency algorithm. So that everyone can play along, let’s first code up the imperative approach using Java 7. Create a file called Words.java:

Then create a Main.java file to put that logic to the test:

The output from this is:

{am=1, for=1, going=1, market=2, things=1}

The logic here is to determine the most frequently used words in a given sentence, printing out a sorted list of those words along with their frequencies, while also ignorning articles or connector words. The wordFreq() method has a Map that holds the key/value pairs. A regular expression is created that allows words to be pulled out of the phrase. The core logic of this method iterates over the words found, ensuring that a word is either added for the first time to the map or the occurence of the existing word is incremented for the frequency count.

As Neal says in the book:

This style of coding is quite common in languages that encourage you to work through collections (such as regular expression matches) piecemeal.

Now let’s change up the example to use the more functional aspects of Java 8. Change Words.java to look like this:

Here the results of a regular expression match are converted to a stream. (This uses the Stream API of Java 8.) Notice how this version of the code allows for performing discrete operations. A mapping is used to make all of the word entries lowercase. A filter is used to remove the articles and connector words. A forEach loop is used to count the frequencies of the words that are left after the filter operation. The find() method returns an iterator and that iterator is converted to a stream in the regexToList() method. That allows the discrete operations to be chained together. According to Neal, this is “the same way that [we] think about the problem.”

It was certainly possible to do all of this in the imperative version. You could have simply looped over the collection three times to perform the same discrete operations. So why not do that? Mainly because, from an execution perspective, that would be considered inefficient. So the core idea here is that the functional approach is giving you efficiency. What some would argue is that it’s sacrificing clarity. Put another way, while the imperative approach of the Java 7 example may be more clear, the functional approach of Java 8 is more efficient.

What do you think?

I know that some would argue that higher-order functions, like map() and filter(), actually do provide better clarity because they allow you, in Neal’s words, “elevate your level of abstraction.” But, again, what do you think? This is an important area to wrestle with as you explore the functional landscape. It’s the area where I’ve seen most people encounter cognitive friction.

Name Capitalizer – Java, Scala, Groovy

In the book Neal gives an example of a program that takes a list of names, remove any single-letter names, and then capitalizes the list of remaining names. Let’s recreate the example for ourselves. We’ll take a look at it in the context of the main JVM-hosted languages. As we go through this, consider that what this example shows, from a purely programmatic point of view, is three discrete operations that are taking place: filtering a list of names, transforming the list of names (so they are capitalized), and converting the list of names (into a single string).

Java 7

First create Names.java:

There you have the quintessential example of an imperative loop. For each name that is provided as part of the list, a check is made see if the length of the name is at least greater than 1. The name is capitalized (by calling an entirely different method) and then that capitalized name is appended onto a result variable. Comma handling is done by making sure that each name, except the last one, gets a comma appended to it.

Create a Main.java that will let you test it out:

The output of this will be:

Jeff,Emilia,Caity

Neal calls out a key point about this, which is that we are using the “same low-level mechanism (iteration over the list) for all three types of processing.”

Java 8

Let’s turn this into a Java 8 example. Modify Names.java so that it looks like this:

That will run exactly the same as the previous imperative example but I would argue it does provide quite a bit of clarity. But what exactly is happening? Functional programming describes programs as transformations, which is a low-level activity. Filtering, collecting, mapping — those are all transformations. As you can see with the above Java 8 example, those transformations are represented as higher-order functions.

Now let’s consider how we can do the above in other JVM-hosted languages.

Groovy

Let’s try Groovy first since it tends to be the easiest for Java developers to move to given the similarity of language constructs. Create a file called Names.groovy with the following code:

If you want to run it, just create a main method like this:

The output will be exactly the same. What Groovy mainly does here is allow you to remove some of the boilerplate of Java. I would argue the clarity remains.

Scala

Now let’s do the same thing in Scala. Create a file called Names.scala and put the following in it:

Again, same output. You could be forgiven for thinking that it looks like Scala is actually starting to remove some clarity.

But let’s stop a moment and consider what’s going on with both Groovy and Scala. The first thing to notice is that Scala, like Groovy, allows you to shortcut writing code blocks with single parameters. Groovy used “it”, Scala uses the underscore. Scala lets you use an underscore for the parameter if you don’t care what the actual name of the parameter is and Groovy lets you use “it”. If that reduces clarity — and it kind of does, I think — you can certainly use your own parameters.

Name Capitalizer – A Synthesis View

Let’s consider these different functional implementations, somewhat side-by-side, particularly since all of the code examples are doing the same thing. Here I’ll just focus on the core transformations that we are concerned about:

Do keep in mind that Java 8’s call to capitalize does require your own function, which is not the case with Groovy or Scala. It also requires use of the Stream API and the Collectors API.

In the case of Scala, a list of names is filtered and the output of that filter transformation is used as an argument to the map() function. The map() function executes the supplied code block on each element of the collection, returning the transformed collection. The collection is held by the underscore and so a capitalize operation is performed on each element in that collection. The output collection from the map transformation is then provided to the reduce() function. This function combines each element based on the rules supplied in the code block. So knowing that the underscore is holding the each element of the collection is key to understanding this functional example.

In the case of Groovy, a findAll() function is used on a collection. This is basically Groovy’s filter transformation. The collect() method executes the supplied code block on each element of the collection which, remember, is held by the implicit parameter “it”. The join() function is then called, which accepts a collection of strings.

The reduce() method being used in the Scala version is very much like the collect() method that was used in the Java 8 example earlier. In fact, collect() is really a special case of the reduce() function in Java 8. The collect() function used in the Groovy version is very much like Scala’s map() function.

I turn the question to you: has a functional approach maintained clarity when you remove a lot of the surrounding material? Does one language or another stand out as “better” or “worse”? I would argue that this is the kind of comparison that needs to be made for people who want to look at the essence of functional programming as compared to other styles.

Name Capitalizer — Getting Some Clojure

Since Clojure is usually stated as the functional language for the JVM, let’s consider a Clojure version of all this. Create a file called Names.clj and put the following in it:

If you’re not used to Lisp-like functional languages, the above is likely to scare you. Neal provides a good example of this in his book and describes it in detail. Basically, Clojure’s (filter) function accepts two parameters. The first is a function to use for filtering and the second is the collection to filtered. Here an anonymous function is passed that actually does the filtering and the collection is the names, of course.

The (map) function requires a transformation function as the first parameter. In this case, that’s a capitalization call. The second parameter must be the collection (names) but note that here the code is actually passing the result of the filter transformation, which is the filtered list of names. The result of the (map) transformation is passed as the parameter to the (reduce) function. The (interpose) function is like the collect() of Java 8, the join() of Groovy, or the reduce() of Scala.

So … Was Clarity Achieved?

Neal’s book takes you through further examples of how to make the Clojure version even more readable. He also shows you to make parallelizable versions of all of the examples. I don’t want to reproduce that here because (1) I’m still trying to understand it myself and (2) you really should buy his book, which I hope I’ve whetted your appetite for.

What I hope you got out of this post is that there is a good reason to look at functional programming concepts. It is an important area to become familiar with and as Neal says in the book:

Even if you don’t care about Scala or Clojure, and are happy coding in your current language for the rest of your career, your language will change underneath you, looking more functional all the time. Now is the time to learn functional paradigms, so that you can leverage them when (not if) they appear in your everyday language.

If I was going to build a new functional-based test solution framework right now and I wanted it to be in a JVM-hosted language, and assuming I didn’t want that to be something like JRuby or Jython, I would certainly avoid Java. (Then again, I avoid the Java language as much as I can.) I would likely pick Groovy, with Scala being a close second. The point here being that I need some basis to make that decision and the above provides me with some of that.

A personal goal of mine is to retain clarity of expression in my code at all times. Any language that does not allow me to do that is one I would tend to avoid. That, in fact, reinforces my view of avoiding Java and likely Clojure. I would still focus on Groovy and Scala. A known aspect of Scala is that Scala has some horrendous start up times — as opposed to operation execution time — when compared with other JVM-languages so if that aspect of performance mattered, it would lead me even more into Groovy.

Again, though, at least I would have a basis for making these decisions and that’s what matters to me. That’s certainly what I hope this post does for you: provides you a way for further exploration and thus making your own decisions.