As I am now retired I am not doing any research in the sense I was whilst an academic in the period 1983 to 2001. In the period 2001 to 2017 I was keeping up to date with current state of the art, but only really contributing via work on GPars and PyCSP, most of my time was consulting and training, and making presentations at professional conferences.
My research work focused on the development of computer-based systems, looking at processes, techniques, tools and environments, and included philosophical aspects. This work was aimed at modelling the development of computer-based systems as a holistic socio-technical enterprise; that is modelling the organisational and human issues in systems development as well as being concerned about the computing-technical issues.
I was particularly interested in languages and environments for developing parallel object-oriented systems. I led a group in the mid to late 1980s developing a novel, parallel, object-oriented programming language called Solve as part of the ESPRIT project SPAN. At the end of that project I continued with the ideas but focused more on a more directly applicable way by looking at extensions to C++ and Java. UC++ was work done in the early 1990s at UCL, KC++ was work done at KCL in the late 1990s. Both UC++ and KC++ were library-based extensions to C++ to deal with parallelism. I was also a member of the EUROPA Working Group which defined a standard for parallel programming using C++ called internally EC++ (not to be confused with the other EC++) as well as ||C++.
I was a member (but not particularly active) of the OPEN consortium which is a research group developing ideas about object-oriented systems development. As well as working on issues of process, I was interested in usability issues involving UML; by this, I mean the usability of the UML notation by developers and also the ability of UML to be used to develop sensible user interfaces.
I was increasingly interested in Dataflow Model and Communicating Sequential Processes (CSP) – and to a lesser extent Actor Model – as architectural models for parallel applications. Now that every computer is a parallel one, and the era of ever increasingly faster processors is over, the only route to continued performance improvement of applications is to make them parallel. For the last 30+ years, high performance computing (HPC), aka supercomputing, has focused on hugely expensive hardware, requiring an attached power station to run, and using Fortran, C or C++ with MPI and OpenMP. Most of the codes are computational intensive, being computational fluid dynamics, weather forecasting, human genome, particle physics, etc. The techniques used there are unlikely to be appropriate outside those areas, so attempting to transport MPI and OpenMP to them are unlikely to succeed. In fact this has been tried using Java and Python and definitely failed.
The Scala, Fantom communities are looking to Actor Model to harness parallelism, whereas Go is looking to CSP. The GPars project is looking to provide a framework allowing Actor Model, Dataflow Model, CSP and software transaction memory (STM) to be used by anyone using the JVM as a platform. The Python-CSP project brings CSP to Python, and there are plans afoot to bring Dataflow Model as well as Actor Model to Python.