Object-Oriented Programming Strikes Back!

disclaimer: the post contains some humor. if you are sensible to humorism, please, do not continue to read.

recently, i read the article beginning to doubt object-oriented programming on dzone. it is not the first post that i find on a blog that praises functional programming with respect to object-oriented programming. for all of these posts, object-oriented programming is dead (more or less). i think that at the basis of all these posts there is a misunderstanding of what functional programming really is. now it’s time for me to give my two cents to the fight among different programming paradigms.

first of all, i want to say that i respect the opinion of the author of the above article. what i am going to say it is my personal point of view on the issue. there is not an absolute right or absolute wrong opinion on this dilemma. so, peace and love to everyone.

what is functional programming?

i think that to better understand my point of view on functional programming, it is important to first understand what i mean with this term.

in computer science, functional programming is a programming paradigm [..] that treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data.

this is the definition given by wikipedia. did you read any references to lambda expression ? nope. so, abusing of lambda expression in your code does not mean you’re using functional programming paradigm.

first of all, you need referential transparency, which means that any time a function is called with the same inputs must return the same output. a precondition to implement referential transparency correctly is the immutability of state. once a structure (can we say a type?) is created, it cannot be subsequently modified in any way.

easy? referential transparency means no side effects, no exceptions thrown, no reading from external sources and so on. how can we be productive without these capabilities?

the hard part of the story

it seems that we are stuck in a black hole, doesn’t it? i cannot have side effects inside a function (not that bad), i cannot signal to function callers that something could go wrong, i cannot access to any external resources. oh gosh!

have you ever heard about monoids , functors , monads ? these are structures coming directly from category theory , a branch of mathematics. describing these structures are behind the scope of this post, but let’s do some examples.

i know for sure that you are using at least some monads in your code. if you are a scala developer, probably you used option[t] type, or either[t, e] , or any kind of collection such as list[t] , set[t] and so on. if you are a java developer you can take into consideration types like optional<t> , collection<t> and stream<t> . all of these types are monads.

these types have nothing in common from a behavioural point of view, which means that monads are a mechanisms to share some properties (basically, code reuse) among different types that are not directly related to each others. what does this mean? quoting the book scala design patterns ,

monads are structures that represent computation as sequences of steps. monads are useful for building pipelines, adding operations with side effects cleanly to a language where everything is immutable.

let’s borrow the definition of monads from the excellent book functional programming in scala .

a monad is an implementation of one of the minimal sets of monadic combinators (i.e. unit and flatmap ), satisfying tha laws of associativity and identity.

monadic combinators? associativity? identity? unicorn? wtf?!!? i am a simple developer: i hear about mathematics, i change programming paradigm.

where do i want to go with this dissertation? the real functional programming really deals with mathematical laws and theories. if you develop your programs following these laws, you will benefit of a bunch of good properties, such as composability, testability, thread confinement, coming directly from mathematical theory.

however, you need to study and learn mathematics. little drops of category theory will wet your face.

object-oriented programming

what about object oriented programming? have you ever heard about boring mathematical laws you have to follow? have you ever heard about esoteric terms like monads or functors, or anything else? have you ever applied some mathematic theory to your object oriented programs?

nope. the beautiful thing about object oriented programming is that is almost math-free. everyone can start to study and learn an object oriented programming language such as java, c++ or kotlin. at first sight, object orientated programming is very close to how we perceive reality.

as human beings living in the lucky part of the world, we know that every car is made by an engine, some wheels, a body and so on. we understand what a car type means and why it owns attributes of type engine , wheel and body .

object oriented programming is easier to learn than functional programming. stop. this is the only truth. both paradigms exist more or less from the beginning of computer era (think about lisp, for example, which is born in 1958). have you ever heard about an operating system written in a functional programming language? nope.

simplicity leads to tradeoffs

simpler means less constrained. less constrained means less formality to respect. less formality means that is simpler to use the programming language’s features in an erroneous way.

take the definition of monads that we gave just a moment ago. in the definition the constraints that a type must fulfill to be considered a monad are clear. math does not lie.

now, take any principle of object oriented programming: for example, the single responsibility principle. the principle states that

a class should have only one reason to change.

what the f**ck is a reason to change ? where is all the mathematical magic that principles that apply to functional programming languages have? no trace.

neither the definition of coupling , which is at the base of all the theories related to object oriented programming, is defined in a formal way.

coupling between components measures exactly their degree of dependency.

ok, so, how can i measure the degree of dependency between components? no formal way. i tried to give a mathematical definition of such concepts in one of my past posts, dependency , but it was only an attempt.

the lack of rigorousness in principles definitions leads to principles’ interpretation. personal interpretation often leads to errors and bad practices.

conclusion

having discussed the differences between functional programming and object oriented programming paradigms we discover and understand an important concept, which is:

the more a programming language is easy to learn, the easier it is to make mistakes using it.

the following graph tries to show visually the meaning of this sentence.

finally, object oriented programming languages are not going anywhere. we will continue to use them because they are easy to learn. also, functional programming languages are here to stay. every time we need to ensure some nice properties relative to our programs, they will help us a lot.

the world is full of trade-off. so, stop this war among programming paradigms and start to get the best from both sides of the force.