Re: JCSP, CSP Networking, and other some other points

[Anne van Rossum <anne@xxxxxxxxxxx>]

Dear Chris,

Your email reads as some kind of science fiction. I like it. In science fiction often hardware is described that yet does not exist. And in your email it is about hardware that existed, or with the hope of existence, but that doesn't exist anymore. Something like the CAM-Brain infrastructure, a bunch of evolvable FPGAs, from Hugo de Garis, which never did make it (it became operational, but went out of existence together with a large part of Starlab). In contrary to that, I think Hugo might in the end finally get such an infrastructure working because he is imo thinking on the right level. Namely, the creation of hardware that supports evolving global brain architecture. Although... I didn't see in any paper or technical report how he thinks he might do this global organization: he is only evolving individual modules. That is like evolving the individual agents in a multi-agent system, but not evolving the interactions/language between those agents, or not providing aggregation operators that fuse agents to composed agents on other levels. However, enough about that. 

What I would like to add to this discussion is the idea that parallelism might not be a cornerstone that can be tackled in isolation. Programs obey certain decomposition principles, as for example explained in Stein's article: "Postmodular systems: Architectural principles for cognitive robotics". I entirely agree that it is not right to teach Java and the object-oriented paradigm as the only viable way of programming in existence. I run into that daily in my work on modular robots and wireless sensor motes. However, that occam is in such demise, might have a reason. The abstractions chosen by the OO way of programming are not the proper ones in certain contexts, but the abstractions chosen by focusing on parallelism alone, might also not be telling the whole story. I tend to abstract from the levels that don't give me "handles" to change system properties, and focus on the levels that allow for self-organization. If an underlying layer supports migration operators, I am happy to include them to achieve load balancing in parallel with for example the pattern recognition that I do on another "level". I see self-organization principles becoming more and more important. What are the individual modules in our brain? How do they interact with each other? I guess software "interface" can learn a lot from their biological counterparts. How does the thalamus interface with the cortex? That interface is a lot more adaptive than a Java interface and does not leave out time, space and a lot of other constraints that are neglected in an OO interface. If we look more at assemblies of bacteria colonies, cells in multicellular organisms, or assemblies of neural agents in a brain, than a "network compiler" might become a viable research direction. If parallelism is considered as a stand-alone topic, it won't survive in this 21st century.

Kind regards,

Anne

---------------------------------------------------------------------------
From: "Jones, Chris C (UK Warton)" <Chris.C.Jones@xxxxxxxxxxxxxx>
Sent: 08 May 2009 13:46
To: 'Larry Dickson'
Subject: RE: JCSP, CSP Networking, and other some other points

Even now, we would write some applications in occam were there a
reasonable way of programming a large parallel computer - we currently
run 128 quad cores with a Quadrics switch.  There are some issues
though:

1.  Lack of occam knowledge - actually this is far worse than it sounds.
We lack parallel computing knowledge at a fundamental level.  Making
cals to MPI libraries is not the same thing.

2.  Personnally, I'd like to see a development systems akin to the old
TDS - I am so old I actually do not like the modern programme writing
pardigm with thousnads of interlinked filelets requiring a compendium of
flow charts and dependency diagrams and spreadsheets to track effects.
I am actually in a day-mare trying to sort out such a problem at the
moment.

3.  Access to standard libraries like LINPACK and NAG.  This may be a
solved problem, I haven't looked recently.

4.  We would have to be able to identify an organisation that would take
responsibility for supporting the compilers.

-- 
MSc./Ir A.C. van Rossum
Researcher
Almende B.V.
Westerstraat 50
3016 DJ Rotterdam
The Netherlands
Phone:   +31 (0)10 85 119 25
Project:   http://replicator.almende.com/ (main project)
Website: http://www.almende.com/
LinkedIn: http://www.linkedin.com/in/annevanrossum