ReRe: why isolated components
Fri Aug 22 15:30:39 CEST 2003
I'm glad to have the answer I liked (and suspected) :).
> 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)
> 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
> > 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
> > 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?
> > 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.
> > 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
> > >
More information about the erlang-questions