Review of Formal Methods: An Appetizer

Programming is still mostly undisciplined, 45 years after Edsger Dijkstra’s “A Discipline of Programming” [1]. For sure, in critical areas, like aerospace, communications, and silicon fabrication, rigorous approached are standard. But the vast majority of the software that underpins all aspects of everyday life is still crafted by one or more hands, with assurance given by design, inspection, and testing, rather than proof or refinement from a formal specification. There are lots of reasons for this, but, most important, hand crafted software works. Certainly, set against how utterly dependent we now are on software, the number of people who have died as a direct result of failure is vanishingly small. Long may this continue. But, by analogy with other engineering professions, it will take a major disaster to make formal software design and validation mandatory, most likely driven by a legal requirement for practitioner indemnity insurance. Thus, facility with formality is rarely a prerequisite for employment. This is really unfortunate: a demonstrable understanding of foundations should give reassurance of competence at practical programming. Thankfully, most Computer Science programmes include discrete mathematics and computability theory, often alongside declarative programming. Formality may be challenging, but it need not be hard. I have long admired the Nielsons’ pedagogy of presenting formal material through the systematic calculation of concrete examples, well exemplified by their excellent introduction to semantics [2]. Their engaging new book is a direct descendant of Dijkstra’s. The first two chapters present program graphs as abstract representations of programs, and Dijkstra’s Guarded Command language as a source for program graphs.