Object Oriented Programming vs Functional Programming

Object-Oriented Programming has been the dominant approach for the past couple of decades, but Functional programming languages are growing in popularity and influence. So is OO programming outdated? Is Functional programming a fashion that simply misses the point?

Many Functional programmes think that Object Oriented programming is bad. Many OO programmers think that Functional Programming is not scalable, what is the truth?

In this episode, Dave Farley explores the software engineering question of object-oriented vs functional programming. Where did these ideas come from, what do they mean and why do they matter. Also, are there other ideas that may be coming in future?

-------------------------------------------------------------------------------------

Also from Dave:

🎓 CD TRAINING COURSES
If you want to learn Continuous Delivery and DevOps skills, check out Dave Farley's courses

📧 Get a FREE guide "How to Organise Software Teams" by Dave Farley when you join our CD MAIL LIST 📧

-------------------------------------------------------------------------------------

📚 BOOKS:

📖 Dave’s NEW BOOK "Modern Software Engineering" is now available on

In this book, Dave brings together his ideas and proven techniques to describe a durable, coherent and foundational approach to effective software development, for programmers, managers and technical leads, at all levels of experience.

📖 "Continuous Delivery Pipelines" by Dave Farley

📖 The original "Continuous Delivery" book by Dave Farley and Jez Humble

-------------------------------------------------------------------------------------

CHANNEL SPONSORS:

-------------------------------------------------------------------------------------

REFERENCES

[mikefromwa]

"Let's be clear, you can write crap code in any paradigm"

I see you're familiar with my work...

[keuqweh]

"It's not about objects, it's about sending a message" :-)

[hplugins]

"You can write crap code in ANY paradigm" - You been looking over my shoulder ? :)

[mike.hawk_]

Non programmers: Oh programmers seem so smart, you have to be some kind of genius to understand code
Programmers: Unga bunga OOP tribe sucks

[ducodarling]

I feel like I'm in programmer church, listening to a sermon

[travis]

As for any dogmatic approach to software engineering, I'm over it. The best paradigm is what gets the job done with the least cognitive load. When you get too dogmatic about it you can pat yourself on the back but you will end up with less readable, less maintainable code and your successor will curse you.

[Pedroantos_]

10:54 "let's be clear, you can write crap code in any paradigm!"

[marcosdiez]

I coordinated a public Logo workshop in the early 90's that ran for 4 years with about 30k attendants, in which we tried to verify Seymour Pappert's theoretical approach. Logo was devised as a learning system in which the screen were used to reflect the way we think about the world around us and the problems we try to model and solve, bringing awareness of Jean Piaget's genetic epistemology (the process that generates our knowledge). The language was devised as a way to implement this learning/researching system, and a key concept for this was the "sintonicity" property: the language should be as closest as possible as the way you express your thoughts to minimize the interference of the translation effort between your own natural language and the computational one, hence one of its features was that the primitive instructions were translated to the final user's language (you had Logo in English, in Swedish, in Spanish, we even contributed to translate it to Quechua). Logo was a functional language, initially a LISP shell (you had lists to manage data and it heavily resourced on recursion). As to be allowed to proof Pappert's ideas that challenged Piaget's ones regarding the immutability of the order of concepts children learns at early ages to understand spatial concepts, the turtle was used, either a robot able to move drawing lines like a kid does following instructions a kid can formulate (move forward 10 steps, turn right 90 degrees) and reproduce, or a triangle drawing in the screen. The thing is, Logo succeeded in this "sintonicity" property when drawing graphics for the programmer could do by themselves exactly the same the turtle would and understand where their ideas on how to solve a problem divert from the reality, but then failed misserabily to provide a similar sintonicity to manage pure abstract data because lists and its operators weren't a natural way to think and arrange data.

Now, there's an article in Scientific American from 1971 that described Smalltalk as an attempt to address this very issue and find a more "sintonic" way to deal with the data. Back then the language didn't implement inheritance (it would appear in Smalltalk '80), but just the idea of messages being sent back and forth between entities that "learned to do things" by following the same principles from Logo. The entities were initially turtles instantiated and addressable by a given name, which could "learn" about data. So you'd create a turtle called Paul and tell it (sending a message) to learn that "age" was "12", you would teach the turtle (a new function or method) how to do some math, and you could ask for the "age" or to do the taught math and return the answer. Eventually you'd create another turtle Susan and would teach it how to ask Paul for the "age" or for it math to do something more complex and either return or act accordingly to the answer. Hence the name "small talk". The concept has proven so sintonic that it evolved into OOP paradigm as seen nowadays: having turtles that managed data but didn't appear on screen to draw stuff didn't make sense, and addressing every entity as a turtle got in the way of the sintonicity, hence in Smalltalk '80 inheritance appeared defining a basic object from which other entities inherited its "knowledge" (of how to answer to certain messages) and the turtles became objects specialized in drawing stuff on screen.

Hence, there was a path connecting functional languages (LISP and Logo) to OO ones (Smalltalk) with the explicit goal of allowing us to represent our ideas of the world "sintonically", e.g in our own terms instead of the ones sufficing the computer requirements, which in turn determine how "expressive" a language is to model certain kinds of ideas.

[Mark]

"We've identified all the paradigms that there are to find"

Reminds me of that legislator around 1900 that wanted to shut down the patent office because "everything has already been invented".

[ContinuousDelivery]

It looks like I am going to have to fire my extensive team of copy editors 🤣
I am afraid that I made several typos in this video, and then missed them in my review before release.
So here are the corrections, and I promise to try and do better in future.

4:09 It is "Edsger Dijkstra" not "Esgar"
4:25 "Constrains" not "Contrains" then I copy-pasted the same typo to 6:44, 7:09, 7:15 and then 7:48 - Doh!

Last but not least (maybe not even last?) is the biggy, I mistyped the Scala code example!

I usually prefer to copy a screen-snapshot of code to avoid this dumb kind of mistake, but thought that I would try something different for these simple examples - Lesson learned!

13:56 The Scala example should read:

val x = someCollection.foldLeft(0)((y, c) => y + c.size)

not
val x = someCollection.foldLeft(0)(y, c) => c.size)

No wonder it wasn't the clearer representation!

Very sorry for these mistakes, but I hope that they don't detract too much from the ideas in the video.

[magiclover]

Even with a few errors a very articulate argument and well presented. I often find myself borrowing from both philosophies. Especially the immutability approach of functional when dealing with multi threaded or async systems. Following functional guidelines can also help when designing slim micro services, which in the current landscape of cloud focused computing is a bonus. However I also like the encapsulation and polymorphism concepts of OO. When it comes to data persistence I've always found it easier to think of it from an OO stand point.

[ianollmann]

Appreciate the experienced perspective. For those of us who cut our teeth on “anything goes” languages, it is more intuitive that different approaches work better for different problems, and a one-constraint-fits-all design ties your hands unnecessarily in very painful and unconstructive ways at times that do not benefit the end product.

[sryx]

I wrote software for years before finally starting to actually study coding paradigms. The personal breakthroughs in my journey really began once I read The Little Schemer. It made me go back and see how much complexity I had created because I didn't understand recursion. It also radically changed the way I wrote code in all kinds of languages.

[rhbvkleef]

You essentially described Erlang with that message passing example.

[simonr]

For anyone interested in this discussion, I suggest reading the paper "Why functional programming matters" by John Hughes, who takes the view that we shouldn't focus on what FP *doesn't* allow (no side effects, no flow of control) but what it does enable (modularity, through higher-order functions and lazy evaluation).

[nathanarnold]

I write with a mix of paradigms these days, where the deciding factor is usually readability. Most of the time, that's functional. I don't think the FP examples in this video were fairly chosen. Good functional code does not need to be so cryptic, but I do agree that it requires understanding some different concepts. I'd like to share and resonate the point that you can obtain the benefits of either paradigm in any language (or almost any) with some discipline, and this is why it's a good idea to learn both. I'm sure this extends to other paradigms as well.

[hkejhkm]

The thing I envy about fp languages is the expressiveness of their type system. Function composition, partial application, mappings are all impossible to implement without abusing the type system with most programming languages, even though using these constructs is extremely easy to do: f(g(x)), f(a, b, c), out[i]=f(in[i]). This lack of expressiveness is really what makes me think "I really wish I could write this in Haskell".

[TinBryn]

That paradigm you explained at the end about multiple modules sending data between each other and otherwise being single threaded is pretty much exactly Communicating Sequential Processes (CSP) as described by Tony Hoare in 1978, and published in a book in 1985.

[sunshinelizard]

One plus of functional programming is the ease of writing tests against the functions. Work in Clojure for a while honed my attention to the testability of any code I write, so I got better at writing smaller functions.

[llpBR]

I do agree about everything said here. My only complain nowadays is the overcomplicated codes I find in OO around. Things you could easily solve with a script or a sql procedure are solved using a huge amount of things, using a lot of memory and processing.