OO or FP easier for beginners

I strongly believe that functional programming is more “natural”. As someone with zero compsci background and taught themselves to program by flailing around with PHP 3 and 4 with no framework for guidance, I found myself creating different nested data structures to describe my state and, without knowing their names, wanting recursion and even some simple types of meta programming (I quickly discovered PHP allowed recursion and some very limited “metaprogramming” with “variable variables”). I already mentioned but after developing and thinking in these concepts, it took me an embarrassingly long time to understand OO (I don’t even wanna say, lol). So I believe that if functional concepts are the first thing you learn, there is absolutely nothing strange or hard about them—they are only strange and hard if you are used to a different way of doing things.

I’m assuming that functional didn’t prevail because for the longest time because it wasn’t that efficient as it would require literal copying of entire data structures in order to change them which was untenable for larger systems. I don’t know my language history that well, though.

I try to stay open in regards to classic OOP, because I have to write in it at my current job, however I don’t see in any way how this is a good way to write software, in any use-cases. I have learned patterns, architectures, all of them being very abstract about a implementation as they all are, everyone implementing them how they think is the right way, only adding more complexity to this pile of already complex code. Usually when I talk to people that have never written in FP code, they defend OOP, however I never seen anyone the other way around.

I think there are many more things in play when we talk about bad OOP, like side-effects, mutability, bad concurrency model, the all influence very much the style in witch OOP code is written.

The OO crowd will respond to this by saying it’s because we’re just wanting to stick with the “cool” thing and we’re secretly waiting for OO to be cool again so we can go back to it

This isn’t a problem unique (or even related) to OO. Really this is the problem of implicitness, which is just as present in Elixir’s import as it is in C’s #include, implicitness is one of those things that’s really nice when you write the code, but can be a PITA when you read the code Thankfully ctags and nowadays language servers, make finding function/method/identifier definitions relatively trivial.

That’s because the claimed OO languages with their classes and methods are imposters and not actually object oriented.

A famous Joe Armstrong quote seems apt:

The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.

Joe provides some pretty good definitons on this forum on why Erlang languages are the only real OO languages:

So I wouldn’t hate too hard on real object oriented programming as that is actually what Elixir on the BEAM is.

While this is all 100% true, when people say “OO” they almost always mean “classes and methods” which is certainly what I mean in this context!

Thanks for moving over the discussion, @benwilson512!

I can see that today the tooling probably makes it easier. LSPs weren’t the norm when I was learning to program, so you would have something like this:

# a.py
class A:
    def abc(self):
        self.thing = []

# b.py
from a import A

class B(A):
    def cde(self):
        self.do_stuff()

    def do_stuff(self):
        # etc etc

# c.py
from b import B

class C(B):
    def xyz(self):
        self.abc()

All in different files and with a lot more complexity. So I would ask the question of “where did the abc method come from?” and I knew enough to understand that it probably came from a parent class, but then I’d go up to the parent class and … surprise! it inherits from another class or maybe even multiple classes. Then it was juggling between different files trying to find where it came from. Sometimes I would search for it and never solve the mystery of where self.abc() came from. It was probably inherited from a class from some other library.

So yes, part of it is implicitness, but this is a sort of implicitness that was really hard to reason about. It wasn’t simply a matter of checking the imports. I don’t think the implicitness seen in Elixir is comparable. With most imports, you know exactly where something is coming from (and it’s very common to reference a module directly rather than importing it - I rarely do statements like import Enum, warn: false or import Enum, only: [map: 2]. You certainly don’t have a situation where a self.abc() can modify your %C{} struct without you explicitly assigning the value it returns to a new variable.

LSPs weren’t unless you learnt very recently, but your example situation, where there’s not an overridden method, is trivial for ctags, and if that wasn’t around when you were learning to program then (like me) you just used grep before riding home on your dinosaur.

I don’t see why you think the “checking the imports” is simple but “checking the base class(es)” isn’t, and re your point that with most imports you know exactly where something is coming from - I’d argue that with most inheritance/delegation you do too.

Your point about mutability is of course true and a significant difference, but nothing to do with knowing where methods are defined.

For me it’s about being easy, it’s about being disruptive to jump between files. Though I recently discovered a few keyboard shortcuts in NeoVim that allow you not only to jump to definition but to also jump after. Pretty nice!

Many of the efficiency issues of immutability were manageable as functional programming dates from the 1950’s.

I think OO was seen as something different offering some kind of promise of better software faster because it offered new concepts of “encapsulation”, “inheritence”, and “polymorphism” which were seen as a potential saviour to the industry.

This left “functional” most likely being seen as academic, mathematical, and potentially also conflated with the problems of that “evil” procedural “spaghetti code”, as superficially that a makes use of “functions” too right?

In the end, the “OO languages” created the “ravioli code” we have today and did not implement the actual definition of OO as described (or hoped) by Alan Kay.

The “OO languages” we have are non determinisitc (there is no guarantee to get the same output with the same inputs), and much harder to test.

One is left with a complex global graph of mutable object state tucked behind “methods”, with that state scattered to the wind in a single address space, with the execution model almost an afterthought.

With concurrency grafted on, you have a mess of threads, critical sections, mutex locks, semaphores and condition variables with many opportunities for deadlocks, no ability to actually clean up for every eventuality, as well as dealing with thundering herds of threads queuing up in the oddest of places (every mutex lock or critical section is actually an unintended queue).

How do you program defensively or even reason about it when the whole graph is a buzz with parallel changes and any thread could at any moment do a rug pull from under your feet? You use locks, and now any read on that graph of objects creates a stop work meeting and often results in a cascade of object interactions, more locks and even more deadlock potential. When considering exceptions none of the threads can actually cleanup properly in all circumstances, leaving a debris field and odd state in that global graph. It is all about coding the sad defensive path in this OO world, writing more code and doing less, but gee with static types you might catch some typos in the many times more code you must write but can’t adequately test.

There is also a runtime cost, shared data and locks actually lock the bus across CPU cores, and hurt cache effectiveness. We all know about “stop the world” GC and how that impacts the 99th percentile.

The BEAM avoids this hell.

As a recent prominent example of what “OO languages” beget, the Java crowd inflicted the log4j security vulnerability on the world which has cost companies in aggregate billions of dollars. What was the root cause you ask? A thread race condition due to fundamentally bad language design, a problem which goes like this:

The barman asks what they want.
Two threads walk into a bar.

The “OO languages” really are what Joe said, touch the banana and this sets off a cascade of side effects where the entire jungle moves.

The attack surface in the log4j vulnerability is vast and easy to exploit. Attacks like this essentially attack the fundamental issues at the core of most language designs that never considered the interplay of the language and processing model for concurrency together. I expect to see many more of these programming model attacks based on exploiting race conditions.

So how do you not end up with race conditions and deadlocks?

You avoid concurrency altogether in most languages and use heavy weight OS processes (often disguised as containers) to keep that state isolated within an OS process boundary and turn it into an operations problem.

Ultimately the truth of Erlang process model of concurrency and isolation prevails, albiet an impoverished analogue of it with many times the operational cost, recovery impact and recovery time when you do have a failure.

In my view the “OO languages” have proven to be a programming and operations tarpit. They looked like a nice shimmering sea of opportunity for a desperate software community, but like all tarpits once you’re deep in it, it’s hard to see a way out. Once you’re in the pit and “failing about”, the solution looks like “better tools”, and this attracts “investment” by tool vendors as there is good money prolonging a problem, which in turn attracts even more victims.

The “tools problem” compensates and hides bad language design which has increasingly been pushed into an operations domain with increased complexity though things like Kubernetes clusters for scalability and resilience of “OO language” programs. The burden of resilience and recovery disappears from the programmer and reappears in operations with orders of magnitude more cost. Those that don’t get Elixir, Erlang or the BEAM probably don’t understand the real problem. They don’t even perceive the problem to exist because of “best practices”, but the vendors and hosting provider do understand, and are waiting there smiling and ready to “help” ensure you consume as much as possible using “all of the best practice complexity you can afford” to retrospectively “solve it”.

Soon one needs to resource an ops team capable of maintaining the “cloud on cloud” cluster “service mesh”, etc, more technologies which no-one can all be experts in, but hey it’s all hipster and well “all the [OO] guys are doing it, Google loves Kubernetes, and RedHat loves OpenShift too”.

One of the red flags of a language/ecosystem that never solved the hard fundamental problems is that it ends up requiring a large set of disparate technology tools (footprint), and lots of people (layers of managers) to compensate for the operational problems it creates. These are usually “mainstream” technologies that generate a lot of revenue, and like lemmings corporates walk to their death willingly, because everyone else is doing it too.

This is where the significant competitive advantage of BEAM languages comes from to those that are savvy enough to understand and do actual risk management.
Less code, better testability, higher quality, low operational complexity and smaller technology footprint = less vendors and fewer SME’s needed to build understand and manage it.

Many decades on, some people are beginning to question their assumptions. This is why there are some significant examples that demonstrate success was no accident with services like, “WhatsApp”, “Discord”, “Pinterest”, and the UK health spine all using BEAM languages for competitive advantage.

I can posit that Jose probably reached a point working with Rails, that something had to change, there just had to be a better way… and thankfully he identified and built a solution and has been a huge mover in bringing the functional language paradigm and the true intent of OO into the mainstream, all by building on the shoulders of giants like Joe Armstrong who reasoned about and solved the fundamental problems that needed solving.

Alan Kay has said “Erlang might be the only object oriented language”. Coming from the person who defined “object oriented” I think that says it all, we have the best of both.