COPL, the Tandem, PLITS and JAVA (WAS Re: Eppur si sugat)

[martin j logan]

"Why OO is less than sufficient for concurrent and fault tolerant
systems." The above title is not too interesting. "Why OO sucks" or "Why
OO is the worst thing since reality television" on the other hand are
titles that grabs peoples attention. A loaded, provocative title will
entice people to read an article. 

Please forgive me if I am being presumptuous but I think Joe's main
point is that much of OO doctrine, philosophy and current
implementations render the paradigm quite unsuitable for concurrent,
fault tolerant systems. No one will argue that OO techniques are useless
for say, a GUI, etc. The point is that if you are interested in
programming for the niche that Erlang currently occupies then OO
inherently sucks for your purposes and you should embrace the doctrines
described by "COPL", its forefathers, and influences. 

My couple of pennies,
Martin


On Wed, 2003-05-28 at 03:11, Joe Armstrong wrote:
> On Wed, 28 May 2003, Peter-Henry Mander wrote:
> 
> > A bit of dictionary hacking leads me to believe joe was alluding to 
> > Galilei; 'Eppur si muove' 'Still the Earth moves'
> > 
> > "And yet it still sucks!" == Eppur si sugat
> 
> Right on - I had great trouble with this.
> 
> It turns out (According to one source) that "Eppur si mnove" is not
> good 'ol Latin but is 15'th century Florentine Italian - I cannot confirm this
> (Francisco - help!!!!)
> 
> 
> I guessed that "muove" must be moves - so I needed the Latin
> for sucks.
> 
> I then typed "sucks latin" into google hoping to find a latin translation
> for "sucks" -
> 
>   This was a  mistake - goggle obligingly coughed  up several pages of
> references to young  latin ladies who sucked things  - the things being
> sucked were not lollipops - I say no more.
> 
> > 
> > Am I right? Everyone else seems or pretends to know exactly what Joe said!
> > 
> > As for the debate, it looks as if you are all fighting over how to 
> > formalise the OO "method." Joe, from the FP camp desires to see the 
> > formal definition of OO to enable comparison with the formal definition 
> > of any FP language. Such definition _does_not_exist_ for OO, because it 
> > has grown out of day-to-day experience and "best practices" of 
> > programmers in the trenches who don't necessarily have time or the 
> > inclination to write a thesis about how they get results.
> > 
> > OO is no more than a bunch of good recipes for hackers.
> > 
> > And like recipes, there's always more than one way to get similar 
> > results. This doesn't mean that they're bad. I get results using OO 
> > methods when digging my trench. Unfortunately some marketing bright 
> > spark came up with a "OOh!" to "Wow!" management, and the rest is 
> > history. In this world the best technical solution doesn't even win on 
> > merit, and I think Joe (and I) get upset because of that.
> > 
> 
>   This is precisely the reason why my latest ploy is to call Erlang
> a COPL.
> 
>   "Concurrency Oriented Programming" is  intended to be analogy of OOP
> - ie nobody  knows what  it is but  everybody recoginised a  COPL when
> they see one.
> 
>   The "thing" about Erlang (and about COPL) is
> 
> 	- Isolated processes
> 	- Pure message passing
> 
>   It is  just the  lack of isolation  that *prevents* Java  from being
> used for anything sensible.
> 
> <<quote>> 
> 
>   ... the  only safe way  to execute multiple applications  written in
> the  Java programming  language,  on the  same  computer is  to use  a
> separate JVM for  each of them, and execute each JVM  in a separate OS
> process.
> 
>   ...  In particular, the abstraction  of a process, offered by modern
> OSes, is thew  role module in terms of  features; isolation from other
> computations,  resources  accountability  and  control,  and  ease  of
> termination and resource reclamation.}
> 
> 
>   ...  tasks cannot directly share  objects, and that the only way for
> tasks  to  communicate  is  to  use  standard,  copying  communication
> mechanisms, ...
> 
>   -- Czajkowski and  Dayn\`{e}s In Multitasking  without comprimise: a
> virtual machine evolution, Proceedings of the OOPSLA '01 conference on
> Object Oriented Programming Systems Languages and Applications},
> 
> <</quote>>
> 
> The above quote is from two guys at Sun - amazing.
> 
>   Their  paper  says  basically  -   if  you  want  to  run  two  Java
> applications on the same machine you  have to fire up two JVMs and run
> each one as a separate OS process.  So despite the fact that Java is a
> "safe"  language  (with GC  etc)  you  still  need the  protection  as
> provided by OS processes.
> 
>   Despite  this fact  Java  is  still used  as  a systems  programming
> language --  amazing, since  *nobody* knows how  to run  multiple Java
> applications on  the same machine *without* protecting  them within OS
> processes (what  do you do, give  *every* programmer an  OS process to
> play in ... :-) - Until this problem is solved Java should not be used
> for systems  applications (it was, after all,  *designed* for applets,
> where it works well and the abstractions are appropriate) ...
> 
>   As  for  pure   message  passing  -  In  1978   PLITS  was  invented
> (Programming language  in the sky) -  this was a  pure message passing
> system  -  The  authors  of  PLITS argued  that  "complex  concurrency
> patterns"  and "shared  memory" was  no-no. They  thought  that shared
> memory models just didn't  work with complex concurrency pattern, they
> thought that programming such a system would be impossibly difficult.
> 
>   The  PLITS people  just  cared about  pure  message passing  between
> isolated processes - "communicating black boxes" they didn't even care
> about what  language was *inside*  the black box (this  is *precisely*
> the XML/SOAP philosophy of black boxes communicating via XML messages,
> or the UBF philosophy)
> 
>   Having introduced the idea of a COPL I talk about fault-tolerance.
> 
>   To  make a fault-tolerant  applications you  need TWO  computers AND
> they cannot share data (because If you only have one computer it might
> crash) - thus you need isolation and pure message passing.
> 
>   The basis of fault-tolerant computations rests upon three things:
> 
> 	a) isolation of components
> 	b) pure message passing
> 	c) stable storage
> 
>   a) the computers  must be isolated - if one  crashes the other must
> continue
> 
>   Since the computers are isolated, they can share no data, therefore
> the *only* way they can interact is by pure message passing (point b)
> 
>   c) stable storage is storage which survives a crash - you need this to
> recover *after* a crash has occurred.
> 
>   Now a) and b) are built into Erlang. c) can be achieved in a number
> of different  ways - mnesia, asynchronous replications,  etc. there are
> lots of ways of doing this.
> 
>   The  conclusion  of  all  this  is  that  if  you  want  to  make  a
> fault-tolerant system you *have* to get interested in COPLS.
> 
>   My current way of describing Erlang/OTP is saying that
> 
>   "it is a software emulation of the Tandem computer"
> 
>   Read Jim Gray's 1985 paper
> 
>   "Why do computers stop and what can be done about it?
> 
>   and you will immediately be struck by the similarity in the design of
> the Tandem and of the Erlang/OTP system.
> 
>   The Tandem  was for many  years (and possible  still is) one  of the
> best known architectures for making fault-tolerant systems -
> 
>   Incidentally, the tandem used "fail-fast  processors" the idea was it a
> failure occurs (ie an error which cannot be corrected) die as soon as
> possible - *exactly* the "let it crash philosophy" in Erlang.
> 
>   /Joe
> 
> 
> 
> 
> > Pete.
> > 
> > Chris Pressey wrote:
> > > On Tue, 27 May 2003 10:40:00 +0200 (CEST)
> > > Joe Armstrong <joe@REDACTED> wrote:
> > > 
> > > 
> > >>   Eppur si sugat (was that right?)
> > > 
> > > 
> > > (Not sure - Google just gave me a blank look when I tried it...)
> > > 
> > >
> > 
> > 
> > (interesting but marginally mathematical related stuff deleted.)
> > 
> > 
-- 
martin j logan <martin@REDACTED>