Meyer, OO and concurrency

[Joe Armstrong (AL/EAB)]

> 
> Joe Armstrong (AL/EAB) wrote:
> 
> >Suppose there was an OO language called K. K "does" objects.
> >
> >In K you can use objects freely - but subject to the 
> following restrictions:
> >
> >	- you should try to use less than say 2000 objects
> >	- if you use more than 20000 objects your program will crash
> >	- instead of destroying objects and creating new ones 
> you should try
> >	  to keep a pool of old objects and reuse them as often 
> as possible
> >	- you should try and keep the total number of objects 
> down because
> >	  programs with lots of objects are difficult to write 
> and understand and debug
> >
> >Now of course, "K does objects" - but not in any *useful* 
> sense - and even if it does
> >objects - the programming style is so warped that nobody 
> wants to *use* objects as a method for structuring their programs.
> >
> >Now replace K by {Java, C++, C#, ...} and the word "object" 
> by "process" :-)
> >  
> >
> I won't argue that "good" native support is not better, but 
> the analogy 
> doesn't apply. How many threads do I really need? I need as many as I 
> have actual concurrent activities. Even then it's OK for 
> activities to 
> block. So I don't need thousands of threads for good effect. I can 
> activate passivate objects or I can have enough RAM.

But our telcoms apps do need lots of processes - say 100,000 subscribers
with a call model that needs 6 process/call = 600,000 processes ... 


> 
> >Concurrent algorithms often provide a "natural" way to 
> describe things (especially for
> >real-world programs - since the real world IS concurrent) - 
> a sub-set of concurrent programming is sequential programming 
> (but the converse is not true) - so in this sense
> >concurrent programming beats sequential programming hands down.
> >  
> >
> Having had these conversations many times with embedded programmers, 
> they just think a shared piece of data protected by a lock 
> makes sense, 
> even if they become mystefied when it all comes crashing down around 
> them. Sending someone a paper on pi calculus is next to worthless.
> 

Erlang is not the Pi calculus - it's a programming langage that's easy to use.
Don't show them the theory - give them the code that does the job :-)


> >The reason why concurrent programming has got a bad name and 
> a reputation
> >of being difficult  has to do with the threads, locks, 
> mutexes, critical regions, 
> >shared memory school of programming. 
> >  
> >
> I'd also point out that ericsson doesn't program their entire telecom 
> devices in erlang. That shows there is
> a weakness and it turns people off.

I don't think so. My banks uses Cobol (a lot) and C (a little) applying your argument would mean that C was weak ... 

The reason that Ericsson does not use Erlang for "their entire telecom devices"
has nothing to do with the the merits of Erlang and everything do do with the failure
of competing technologies.

The big Erlang success story (AXD) came about when the "conventional" way of doing things failed. At the time Erlang was chosen for the AXD because all the alternative
(conventional) methods had failed - it was not chosen becausen it was the only thing that worked.

It's pretty clear that the best software technologies are rarely used
in industry - old crap technology are extremely "sticky" and not easily replaced.



> >The non-shared memory, pure copying asynchronous message 
> passing, paradigm is
> >far easier to program (witness all the web applications, 
> virtually all use
> >non-shared memory (ie separated processors) and pure message 
> passing (defined by RFC's))
> >and very easy to understand.
> >  
> >
> And for scalability simply add clusters, replicated web tiers, 
> replicated datababase backends, and L4-L7 redirectors :-)
> 

Absolutly - "go parallel young man"

/Joe

>