Clojure on Functional Programming
By: Ryan Towle
Tags: Clojure, Scala, Functional Programming

Authors: Ryan Towle and James Park

Date: November 10, 2020

Among college-level Computer Scientists, functional programming can get a little bit of a bad reputation. Programming is traditionally taught from a Java-based perspective–encapsulation, abstraction, inheritance, and polymorphism are truly the keywords of a beginner’s journey into CS, with other concepts like mutability left off to the wayside, along with many others. It’s for this reason that many are uncomfortable, let alone unfamiliar with the idea of immutability. We learn concepts like states, and even go in-depth into concepts like semaphores all for the sake of handling mutability, without even questioning why it is that we go to those lengths in the first place.

The truth is, the concept of mutability has been in the spotlight for so long that immutability has been forced to sit in the back seat, though not without good reason. Back during the 60s, when the first LISP was being developed, it just didn’t make as much sense to use all that extra space for what the language had to offer. Of course, when you live in a world where memory and storage isn’t as cheap as pennies on the dollar from your friends over at AWS, efficiency and re-usage become the best option, though as mentioned, not without their drawbacks.

However, the thinking of this era still prevails, despite the times changing quite so. Thankfully, we’re starting to see a bit of shift in the other direction. Over the last 2 decades or so, we’ve started to see a huge resurgence in the usage of functional programming languages, all thanks to a field called web development. It turns out that the key functional programming principles like immutability and function composition can be pretty useful in that context. As the market shifts more and more to the Internet of things, functional programming

Over this past summer of 2020, author and programmer Ryan Towle spent a few months at CollBox, a small finance startup based in Austin, Texas. There, he spent the summer learning a functional language named Clojure, which, much like Scala, is built on top of the Java Virtual Machine, though much more similar to LISP in its syntax and structure. It was there he learned about the fundamentals mentioned above.

It was from this experience that when Ryan was tasked with learning and utilizing Scala for a simple data analysis project, the process of applying functional programming fundamentals shared with Clojure became evident, as well as the differences between Scala and a type of LISP.

In terms of the programming fundamentals, there are two main differences between the two. Firstly, Scala is a statically typed language, while Clojure, being a type of LISP, is dynamically typed, essentially distinguishing where variables can be defined, as well as how they can be initialized before usage. Related to that is the second difference, Scala being object-oriented. Despite Clojure being built on top of the JVM, the language itself is not object-oriented, which aligns itself a lot more closely with more traditional functional programming languages.

Syntactically, Scala looks much more similar to Java, utilizing much of the same syntax surrounding variables, classes, and data structures, though still very different in terms of function calls, constructors, and function definitions. Clojure, being a type of LISP, takes a very different approach, treating the entire program as a single list. One of the signature traits of LISPs is the rather extreme usage of parentheses, as every function call comes at the beginning of a new pair of parentheses, with any related arguments coming afterwards. This even extends to basic functions like addition and subtraction. For example:

def number = 1 + 5

becomes

(def number (+ 1 5))

where the operator comes before the values, and is always at the start of the parentheses. These sorts of small syntactic differences make it often difficult to learn initially, but over time can reduce the complexity of learning new functions or libraries, as the format for a function call is standardized.

These are just a handful of both the syntactic and fundamental differences between the two languages, but hopefully these examples should make it clear that even within the paradigm shift that is functional programming, there are many different ways that languages can be expressed. After spending some time with them, we both recommend learning functional programming, due to the better understanding they can give you not just of functional programming, but even many other languages by proxy of understanding the alternatives.