Re: A path for CSP-based

[Andrew Cooke <andrew@xxxxxxxxxxxxxxx>]

You're right, but it's got to the point where most bugs are not thread
related, so priorities lie elsewhere (the (time) cost of getting the
libraries, reading the docs again, talking with coworkers (more now)
about it seems too much - which introduces another problem, getting
motivated about something enough to do it, when there are other
competing demands on time).

You could paraphrase me as saying the problem is that I simply don't
care enough, but I think that's slightly unfair - now that we have code
that works, the gains from CSP don't seem that much (as I said before,
the basic threading stuff isn't *that* bad, once you're experienced with
it).  Logically I'm sure the long term cost would outweight the short
term gain, but there are so many other competing short term costs in my
(professional!) life that it's not likely to be any time soon.

Hmm.  I typed (and then deleted) "my manager is only going to accept one
or two changes to the way we do things at any one time" - that got me
thinking that maybe presentation is the problem, but for him, not me. 
But then I realised that's not true - CSP could be one of the changes I
think are worth "fighting" over (persuading, reverse psychology,
blackmail, whatever), but there really are other more pressing problems.

Remember - this is from someone who liked the concept so much he's
stayed listening to the newsgroup for a year or two: if I'm the "good
guy", what chance have you got of persuading others...?

So: unless you get in at the start, the (perhaps apparently
insignificant) costs of transferring are simply too high.  In an ideal
world CSP would be a nice refinement to our development process, but at
the moment there are more pressing needs.  Perhaps that is worth
remembering - you're not introducing CSP to people who have nothing to
do all day, but to people who already have a stack of good ideas that
need trying out when there's time available.  Busy busy busy.  So no
more emails from me ;-)

Sorry, a bit rambling and circular,
Andrew

Richard Beton wrote:
[...]
> Perhaps if Andrew will fogive me for offering unsolicited advice, it would be
> this: take a divide and conquer route, rather than a big bang. If your Java
> systems have meaningful dataflow decompositions at a coarse-grained level (and
> which large systems don't?), then you can apply JCSP or CTJ at that level
> initially. Wherever there is a benefit, rewrite to increasingly fine-grained
> decomposition using JCSP or CTJ.