Meyer, OO and concurrency

[todd]

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.

>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.

>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.

>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 :-)