RE: The world needs process-orientation

[tjoccam@xxxxxxxxxxx]

>> 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.

Neil,

I'm aware of all that, having lived it in the last 10 years of my career.
But things do not stand still. There may not have been a conspiracy (see
my thread starter for evidence that there was at least dishonesty), but
the causes you mention have come to a head and are clearly about to
administer a death-blow to process-oriented (i.e. designed) technology.
Sub-optimal steps are simply being swept away in the avalanche. This is
the meaning of Ruth's message. THERE NEEDS TO BE A WAKE-UP CALL and
something other than business as usual.

>
>
>> 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.

But the tools have to have a universe to live in. Hence, the idea of a
territory. Otherwise our alphabet soup entries just get swept away by
confusion with everyone else's. The Cell or 360 would be really good ---
given our kind of OS. I have a patent-pending invention that would be
perfect, and valuable, but of course I've got a near-zero chance of
getting funded. Whatever it is, it's got to be a concerted, focused effort
that results in a physical, usable thing that works better than anything
else.

>
> 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.

That's where I disagree: books and tutorials enter a hugely crowded field,
and everyone else "can't find the time" either. However...

> <SNIP>

>> 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.

That means the Cell should be our target. According to Hannibal's review
of the Octopiler, they won't have a good compiler for 10 years, whereas we
were dealing successfully with these issues in 1990.

Larry

>
> Thanks,
>
> Neil.
>
>
>