ReRe: why isolated components

[Laszlo Varga]

Hello,
I'm glad to have the answer I liked (and suspected) :).
/Laszlo

> X-Authentication-Warning: enfield.sics.se: joe owned process doing -bs
> Date: Fri, 22 Aug 2003 14:57:29 +0200 (CEST)
> From: Joe Armstrong <joe@REDACTED>
> To: Laszlo Varga <Laszlo.Varga@REDACTED>
> cc: joachim.durchholz@REDACTED, <erlang-questions@REDACTED>
> Subject: Re: ReRe: why isolated components
> MIME-Version: 1.0
> X-OriginalArrivalTime: 22 Aug 2003 13:04:45.0895 (UTC) 
FILETIME=[F5CC6570:01C368AD]
> 
> 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
> > > 
> > 
>