“Tell, Don't Ask”: according to Pragmatic Programmers it is preferable in object oriented programming to “tell an object to do something rather than asking it for some data.” Michael Feathers believes that “this is a great piece of advice”, especially for larger systems:
Return values push work back on callers. It's not enough to do some work and decide to send a message to a collaborator; you have [to] wait for something to come back to you and then, perhaps, do some more work. We're better off not returning values.
According to Feathers, using mocks in test driven development results in this kind of architecture:
Rather then telling an object to do something and then asking whether it was done, you tell an object to do something and then see what happens to its collaborators. […]They are a bit like a workflow. […] There's less design impact under new requirements. And, it makes sense. Each object is responsible for doing one thing and notifying its successor.
One can go beyond this. Feathers argues that if there is no return value to wait for, it may be better to send “asynchronous messages send rather than synchronous messages”. H.S. Lahman has actually been arguing that in object oriented architecture “behavior is assumed to be asynchronous”. Today’s OOP model, however, is synchronous because in object oriented programming languages “message and method are not separated”. This makes it “more difficult to construct correct OOA/D models” that could significantly improve not only maintainability but also robustness.
This maps to the Erlang model as described by Michael Feathers:
The idea behind Erlang is that if you can make a large number of processes and guarantee that they never share state, you can develop more robust systems. Each process receives messages, does its work, and sends messages to other processes. The message sends are largely asynchronous.
According to Feathers, the “Tell, Don’t Ask” model of programming is “almost the opposite of functional programming” even though “both of them seem to have a relatively stateless substrate that data flows along”:
In the purest form of functional programming, you never tell; you ask. And when you have lazy evaluation, the system only does as much as it really needs to when it's answering your question.
Arguably, Erlang cannot be considered a purely functional language, as highlighted by Feathers referring to Ralph Johnson who has pointed out that Erlang is “OO in its core”.
In your opinion, which stateless model is the best for handling today’s adaptability and robustness issues: Erlang’s asynchronous message model or a pure functional programming approach (e.g. Haskell) ?