RE: The world needs process-orientation

[neil@xxxxxxxxxxxxxxxxx]

> The problem is IT DOES NOT MATTER IF WE OFFER SOLUTIONS WORTH BILLIONS OF
> DOLLARS. WE WILL NOT BE LISTENED TO. We are in a positive-feedback death
> spiral, created by the OO people who commandeer all the relevant
> terminology, apply it metaphorically to unworkable irrelevancies, and use
> their clout to enforce their interpretation. 

> I have pursued the game development / highly parallel CPU opportunity for
> two years, including a white paper, written this year, showing how to deal
> with their problems. When I was interviewed for a job by a major game
> console manufacturer, the technical people were very interested, but I was
> vetoed by top management, who are married to their non-working design.
> Quality is actually a threat.

Larry,

I don't mean offence, but you make it sound as if there is a giant
conspiracy maintaining OOP's position.  The fact is, people are
resistant to change, and sometime about thirty years ago, OOP
succeeded, but POP-like (process-oriented) techniques were ruled out. 
Quite possibly because concurrency was less of an issue when you
usually had a single-CPU.  So they still have OOP now, and don't want
to have to retrain everyone and lose legacy code.  That is a legitimate
reason for sticking with what you know - hence my suggestion that small
sub-optimal steps (such as C++CSP/JCSP) might actually be the best way
to convince people.

 
> Here is my 2 cents worth: It needs to be a territorial thing of
> process-oriented people. We have to fence ourselves off from "standard
> computer science" or the OO hordes will dilute our directions before they
> can reach critical mass. This is the sort of role Inmos used to play. Our
> territory must offer hardware, OSs, compilers, linkers - all
> process-oriented only (very powerful hardware, by the way, now costs a
> hundred times less to develop than it used to). Only in this way can we
> make our case against the will of the managerial empires.
> 
 

I agree that we need more and more tools.  KRoC, SPOC, Honeysuckle, CTJ,
JCSP, CTC(++), C++CSP, are all good.  The more the better!  This is a
topic oft-mentioned, but what we need (as much as, if not more than
more tools) is good literature on the matter.  Whenever I advocate POP
to anyone, I lack a good place to point them for a good introduction to
the matter.  They say what is it, what can I use it for, where are code
examples, etc; I can usually point them to papers, which are not what
is needed.  Things like the IBM DevWorks JCSP article recently, pages
like Fred's on how to program occam, are what we want.

I'm as guilty as anyone else - I just can't find the time to write an
introduction to POP, or even a good guide to C++CSP.  I should, and I
encourage everyone else to consider the same.  Of course a major step
would be a book on the matter, but that's an even bigger undertaking. 
In the mean-time, we need web resources explaining POP, the tools, and
how to use them.  I know there are some people in Japan doing something
very similar to this, creating training materials and tutorials - we
need to do the same.

> > <SNIP>
> > While I would love for them all to start using occam or
> > the like, perhaps (excusing my self-indulgence) a port of C++CSP to the
> > Cell and 360 is more the approach that is needed in the short-term.
> >
> > Neil.
> 
> Writing an occam compiler for the Cell or 360 ought to be within even our
> diminished capabilities. Has anyone done it?

Not so far as I'm aware.  The 360 runs PowerPC cores, whereas the Cell
is very different to other designs so is trickier.

Thanks,

Neil.