You setup this great analogy about messages and cells and a bunch of other stuff, but then exceptions and pointers/references show up and everything falls apart

You setup this great analogy about messages and cells and a bunch of other stuff, but then exceptions and pointers/references show up and everything falls apart. If you have a system like ruby or java or c# then you can sort of pretend that you have different "organisms" all sending signals to each other. However, if your throw an exception at any one place, suddenly what order the functions you are simulating your message calls with WILL determine the semantics of your program. Have fun figuring things out when the order changes based on minor details that change wildly with different inputs. In this scenario if methods are messages, then exceptions are like a false vacuum in quantum mechanics collapsing and destroying reality. [Additionally, you'll need some sort of threading and message queue system setup or else you'll get a similar mess with your metaphor OR stack overflow. Really erlang is the only system that preserves the metaphor without the programmer either having to A) understand everything without the metaphor ... in which case why have it or B) not understand anything and only be able to program until they hit the threshold of their comprehension and then type random letters and hope it runs until they can find a new job.] Pointers are also a problem. In real life we have ownership types build into reality. If I have something, then you don't. You also don't have to worry about cyclical references or infinite recursion in reality. Eventually all of the physical resources are utilized and you have to wait for something to free up before you can proceed. Once you have pointers, though, you have to worry about one "cell" possessing another "cell" that just happens to possess the first "cell". A system that works just fine in real life (because paradoxical systems just can't be physically built) gives way to a system that will hopelessly break UNLESS the programmers know that the metaphor is false and can see through it. We run into the same problem as before. Either they can work just fine without it (so why are we using it) OR they can't see through it at all (or only partially) and eventually they'll run into a problem that they can't solve. Maybe there are scenarios where it makes sense to use an incomplete metaphor that pretty much has to break sometime. But it seems like it's going to be for unimportant work that we're comfortable with breaking with no good path forward for fixing it (besides to find people who can see through the metaphor completely).