Re: You must read this

[Christopher C R Jones <ccrj@xxxxxxxxxxxxxxxx>]

Dear Peter,

I was very interested to read your response to this Brinch Hansen
reference.  I was also interested to note in his e-mail with 17
references, all to his own work(!), that he comments on his lack of
reading on parallel issues(!)  This will rather preclude the "standing
on the shoulders of giants".

What particularly caught my eye from phw was:

"Second - gloom!  Yet again, the whole technical, commercial and
academic development of occam has been as though it never
happened. "

and

"Those principles are the foundation of the engineering that went
into occam and, by 1991, although the owners of occam may have
lost that understanding, there was a vigorous community of users -
including industrial users - that hadn't!  And we're still here.
Somehow, we've become invisible ... we speak and show and teach
... but nobody, not even Brinch Hansen, can see us?  Was it
something we ate???"

I was recently at a meeting to discuss a proposal destined for the
EC's 5th Framework.  It concerned some software development,
which must be designed for parallel operation - are there any non-
parallel supercomputers still in use?  Being very concerned about
the achievability and maintainability of the product of this
proposal, I suggested bringing into the list of contributors, a
member with specific parallel computing knowledge, and further,
that recognising the difficulty of integrating the whole for parallel
operation, we should consider the use of some more formal analysis
using CSP.  I will admit, that my explicit mention of CSP (I got
occam in there too) was to some degree mischievous (not entirely
so, as I think this would be right).  The response was interesting.

First, everyone claimed to have the necessary parallel computing
skills - yes, everyone of the contributors claimed that they or their
organisations had all of the necessary skills for the parallel
programming required!  Secondly, only one person (from ESI in
France) agrees with the essential principle of using something like
CSP, but thought that this particular problem was too complicated
for it.  The rest more-or-less laughed at the idea, especially at
occam.

When we started to work with parallel computers - we had a
wonderful Parsytec Multicluster, (I still have, but I don't have the
switching card - anyone know of one I could purloin?) - we had
Adrian Lawrence come and give us a course on CSP.  That did
certainly colour the thinking of the guys who have written/
adapted/maintained the codes.  Once, we had a guy who actually
wrote a CSP description of the big TLM code (it was tractable!),
and proved it deadlock free.  That is all.  We just hack the code
now.  So I have been having chatettes with the guys to try to
understand why we do things the way we do them, and what it
would take to persuade them to do things differently.

The general feeling is:

a) would naturally turn to c for the dynamic memory advantages.

b) would rather use the c++ compiler for its tighter checking,
though would not use OO (it's too hard).

c) data and data structures perceived as the difficulty (they don't
even think in terms of messages, nor of messages (or data) as
triggers for events (processing)).

d) they would think more seriously about formal methods if there
was a tighter link between the formal description of code and the
source of the executable programme (tail-end config-control).
(Strangely unconcerned about the front-end difficulties - but
probably just hadn't thought about it.)

e) CSP is:      another thing to learn,
                another manual process in the way of code writing,
                        (cf Denis Nicole to OT, 21 Apr 99)
                less able to cope with complexity than hacking,
                not obviously of benefit.

My impressions from this are:

1/      That people have a very strange view of the way to cope
with complexity.  It seems that the formal approach should aid in
this, not hinder, that high complexity ought to be driving us
towards CSP, not the opposite.

2/      That the benefits of CSP, its successes, are not publicised
and exploited sufficiently.

3/      That there is a need for more education on the benefits of
designing parallel code - we are definitely still thinking about,
designing and writing sequential code that we hack into parallel
operation.

4/      In the area of simulations and analysis code, there is
absolutely no perception of the need for or benefits from security,
and write-first-time is a jam-tomorrow promise.

Short of doing it my way, and I already have a full-time job, I do not
know how to change this.  There are examples of the success of
CSP and of occam, but they are not widely perceived.  I know that
Formal Systems had some tools, but do they help in industrial
circumstances without giving the impression of added yet another
process?

Asides:

A)  Our chief programmer is a Cambridge mathematics graduate (ref
phw to OT, 19th Apr 99)

B) How much more rapid might developments in mechanical
engineering have occurred and how much more reliable might
mechanical systems be now had 'a posteriori' formal methods been
applied - it is still almost always the mechanical bit that fails.  (ref IE
to phw, 19th Apr 99).  Actually, I think I want "a priori" at least.

C) ref Rick Beton, 10 May 99.  I remember suggesting Unix written
in occam years ago.  Memory management and recursion were the
excuses then, though I cannot see that they could not have been
got around explicitly, at least for a demo.  I still think its a great idea
and would do something for the image, if nothing else.  It might
inadvertently result in an OS that doesn't crash around your ears all
the time as a minor spin-off.

Cheers,

Chris.
-- 
Christopher C R Jones
Technologist Consultant - Lightning NEMP & CEM
British Aerospace
Military Aircraft & Aerostructures                      tel: +44 (0)1772 854625
W423A                                           fax: +44 (0)1772 855262
Warton Aerodrome                                           ccrj@xxxxxxxxxxxxxxxx
Preston
Lancashire  PR4 1AX
United Kingdom