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

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

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

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

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.

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.

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

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.

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.

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.

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

You essentially described Erlang with that message passing example.

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.

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

The hardest part of reactive programming is convincing management, especially those who were once developers.

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