Meyer, OO and concurrency

[Joe Armstrong (AL/EAB)]

Todd wrote

> Peter-Henry Mander wrote:
> 
> >I ask myself *why* has it taken soooo long to recognise the need for
> >concurrency? 
> >
> You've always been able to do concurrency, so maybe it wasn't 
> seen as a 
> dramatic need. I never did. I could always add it. I was 
> happy that Java 
> had concurrency until I saw how broken it was.

Why has it taken so long? - answer: because people things that concurrent programming is
difficult - and because in the languages to which they have been exposed
concurrent programming is extremely difficult.


Anyway, you haven't "always been able to do concurrency" - Let me try the
following argument on you.

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

*Very few languages do concurrency* - in the sense that it is natural and easy to use
and that there are not arbitrary restrictions on how you use processes etc.

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.

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. 

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.

/Joe
    


> 
> And don't forget you still have a lot of people, especially 
> in the agile 
> keep it simple camp, that say concurrency is an unecessary 
> complexity. 
> The exact opposite of seeing concurrency as a fundamental building 
> block. They have, of course, thrown the baby out with the bath water, 
> but the attitude is common.
> 
> 
>