OO -> Actors (?)

Since the web has been established, networking and concurrency became central in most applications, like parrallelization is going to be with the multicore technology. However, OO seems not to be that well suited for either of both.

Why is OO not good for parrallelization?

Let’s say you have:
a := f()
b := g()
c := a + b
Simply put: how can you know if you can run f() and g() parrallely? You cannot tell directly. You have to know if f() or g(), and all resulting function calls, might at some moment modify a variable that the other uses or modify as well. In the latter case, parrallelization would lead to unpredictability and thus cannot be performed. Moreover, analyzing such dependencies is extremely difficult and breaks the principle of encapsulation.

And is OO good for networked applications?

Yes and no …At first sight it looks like yes but after some time it turns out it is not ideal. One issue is concurrency. When two requests come in at the time, it should be taken care that something being used by one is not modified by someone else at the same time. This leads to hard to investigate bugs and increased complexity due to synchronization. Another issue is that objects are not that well suited to model transactions.

Ok, so what now? Do you have anything better?

Object Orientation, combining data and methods acting upon them, is “today’s paradigm”. Now everything are objects, everyone “thinks” in terms of objects and OOP is “the way to go”. …But we should keep in mind it’s by all means not the sole way! And perhaps there are even better ways.

Two of the (compatible) models seeing some resurgence are the ones of functional programming and the actor model. I’ll skip the first one and directly go on speaking a little about the actor model.

What is an actor?

At first sight, both may look similar. However, they have profound differences. Conceptually, objects are just “dead” data with methods. On the opposite, actors are “alive” indepedent processes with transactional memory.

An actor is basically like a server. It receives and sends messages, and can also start/stop other agents. By  “transactional state”, we mean that state is associated to a “conversation”; not to the actor itself, as opposed to objects having a global shared state. As a consequence actors are free of concurrency issues.

So?

So transactions with asynchronous messages are naturally expressed and we have no more concurrency issues!

What can we model with actors?

Everything that follows the client/server architecture: I/O, networking, the X window system… 
In fact, anything interacting with the environment can nicely be modelled with actors, as well as intelligent agents, jobs running in parrallel, etc.

And this is even more natural! Indeed, when reading a file, a DB or whatrever: why sitting there and waiting for the answer? When these are seen as asynchronous requests, computation can go on until the response arrives.

…Sounds nice. Is there anything further?

Yes, this goes wonderfully hand in hand with functional programming. …But more on this later.