Object-oriented programming: Some history, and challenges for the next 50 years [pdf]

People disagree widely on what OOP really is/means. I've read and been in many definition debates. Even defining what inheritance, polymorphism, and encapsulation is, is also a can of worms.

Have a look at the paper. It's actually one of its conclusions that Simula had active objects even in 1961 and also in the OO version 1967, but for some reason this aspect didn't make it into the concept generally envisioned by OO today.

> I think Alan Kay himself has suggested that what he really wanted when thinking of OOP was something more akin to the Actor model as espoused by Hewitt and realised by Erlang and to a lesser extent Scala on the JVM.

> This model gives full benefit of FP at the actor level whilst being realistic about distributed messaging semantics.

It's interesting you bring that up; I normally am very much on the 'Use interfaces and Dependency injection instead of inheritance' camp. And yet, When I work with Actor Model frameworks (Mostly Akka/Akka.Net) I find places where using some simple inheritance is insanely powerful yet intuitive. You wind up getting something in-between OOP and AOP with the results.

I think so too. FP does not work over a distributed system, because it requires to view "the world" in one chunk. But that does not scale.

Using actors is a great way to chunk the worlds into smaller parts, each of which can then be handled in fully FP manner.

It is also to note that features like closures and LINQ-like operations were already available in Smalltalk-80, which tend to be the most FP features used by average enterprise joe/jane developer.

That's a very interesting observation, that is very much aligned with my own views, but I'll need some time to absorb the details here.

I'm myself on the quest to fully understand what is really wrong with OOP and then try to share it with more people. It's actually very hard because it's a complex topic, ridden with subtleties, and even the exact definition of "what is OOP-code" is elusive. I've just recently made a reddit post that you (and other's who find your post interesting) might also enjoy: https://www.reddit.com/r/rust/comments/ju5oqp/how_to_avoid_r...

I wish there was some "OOP-deniers" community, where we could discuss things like that with an open mindset. Usually discussing OOP degenerates quickly and it's impossible to even establish some shared understanding.

> his combination of data and code in a strict hierarchy means that all data access patterns are baked into this dependency tree

I believe OOP is really good at modelling state and really bad at modelling data.

With state (and side-effects modeled by state machines) you want a well-defined interface, messages, local retention and so on. This way you get the benefit of reasoning about state in a constrained manner both as the caller and the callee.

For example it makes sense to model Mario as a state-machine that receives messages from game-pad (pressed buttons) and collision events. Note that this is a conceptual, high level kind of modelling and not a concrete, structural one.

But data is about something. There is data about Mario at any given point in time: his physical dimensions, his velocity, consumed power ups and so on.

This is where OOP makes no sense at all. Reading and transforming data should be universal/uniform rather than guarded by idiosyncratic getters, setters and so on.

This is why SQL, JSON, XML, HTML, Unix filters, AWK, Functional Programming etc. are so powerful. These technologies provide/enable a uniform/universal way of reading data and composing transformations.

(As a side-note: I consider state that never leaks as an implementation detail, usually for performance)

I think adhering to the Solid principles prevents those problems. Single-responsibility should prevent two things working on the same data, dependencies should only point to abstractions and if you feel that a class hierarchy is hard to change favor composition over inheritance.

I believe languages should allow the programmer to define the relationship between one code block and another. This includes scope and state relationship. Think more powerful lambdas with better interface syntax and options. OOP languages typically hard-wire such relationships into a limited set of relationship conventions. This results in OOP graphs that don't fit the domain or need well.

Sure, one can do such in Lisp, but many find Lisp hard to read. With C-style languages, the "ugly" syntax gives helpful visual cues. Stuff within (...) is usually a parameter list, stuff within {...} is usually sequential code, and "[...]" indicates indexing of some kind, for example. I find such helps my mind digest code faster.

Lisp aficionados will often claim "one gets used to" the uniformity. But that's like arguing we don't need color because one can "get used to" seeing in black and white. To a degree, yes, but the color adds another dimension of info. Easily recognizable group/block types is another color.

The reasoning behind "closures", is that one can capture some context such as the example you describe. If we think of an object as simply a record of functions, then we can close over some shared context during the construction of such records, if we have a language with records and closures.

Yes, it's called a closure.

Look up the Reader monad. Don't be intimidated by the M word, it's a simple pattern which make use of function arguments but masks the argument drilling.

Others have mentioned closures; there are also a few other patterns that can do similar things.

One is "ad-hoc polymorphism", which lets us associate values with types. This is essentially the same as implementing an interface in languages like Java, except we don't need to modify any existing definitions (e.g. we don't need to edit a class to say "extends Foo"). This is useful for picking between pre-defined sets of values, e.g. for your example of logger and base dir we can define an interface like 'Environment' with methods returning a base dir and a logger; then we can define a 'Production' type which implements this interface by providing the real logger and base dir, a 'Test' type which returns a temp dir and stdout logger, a 'Dev' type whose logger keeps verbose debug messages, etc. We can write our code in terms of a generic Environment, then in our 'main' function we specify that we're using 'Production'; in our test suite we specify that it's 'Test'; when debugging we can specify 'Dev'.

Another approach is called 'Reader', and it's based around the following type and helper functions (in Haskell syntax):

    data Reader a b = R (a -> b)

    read :: Reader a a
    read = R (\x -> x)

    runReader :: Reader a b -> a -> b
    runReader (R f) x = f x

Or in Scala:

    final class Reader[A, B](f: A => B) {
      def run(x: A): B = f(x)
    }

    final object Reader {
      def read[A]: Reader[A, A] = new Reader(x => x)
    }

Note that this type literally just contains functions from some type A to another type B. The function 'read' is a wrapped-up identity function (returning its argument unchanged), the 'run' function just applies a wrapped-up function to an argument.

This gets interesting if we do two things. First we can specialise the input type (a or A), e.g. in Haskell:

    type Application t = Reader (Path, Logger)

Or in Scala:

    type Application[T] = Reader[(Path, Logger), T]

The type 'Application[T]' represents functions from a Path+Logger pair to a T.

Next we can define some functions for manipulating Reader values:

    -- Applies a function f to a Reader's result; AKA function composition 
    map :: (a -> b) -> Reader t a -> Reader t b
    map f (R r) = R (\x -> f (r x))

    -- Wrap up a value into a Reader, by accepting an argument and ignoring it
    wrap :: a -> Reader t a
    wrap x = R (\y -> x)

    -- Combine two Readers, so they're given the same argument and their return values are paired
    product :: Reader t a -> Reader t b -> Reader t (a, b)
    product (R f) (R g) = R (\x -> (f x, g x))

    -- "Unwrap" nested Readers, by passing the argument into the result
    join :: Reader t (Reader t a) -> Reader t a
    join (R f) = R (\x -> runReader (f x) x)

Together these functions let us write arbitrary functions "inside" this 'Application' type. For example:

    -- The 'fst' function gets the first element of a pair
    baseDir :: Application Path
    baseDir = map fst read

    -- The 'snd' function gets the second element of a pair
    logger :: Application Logger
    logger :: map snd read

    -- Use the logger to log the given string (via some 'logWith' function)
    log :: String -> Application ()
    log msg = map (\l -> logWith l msg) logger

    -- Read the contents of a given file from the base dir
    openFile :: Filename -> Application String
    openFile f = map (\d -> readContents (d + "/" + f)) baseDir

    -- Log the contents of a given file from the base dir
    logContents :: Filename -> Application ()
    logContents f = join (map log (openFile f))

Note how we can only access the base dir and logger from 'inside' the Application type; i.e. we can get an 'Application Logger', but we can never just get a 'Logger'. That's because the code doesn't actually define a logger or base dir anywhere; any value 'Application T' is really just a function '(Logger, Path) -> T'. To extract a result, we need to give it to 'runReader', which (in the case of Application) also needs to be given a '(Logger, Path)' pair.

Using these functions directly can be a bit tedious. Some FP languages have special syntax which makes it nicer, e.g. in Haskell we can write things like:

    do x <- foo
       y <- bar x
       baz x y

The Scala equivalent is:

    for {
      x <- foo
      y <- bar(x)
      z <- baz(x, y)
    } yield z

These get rewritten to (the equivalent of):

    join (join ((map (\x -> map (baz x) (bar x)) foo))

This API is a combination of Functor (map), Applicative (wrap and product) and Monad (join). Hence people sometimes call this "the Reader monad"; but don't let that scare you!

Nonetheless, Erlang is closer to the original OO as implemented by Smalltalk than C++ or Java.

Just to set some context, I'm of the "OOP Generation" where I learned to program when OOP was at its zenith. Every major language was Class-based OOP (C++, C#, Java, Python, Ruby) and it was just THE way to code for all things in the foreseeable future.

That said, I've since looked into and learned other methods of programming: classic C, prototype-based JS, functional Clojure, and Go.

From what I can gather, even from the SOLID principles and other Class-based OOP advice (prefer composition over inheritence) is that Interfaces (as abstraction and reuse), Aggregation (that objects can have other objects), and Delegation (which allows of ergonomic aggregation) are the real winners of OOP.

In this way, Go gets it mostly right IMO, though at the risk of "initial hype" I'm still cautious on it.

It feels so backward that OOP is taught with a focus on abstract & subclasses, with very little emphasis on interfaces, which is really how we achieve the goals of abstraction and reuse.

What's funny is seeing languages like Java trying to "undo" the arguable "mistake" of abstract classes by adding more and more power into interfaces: default methods, etc.

To your original conversation, there's a mix going on with "model." Are they talking about the Service's API Model, the internal model representation, or the database model? The outer layers (API & Database) of your code should be plain structs (POJOs in Java), but you're absolutely right that within the business code itself, you should have logic within the classes. Otherwise, you're not coding much different than C passing around struct pointers.

Related terms: MVC, Data access object

There is no relation to the paper. Recommend that you first take a look at it.

It is better not to put business logic into data model - in order to:

1) Keep your business logic simpler.

2) Keep your data model simpler.

If you put both business logic and data model in the same class, then:

- When you investigate data references pointing to your class -- you will see references noise from your business logic.

- When you investigate business logic references pointing to your class -- you will see references noise from your data model.

3) Combined "business logic + data model" class is much harder to refactor.

So, technically, you can combine business logic and data model in the same class.

But practically, such code combining will significantly complicate maintainability of your code.

The paper is from 2012, and it is not actually about research results, but a historical outline, even with a few errors. But still interesting to read.