Paradigm crisis

Ever since I took the Haskell 101 course I have gradually entered a state best described as a paradigm crisis. Prior to that course I happily hacked away in an object-oriented fashion, and I felt pretty confident in how to tackle problems when I faced them. I knew the most commonly used design patterns and how to look up the ones not that frequently used when needed.

Then came functional programming.

Admittedly I was not immediately convinced when I took my first steps in the Haskell 101 course, and I think the reason for that was that I did not quite see where these new functional tools would fit into my very object-oriented toolbox. Somewhere in that toolbox, along with factories and decorators, I had to find room for map, fold, filter and other functional concepts so I could easily find them.

It turned out that I actually needed a whole new compartment in my toolbox, as object-oriented programming and functional programming indeed are two very different paradigms.

It is true that we in the hybrid world of Java 8 can mix these two paradigms as we see fit, but when we are writing functional Java we leave the object oriented paradigm for a moment and become declarative and immutable, which is really cool. For me as (mainly) a Java programmer, the functional style of doing things are increasingly becoming my first-hand choice. I mean, what's the point of for-looping a list of elements when all I want to do is to grab some elements that matches a given predicate? The "old way" of doing this is way to error prone to be worth it. Moreover, when we leave out the "how" part when working with collections, the language can apply optimizations to the "how"-part. The declarative style of programming allows you to work on a higher level of abstraction and let the language worry about the specifics of "how".

Now, the leading paragraph of my blog post mentioned the word "crisis", which intentionally was a strong word to get your attention. ;) Although the new compartment in my toolbox have complicated my professional life a bit - especially at the time of writing when I am still a newcomer to the functional paradigm - I have noticed that I am starting to think about how to attack problems a bit differently than before. When in the object-oriented world, you would use all kinds of design patterns and language constructs to control mutability of objects in order to get a fair chance to understand and reason about what's really going on. In the functional world, you would instead work declaratively on immutable data structures, which means that we write code on a higher level of abstraction without the need to worry about mutable data.

And suddenly, the new functional toolbox compartment seems really compelling.

I have to admit that I may be a bit over enthusiastic right now, I usually behave like that when I try out new things that I like. But when listening to Martin Odersky in yet another course I'm enrolled in on functional programming I find it a bit sad that object-orientation turned out like it did in languages like Java. I mean, why is everything mutable by default? That doesn't make sense. And why did the programming courses I took at the university teach this mutable object-oriented way of programming? As far as I understand, imperative programming where everything is mutable has been a well-known problem for decades.

Time to sum up this blog post with a stupid quote coined by myself over a cup of coffe: functional programming is like sudoku! :)

This blog post was authored by Martin Moberg.