[erlang-questions] Please criticise these principles

[Richard A. O'Keefe]

Joe Armstrong replied to my request for criticism.
>>
>> 2.  No distinction between indistinguishables.
>>
>>    A specification shall not mandate distinct responses
>>    to situations that user programs cannot distinguish.

>>
> Impossible. Suppose Pid is on a remote machine. You cannot distiguish
> communication failure, with machine failure. So you cannot implement  
> this.

There is one fundamental difference between what you were thinking of
when implementing Erlang and what the ISO DTR authors were thinking of
when they came up with their design.

You were thinking "I have to implement distributed concurrent systems.
What kind of language would give me a fighting chance at getting such
programs right (or right _enough_)?"

They were thinking "How can we adapt the model of multiple threads in
a single address space to Prolog".  It is an _essential_ characteristic
of the ISO DTR that it is not and cannot (without major hassle) be
distributed.  It probably never occurred to the authors that a
concurrent Prolog-like language *could* be distributed over a cluster
or NOW just as easily as running in a single UNIX or Windows process.
I suspect they were thinking of "distribution" as "a problem solved
by sockets" and "concurrency" as a separate "problem solved by threads".

>> 4.  No unprotected shared mutable variables.
>>
>>    While some thread has the power to write a variable,
>>    it is VERIFIED that no other thread has the power to
>>    read or write that variable.
>
> I have always thought that there should not be shared variables AT  
> ALL.

Of course I agree.  In fact that principle is a little sneaky.  It's
such an obvious thing to agree to (and it is basic to the way
Concurrent Pascal, Ada, and Occam work) that I hoped people would
agree before they realised that banning shared variables entirely is
by far the easiest way to do the verification in Prolog.
>
> Erlang programmers have happlily been writing distributed and
> concurrent programs
> for twenty years without the use of mutexes - they are just NOT  
> needed.

When I was writing that message, I was trying to figure out a way
to work the phrase "astonished delight" into it, as in

	"When you consider with what astonished delight programmers
	 have found that concurrent programming in Erlang and Haskell
	 are easier than they imagined possible, it would be a great
	 shame for Prolog to adopt an approach famed for the opposite."

I'm also of the view that if you have possibly unreliable components
co-operating on shared data of some sort (such as a data base) you
will find yourself wanting transactions sooner or later.  It will be
interesting to see how the new Sun machines work out (if only rich
old Uncle Nemo would order me one for Christmas; to bad I have no
rich old Uncle Nemo) with their hardware support for STM.
>
> Concurrency isn't a "nice layer over pthreads" - the most important  
> thing
> is isolation - anything that mucks up isolation is a mistake.

That needs to go in the list, I think.
Somewhere near the top.

--
If stupidity were a crime, who'd 'scape hanging?