Bijan Parsia <bparsia at email.unc.edu> wrote:
	I was reflecting on the problems you discussed at various points of each
	class inventing syntax in Smalltalk-72, and wondered why it doesn't seem
	to be a problem in Erlang.

The answer is that one of the design rules in Erlang is
    HIDE THE PROTOCOL!

Typically, a process->process communication protocol is hidden inside
a module.  From the outside, you call functions to get things done,
and never see the protocol.  In effect, each class _does_ have its own
syntax, but that doesn't matter because other classes never see it.

There is of course one major difference between Erlang and Smalltalk-72,
which is that Erlang message-passing is rather like UDP (in fact, in at
least one Erlang implementation it _is_ UDP) so it's expected to fail from
time to time, and you __really__ don't want to mess around with the details
of a protocol that's designed to handle that.  Some protocols take the TCP
route of trying to build reliability in at a fairly low level, and of course
that is really best hidden.  (How many TCP users know about the three-way
handshake at the start, or the slow start mechanism, or the four-way
handshake at the end?  How many _need_ to know?)  The majority of Erlang
code seems to rely on higher level protocols for fault recovery; since
Erlang programs are supposed to keep on running when you start pulling
boards out of the hardware (I've seen it done) low-level protocols aren't
enough.

So the answers are
1. Encapsulation (no novelty in Smalltalk)
2. High level "behaviours" for fault-tolerance.

	That being said, I don't quite get all of the Smalltalk-72 model, though
	I'm diligently (for me) perusing the manual :)
	
Where is that?