3 ms·

Yes, as I said, each individual piece (actor) is easy to understand, locally. But you cannot in general understand the global behavior of the system that way.

• lostcolony 11y ago
  And what I was saying is that in an immutable system, that's -usually enough-. It's not that difficult, because the reasons for messages being sent are predictable. You get a lot of emergent behavior in systems with mutable state that is avoided in systems that enforce immutable state, and without that it becomes far more tractable to trace back a series of events and reason about them. You got a message? Okay, who can send that message? If it's more than one, is there a reason why you aren't indicating -who- sent that message (in Erlang, including a pid as part of the message; this is done automatically any time you use a gen_server and send a synchronous message via call)? But regardless, what does that message mean? Is it the same across all senders? Because if so, your bug is in the implementation in this actor. If not, if the message means different things when sent from different places, you need to figure out what the different messages you want to send are, and send different messages for them. If you have mutable code, even mutable message passing, the time the message arrived changes what it does. Suddenly you have situations where the message being sent, and the behavior the actor exhibits, is dependent on mutable state. It's totally correct in some instances, and totally incorrect in others; completely dependent on what has happened in the system previously as to whether ~this~ particular message, with the coded behavior, does the right thing or not. And it's that, the interplay of all events that came before, that makes things complex.
  • platz 11y ago
    Yeah, I can see how adhering to nice principles leads to more predictable behavior in erlang. And clearly people do it which seems to back up the claim.