Computing: the science-engineering continuum 18 Apr 2008Posted by Tony Law in Uncategorized.
Tags: BCS, Correctness
add a comment
Professor Sir Tony Hoare is one of academic IT’s great names: one of the first UK Professors of computer science, and now associated with Microsoft’s Roger Needham Research Laboratory in Cambridge. What may not be so well realised is that his early days in IT included the decidedly practical delivery of the first commercial compiler for the Algol-60 language – the first language I myself learned as a postgraduate at Oxford less than ten years later. But, in the early 60s, everything was new and there was as much research involved in such a task as practical engineering.
The BCS’s London Group meeting yesterday evening was probably better attended than any I’ve been to, showing how widely recognised and respected Prof. Hoare is. He shared his thoughts about the two ends of the spectrum, and the collusion (no, not collision) between them. He stimulated a wide ranging discussion about the differentiating characteristics of “pure” exploratory science, and practical engineering. I’ll pick just a few, and reflect the discussion.
A scientific investigation focusses on the long term development of knowledge, or of an effective framework to understand and rationalise observations. It is as much interested in the details that don’t fit. In fact, probably more so: since these indicate the imperfections that will lead, in due course, to the flash of inspiration that creates a newer, better and more generalisable theory. We might say that a scientific theory is developed to stand for the foreseeable future, though “foreseeable” might be short-lived or very long term.
An engineer, on the other hand, is concerned to develop a serviceable, dependable product whether it be a bridge, a vacuum cleaner or a software module. The 80-20 rule applies; an engineer will either over-compensate for the unknown, to assure safety, or find a way to work round it. Innovation is a source of risk that has to be assessed and managed, and an engineer for preference will work on the basis of what has been successfully understood and used before. An engineering artefact is developed to meet a particular need and to stand for a known period of time. In many cases this is short term, until the next scheduled generation of the product is developed, although the designed-for period may be long and it may be considerably exceeded (think mediaeval buildings, for example).
Tony Hoare is interested in the science of correctness of programs. He argued that this endeavour is truly a science, based on the list of characteristics he (and the audience) had adduced. However, its target is the development of engineering dependability in the software that will be proved using the tools. He sees the link between the two as the necessary development of domain models which can themselves be scientifically proved, and can then be used as the basis for dependable production-scale engineering. He cited the parallel of the aircraft designer, who tests aerodynamics using a model in a wind tunnel. Such models must be of significant enough scale that the tests are realistic, but will not be production scale. Finding such domain models is itself a challenge; in some cases they may have to be developed.
Over refreshments, I talked briefly with Prof. Hoare about the challenge of developing tools to prove correctness. Their own correctness must of course be of a higher order than the correctness they are trying to prove, otherwise the error might be in the tool, not the artefact being tested! There’s no primary standard. If I understood correctly, there’s a bootstrap process which can be used to successively prove the correctness of elements of the tool. The necessity for proof of that process is what shows that this is science, not engineering!
• Tony Hoare home page on Microsoft Research
• Elliott Algol-60 (History of Programming Languages, Murdoch University, Australia)
• BCS London Central Branch past events; look here for the download of Prof. Hoare’s slides, not yet available