Re: A path for CSP-based

[Andrew Cooke <andrew@xxxxxxxxxxxxxxx>]

I don't read every post to this group (by a long way), but I get the
impression people are discussing how to present/sell CSP.  It might be
helpful if I described my own experience - this is working for a small
company (when I heard of CSP there were just two of us doing coding).

As far as I and my co-worked were concerned, the introductory papers we
read (from Keele, I think) made a good, clear case.  We were both
impressed and enthusiastic about the approach.  
However, we already had a significant amount of Java code that used the
language's basic threading primitives and some of the simpler bits of
Doug Lee's library.  Changing our product (which is a collection of
sperate chunks of code, running on different machines, each containing
maybe a dozen threads typically, and conversing via simple HTML based
protocols) to use the CSP approach would have meant changing a lot of
code and learning a new bunch of skills.

Being a small startup(ish) company, development is iterative, reusing
much code, usually to short deadlines, and so there is no "clean break"
to start again.  At the same time, we got pretty good at writing
"traditional" threaded code (it's like using C again - dangerous,
requiring a disciplined approach, but a refreshing mental work-out :-). 
So have our own patterns that work reliably for us.

So I don't think the problem is presentation or the lack of a good idea;
it's just the usual inertia and the fact that, with some experience,
"traditional" threading is not *that* bad...  Of course, other scenarios
may demonstrate other priorities.

Sorry if this is completely off-thread - had ten mins to kill (maybe it
would have been better spent recoding something with the CSP libs :-)

Andrew


"B.M. Cook" wrote:
> 
> All,
> 
> > I know we have to fight against the fact that "component" has already
> > been appropriated by the OO crowd, but their component requires giant
> > centralized information structures to be identical and can't just be
> > plugged in like a new alternator in a car.
> 
> Personally, I distinguish them by remembering that the CSP/occam approach
> uses "Active Objects" and "Active Components" rather than the passive things
> currently called OO. The clearest presentations that I've heard on the
> differences are given by Peter Welch, anyone who has heard these will be
> very aware how much better the CSP view is.
> 
>            Barry.