Erlang was indirectly influenced by CSP - but the major influences were Smalltalk and Prolog. Smalltalk talked about objects and of doing things by sending messages to objects (in fact message sending in smalltalk was not true message sending but syntactic sugar for a synchronous function call).
The first Erlang was a Prolog implementation of a Smalltalk message passing model of a telephony system.
I’d always liked the idea of messaging between parallel processes as a way of separating concerns and mainly because it was the only way I could think of to make things fault tolerant - I reasoned that if the entire machine crashed the computation would have to continue on a different (linked) machine - if you have two machines the only way they can communicate is via messaging - there is actually no such thing as shared memory in distributed systems (this is a programming abstraction that cannot be created) messages are really photons bouncing up and down in a fibre or changes in an electromagnetic field and they travel at most at the speed of light.
CSP assumes lock-step synchronous communication between a sender and receiver - if a sender emits a symbol ‘x’ and the receiver receives a symbol ‘x’ and they are in phase then we can step both the sender and the receiver. So with CSP you can prove things about protocols in an algebraic sence.
While I liked the CSP model (and notation) I didn’t like the assumptions of synchronicity.
It seems to me that you can either have:
a) A mathematically sound system where you can prove things - but you can never build since you break laws of physics.
or
b) A physically sound system that breaks no laws of physics, but which we cannot know the correctness of.
a) is CSP - we can prove CSP specifications to be sound but we cannot implement them since things like delivery of messages can never be proven.
b) is Erlang - we make no assumptions about message delivery other that what we observe. If we want to guarantee that a process has received a message we must add a unique tag and do a round trip and check we get the message back again. If the message does not come back we won’t know why - it might be a remote failure or a communication failure. We can’t prove that remote systems are alive NOW only make statements about the fact that we knew the remote system was alive the last time it told us.
Seems like there is a dichotomy - system building is a trade off between what we can build and what we can prove. We can build systems whoes properties we cannot prove - and we can prove properties about systems that we cannot build.
