On Thursday 25 October 2001 10:54 pm, you wrote:
> That is interesting.  I think it's perfectly reasonable to expect an OO
> language to offer good support for concurrency.  It's a natural way to
> model a problem...which is different than actually thinking in parallel.
> The trouble is that it's easy to provide nice concurrency abstractions,
> but it's a whole a different affair to make those abstractions work
> without introducing all sorts of concurrency related bugs.
>
> I've found that programmers that have worked for years with languages
> that have little or no support for concurrency (like C for instance)
> tend to solve problems sequentially (and even go to very extreme lengths
> to keep the solution sequential!).  On the other hand, programmers that
> may have started with environments like Smalltalk (where they can be
> exposed to multi-processing earlier in their programming career), tend
> to be more aware of multi-processing and how it can be used in modeling
> a problem.  Part of the problem is that multi-processing has
> traditionally been seen as something that the operating system (or web
> server these days) does and not viewed as a programming language
> construct.
>
> - Stephen

	I agree, languages that make multi-processing hard to use cause people not 
to use that feature... ;)

	Which is why modern languages should have more support for such features. 
Easy support.

	Not the silliness of writing threads in C, or even java, but a good way to 
handle all such cases.

	Daniel