I love data. I love everything you can do with data. I love how much data can tell us about the world. One of my favorite hobbies is to go over the StackOverflow annual developer survey and find those little outliers that tell interesting stories. In 2021, Clojure’s case is a perfect example.
Clojure is a functional programming language described by its author, Rich Hickey, as “kind of like Lisp for the JVM (Java Virtual Machine)” and designed to develop large-scale systems. According to its author, it’s fast and flexible, giving developers the tools they need to write clean code.
Let’s look at some facts:
- According to the StackOverflow survey, Clojure is a relatively unpopular solution, as only 2.25% of all respondents work with the language—not exactly eyebrow-raising.
- 81% of the people that work with Clojure love it, making it the second most loved language just behind Rust.
- Clojure has by far the biggest paying salaries in the business, just a bit over $90,000 annually, followed by F# (another functional programming language) with $81,000.
This immediately caught my attention. At first glance, it would seem like Clojure is a case of low supply and high demand. Few developers, therefore higher salaries.
But there is a more interesting story to be told. According to the State of Clojure 2021 survey, 65% of all respondents have been working as developers for at least 6 years. With almost 50% over the 10-year mark. Clojure is a senior programmer´s language.
An introduction to Object-Oriented Programming
Object-Oriented Programming has been the go-to approach in software development for the last couple of decades. Its origins can be traced back to 1961 in the works of Ole-Johan Dahl and Kristen Nygaard as well as the programming language Smalltalk, created by Alan Kay in 1980.
During the 1990s OOP saw incredible growth with the popularity of Java as an all-purpose multiplatform programming language. Likewise, this was the decade where many developers started focusing on GUIs (Graphical Unit Interfaces), an area of software development that is well served by an OOP approach.
Since most programming languages offer OOP to some degree it’s become part of the norm. For example, the 2 most popular programming languages at the moment, Python and JavaScript, have ample support for object-oriented programming.
As its name implies, at the core of OOP is the notion of an object, an “entity” that can have both data (called attributes) and code (called methods). Let’s explain it with a quick example:
Let’s say that we want to make a game about dogs. So, you create a class called “dog” that has attributes such as size, fur type, favorite foods, and so on. Dogs also do stuff, like walking, eating, sleeping, or playing with a ball. Those are all methods.
Now, let’s say you create 3 dogs, Fido, Max, and Buddy. Each one might have different values in their attributes. Even if they all share the class dog, they are independent. For example, if something happens to Fido’s data, it doesn’t affect Max’s.
That’s OOP in a nutshell. It’s a paradigm, a set of beliefs and practices that help you model the world and build software that is easy to manage.
Overcoming the Paradigm
Unfortunately, to paraphrase philosopher Thomas Khun, paradigms have their limits. The longer you spend working within a paradigm, the more you see the cracks on the wall. The more you grow as a developer, the more you push the boundaries of a paradigm.
The 2 most common complaints leveraged against OOP are:
- In the end, it doesn’t help prevent spaghetti code (messy code), it just hides it behind encapsulation.
- It doesn’t help to avoid side effects. Unless you are careful, objects can cause changes to other areas of the code.
It’s easy to control side-effects if you are working on a small project. But with 20 developers and millions of lines of code? That’s another matter entirely.
Going back to the Stack Overflow survey, 28% of respondents migrated from Java to Clojure, 16% from Python, and 15% from JavaScript. In other words, these are senior developers, with experience in object-oriented biased languages making the jump to a functional programming environment.
The same can be said for F#. In both cases, it’s not that these languages pay higher salaries, it’s that those senior developers who earn higher salaries are making the transition to functional languages. But why?
Once again, the survey holds the answer:
- 34% of all respondents use Clojure because they prefer a functional programming paradigm.
- 35% use it because they like the “Lispiness” of the language, which is a great alternative to the overall verbosity of Java.
This data aligns with anecdotal accounts. People who try Clojure do so out of a desire to find better ways to tackle the development process, especially people who’ve been working with Java. In essence, these are developers who have seen the crack in OOP and are looking for alternatives.
Where is Clojure used?
Clojure is well known as the backend language of Brazil’s Nubank, the biggest digital bank in the world. According to the latest stats, about 700 Clojure developers are part of Nubank’s development team.
Clojure is mostly used for financial services and enterprise software, with a steady adoption in both the healthcare industry and retail markets.
The language is a strong solution for both large-scale and small-scale businesses. But most of its user bases are startup companies. This stands to reason since it’s easier to start building solutions from the ground up than having to migrate previous work.
Why Functional Programming?
Functional programming proponents believe that their approach creates cleaner code that’s easier to maintain and requires less debugging.
For example, if you need to transform uppercase “A” to lowercase “a” you write a function that takes “A” and outputs an “a.” You don’t change the original data, you just use it to output something else. This avoids the problem of inadvertently transforming your data, which may create issues down the line.
That’s one of the many perks of a functional programming paradigm. Is it a replacement for OOP? I don’t think so, but it’s undeniable that functional programming is gaining proponents every day.
Senior developers who have made the change will bring in junior developers and teach them about this approach. It’s a ripple effect, one which I believe will popularize this approach down the line.
I don’t think OOP will be dethroned anytime soon, but having a bigger toolkit to solve problems is always a welcome addition to any discipline. Software Development included.
