ReRe: why isolated components

[Joe Armstrong]

On Fri, 22 Aug 2003, Laszlo Varga wrote:

> Hello,
> thanks for the "answer". Right, isolation reduces the (possible) complexity,
> but is that the motivation for the wrapper project? For coping with complexity
> we have several other isolation technics, like namespace, functions, or 
> objects. Part of the mail thread showes that the main motivation is to cope
> with the "dynamic complexity". (Reduing the number of states, I mean).
> Other reflections say that it is for robustness.

  When  I  use  the  world  isolation  I'm thinking  of  the  kind  of
protection domains offered by processes.

  Two components  running on two different computers  in two different
countries are isolated :-)

  Namespaces are a different kind of isolation.

> 
> Other benefits that not mentioned are the reusability, the cooperation of
> programmers, the testabilty, and ....
> 
> I guess that everybody who started programming knows these benefits in general.
> There are many tools and paradigmas to support this idea.
> But now, people seems to start thinking something new,
> and I wanted to provocate them to try to be precise at the start.
> I know well that it is hard. But also had bad experience when ommited
> this hard phase.
> 
> 
> So what we (Joe) want?
> 
> Robust system?

  Yes

> Real time system?
> Open system?
> Replacing CORBA.
> Supervised components?
> Standardised components?
> ???
> ???
> ???
> 
> All of them?

Not yet.

In the old days the great masters said:

  "get it right before you make it fast" - IMHO the "getting it right"
bit is the difficult bit (VERY  difficult) - making it fast once it is
right in much easier.

  Unfortunately, virtually every (or possibly it is every) system only
gets things almost right and  customers have been lead to believe that
fast flashy  software that crashes now  and then looses  their work is
preferable to simpler and more reliable things.

My view is that 

	1) We should construct systems from isolated components
	2) The systems should communicate with asynchronous messages
	3) The sequencing and types of these messages should be governed
	   by contracts
	4) The contracts should be checked dynamically and all the time

	  Read www.sics.se/~jeo/ubf for more details

  We should also aim to improve the isolation bit - ie make Erlang etc
better to avoid malicious inter-process denial of service attacks.
 
  Once we have done 1) - 4)  in a realistic system we will have got to
the "get  it right"  toll-gate. Then we  can start thinking  about the
"make it fast" bit and some of the other issues you addresses.

  /Joe


> 

> Cheers
> Laszlo
> -------joachim.durchholz wrote------------------------
> > Laszlo Varga wrote:
> > > Really, why?
> > > What are the (main) motivations for kind a system?
> > 
> > Let me rephrase, in the hopes that I understood your question correctly:
> > What is the main motivation for isolating components?
> > 
> > The answer is simple. If you double the number of names in a program, 
> > the number of unwanted possible interaction quadruples. More generally, 
> > for N items, you have N*(N-1)/2 possible interactions.
> > 
> > The number of *intended* interactions between components grows roughly 
> > linearly (I think it's usually on the order of N*log(N), but whether 
> > it's really linear or not doesn't matter: the main point is that the 
> > number of wanted interactions is massively less than O(N*N)).
> > 
> > In other words, the number of unwanted potential interactions grows in 
> > an approximately quadradic correlation with program size.
> > 
> > To keep the number of potential interactions down, Parnas propagated 
> > "information hiding", cutting down on the number of interactions that a 
> > compiler will allow. (Information hiding is not intended to prevent 
> > programmers from looking into components, its for preventing components 
> > from looking into other components.)
> > 
> > Just my thoughts on the subject.
> > HTH
> > Jo
> > 
>