|Hello Rick and Peter,|
For my efforts - stretching over decades - the main benefit I have received from you is the discussions and ideas, especially on this list. My actual work has generally been hacked together in C, but always with the benefit of occam-related concepts. You have done great service in keeping an alternative path alive in what threatens to become a computing monoculture. I would suggest to the Research Excellence Framework that this has been your main "Impact of Research" - avoidance of a monoculture. The Irish Potato Famine and many analogous disasters in technology (e.g. Ariane 5 disaster) teach the great value of avoiding monoculture.
A question on a term, and an idea responding to Rick...
I feel that the work at Canterbury has been very necessary, quite distinctive, and a considerable but subtle benefit to the commercial business software in which I spend my time.
One notable benefit has been from the educational materials in process oriented design with Java, such as Peter Welch's talks and presentation materials. This stream of insight has been quite distinctive in a software world where everyone else is talking about asynchronous programming (which is unscalable and therefore ultimately much harder).
What is the meaning of your term "asynchronous" in this context? I have noted it used frequently and clearly as a key concept.
Much business software is event driven, involving message passing queues etc. Clear ways of thinking through the issues are needed and the Canterbury team have made a very worthwhile contribution here.
We have been able to use JCSP in some very effective ways in a range of projects. The largest design-in was in the London Congestion Charge control centre. Here, JCSP orchestrates the Java server that collected the feeds from nearly 1000 cameras, with 7 tcp connections per camera. This task is highly concurrent and high volume (typically 1.5M records captured per day).
Some of my projects have been of the 'one thread per request' Tomcat model. Such projects tend not to use any other explicit threads. But as soon as the design needs to vary the lifecycle from one thread per request to interacting with longer-running threads, JCSP has been found to be an effective way of synchronising and exchanging data.
In my work, JCSP is now also being used from Scala and other JVM-based languages.
I'd like to conclude with a few observations about Occam and the Kroc toolset. This has clearly been a potent tool for education and concurrency research. However, there is just a hint that we might have done more here. Compared to other small language bases (perhaps Go for example), there have been some hurdles to wider adoption that could in principle have been overcome with a modest effort - the incomplete tool chain and the need for creating more modular code are the two issues I would mention.
I think both these complaints are part of a bigger problem: It is necessary to handle all boundary conditions in a clear and understandable way (simply put: capable of being scripted in Linux, for example). Boundary conditions include: how to load the code, how to start, how to stop, how to initiate communication, how to connect new parts, how to bring already existing blocks of code into service. There should be no inaccessible magic - not even interrupts should be magic!
I think that there needs to be more effort expended here - there is the potential for this work to have an active community of users, particularly in embedded logic and control systems, but it needs a small seed-corn to get it to a place where this can flourish. Occam is the bed-rock of the highly-successful JCSP and deserves to do better. I see Occam and Go as siblings that occupy a similar minset but slightly different spaces and there will be clear benefits from keeping Occam in a usable state therefore. There is potential for a healthy cross-fertilisation of ideas in their respective communities going into the future.
In summary, there has been much work that has been of considerable benefit from the Canterbury team and I strongly recommend that this continues. I have a few ideas for taking this further - perhaps in addition there might be more investment in Kroc as a vehicle for practical concurrency and for education, and more investment in cohesive literature such as a book on the process oriented approach on a variety of platforms.
Big Bee Consultants Ltd