Object Oriented Programming vs Functional Programming

"Let's be clear, you can write crap code in any paradigm" I see you're familiar with my work...

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

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

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

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

"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".

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

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.

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.

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.

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.

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.

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

The mistake is to believe a single paradigm is the best approach to solving all problems.

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.

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.

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".

I know that OOP encompasses a wide range of languages, so my initial reaction might be misplaced here. But you did mention Java, and it is striking to me just how much my experience with it was the opposite of "bringing me closer to the problem" as opposed to functional programming. The core idea of functional programming to me is composition. Because the functions are pure, you do not have to orchestrate them in a way that takes into account their side effects (as you would e.g. with imperatively creating a connection, imperatively committing it to a pool, imperatively checking if it is still open, imperatively disposing of it, etc). If a function does something in one context, you have a guarantee that it will do that exact same thing in any other context, which ultimately makes it cognitively cheaper to think on much higher levels of abstraction. Maybe Java wins in the loop-sum example, but looking at it gave me flashbacks to the nightmares I created in the early days, summing various quantities simultaneously in inner and outer loops and trying to keep them all in sync. The imperative approach is not clearer here. Had I learned to express what I was doing in a functional style, the odds are good that I would have escaped that quagmire much faster (and maybe even realized that what I was doing was not actually necessary for the program). I've heard it said before that object oriented programs let you use objects to model a problem. In my experience that has been a false promise. Objects create a layer in between you and the problem. Almost universally in programming, the problem is in the data: some input has to be turned into output. Functional programming is not short of ways to model that data and define transformations on it. What it avoids doing is handing the data off to a sovereign domain of control that might mutate it according to its own opaque rules. When functional programming works, it works because it links the program's input to its output in an unbroken chain. I have never seen anything comparable actually achieved in a Java program. When it comes to polymorphism, it seems like this potential strength of OOP is unavoidably tied to what I see as its greatest weakness, which is that objects are opaque to the caller of a method. If one is careful with side effects, I do see how polymorphism can help build reusable code. I'll just add that many functional programming languages use duck typing to accomplish the same thing. Instead of defining a class or interface that future implementations must extend, one defines the contract of a function in terms of what is true of its type. In this system, things can interoperate by virtue of their common traits, regardless of whether they share the same explicit interface or abstract class. Of course this idea does have its drawbacks as well.

Keeping code readable + maintainable to me is the hardest part no matter if you're using oop / functional paradigm. Good and bad code can be written in either they just help you out in different areas :)

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).