Joe Is Wrong (2009)

I'm a recent FP convert after 15ish years of OO. I don't hate OO now or anything, but maybe a little? It adds so much more to think about for what I now consider to be no benefit, at least for the types of systems I've worked on in my career. A big thing I've realized is that everything I've worked on has modelled things that are already abstract. For example, I'm working on a scheduling app right now. In real life, a schedule is an abstract concept realized on paper. Our app certainly doesn't have a Paper class. That may seem knit-picky to some people but it's true: the whole "model the real world" breaks down there. My apps also always have way more behaviour than they do things. FP is much easier to model a lot of behaviour around a generally fixed set of things than OO is.

This is not to say there aren't good use-cases for OO (video games come to mind) but for my day-to-tasks, I've found FP much simpler (and immutability is a god-send... it's like, "Hey, you know that foot gun you've been carrying around? You don't need that anymore!"). I would encourage any OO zealots to give FP a honest try.

There are now Top level statements in C# 9.

- https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/tut...

> Top-level statements enable you to avoid the extra ceremony required by placing your program's entry point in a static method in a class.

After many years of a lot of OOP, many people have realized, that putting behavior and state together into one entity might not be a good idea. We can see modern languages moving away from such practices. For example in Clojure one has defmethod, which defined a method separately. In Rust one has structs and implements traits for them separately. In some languages OO systems are libraries, which are optional, opt-in, not part of the core language. Think GOOPS and CLOS. Usually those languages define functions for data structures separately and you will have something like vector-length.

So it seems wisdom is slowly sinking in and we are progressing away from bundling state and behavior together.

Why is this done? For example to avoid having to subclass loads of stuff. For example in Rust one uses composition over inheritance and one can add behavior later by implementing traits, that make use of the parts of the structs. This way one does not need to subclass everything to add a new behavior. Similar for defmethod in Clojure. With Erlang this is raised to a whole new level, by defining the behavior in separate actors, which process messages, which are the data, which travel around without the behavior part. Overall it makes it possible to actually have encapsulation. A similar thing happens when we leave the boundaries of one machine and look at the web and REST, where we basically pass messages, conceptually similar to what happens between actors. For details about how encapsulation is broken in mainstream OOP read the article "Goodbye, Object Oriented Programming" by Charles Scalfani: https://medium.com/@cscalfani/goodbye-object-oriented-progra... (Sorry for the medium link. Does anyone know a better link?)

Next I'll address some things in the article, which I see problematic and questionable.

> Putting them together creates a boundary around this group of data and functions - encapsulation. Sure, you may call that a “module” but an object is IMHO slightly different since objects have identity, a life cycle and we can hold them, send them around etc.

That is not, what a module usually is. A module usually groups things, which are independent from each other, but are used in the same context. For example a module could contain a definition of a math functions. It does not track state or data. It might contain data structure _definitions_, but not their instances. A module is not a class or object replacement.

> So in some sense objects can probably be viewed as modules but often more fine granular. And we can combine such “modules” into larger modules (since objects have identity and can be referenced etc) and we can create and kill them dynamically (life cycle).

See above for the differences of objects and modules. It is not about being "more fine granular". It is different in character and should be used in different scenarios.

Joe himself once said on stage (it was a video with him and Kay on stage, not sure of the name), that Erlang is either the most OOP lang or the least. I think he meant, that it depends on what OOP you look at. If you look at Smalltalk and message passing, as Kay highlights as the prominent ideas, then it might be the most OOP (or somewhere close to), while it is a 180 from mainstream OOP, when we look at the actor system and how distributed systems work.

Modularity in imperative programming is ad hoc. It's not part of the paradigm itself like in modern functional programming, or object-based programming with interfaces and composition.