Skip to main content Skip to navigation

Formalism and Hermeneutics

An extract from EM paper #121: "Realising Software Development as a Lived Experience", an essay presented at Onward! 2012

More pragmatic approaches to developing theory and principles of programming acknowledge the human dimension as beyond formalisation. Most give high priority to abstraction as a means of maintaining a safe distance from the semantic mire of human experience – indeed, Kramer [66] proposes abstraction as “the key to computing”. Many other champions of formal approaches take a similar view. Lamport [67] reviews the prospects for systems development based on logic or biology, and declares his faith in logic. His key message is “we must keep our systems simple enough so we can understand them”. For Lamport, there is a role for metaphor, but it is one that is subservient to logic: “A good program must use good metaphors, and it must behave logically. The metaphors must be applied consistently – and that means logically.” In his “discipline of programming” (cf. [48]), Dijkstra strongly favoured the use of symbolic arguments, deprecating the ‘intuitive’ diagrammatic representations that featured in established software development methods. For such thinkers, visual images and other immediate components of our experience are to be treated with the greatest caution, and are in no way to be regarded as mature products of understanding.

The suspicion of metaphor and intuition in this context stems from the fact that they are associated with a tradition that is hermeneutic rather than formalist in the sense discussed by West in [84, Chapter 2]. In a hermeneutic approach to semantics, meaning is regarded as being negotiated through interaction with the world and with other human agents. This establishes an essential link between knowing and personal experience, and means that what a formalist regards as ‘objective’ knowledge is subject to a process of construction (cf. Latour [69]).

The scope for conflict between formalist and hermeneutic stances is highlighted by West’s provocative characterisation of a hermeneutic perspective [84, p.54]:

“The hermeneutic philosopher sees a world that is unpredictable, biological, and emergent rather than mechanical and deterministic. Mathematics and logic do not capture some human-independent truth about the world. Instead they reflect the particularistic worldview of a specific group of human proponents. Software development is neither a scientific nor an engineering task. It is an act of reality construction that is political and artistic.”

Taken at face value, such a characterisation leaves little scope for reconciliation between hermeneutic and formalist philosophical stances – an issue central to my own research objectives to which I shall return later in this essay. But this controversy is much more than a matter for esoteric philosophical debate; it is a fundamental concern for the practical evolution of software development.

The tension between formalist and hermeneutic outlooks is prominent, for instance, in the unwelcome impact that SQL, as the de facto standard relational database query language, has had on software development. There can be no doubt that the world-wide adoption of SQL has the character of “an act of reality construction”. There can likewise be no question that, as has been argued by Date and Darwen [46] over several decades, SQL embodies fundamental logical flaws that have subverted Codd’s visionary conception of a pure relational algebra database model [42]. Whether the mathematical and logical model proposed by Codd can be described as “a human-independent truth about the world” may be controversial. But, as Date and Darwen have made clear in numerous writings, the implications of the deviations from a pure relational model are profound and disturbing. Relational algebra provides a framework within which to represent and manage complex data that – in its appropriate context of application – has exceptional elegance and power. As is commonly the case when a construction is inconsistent with a well-conceived mathematical pattern, even if only in what may appear to be minor details, it cannot diverge ‘just a little’ from the ideal. The logical flaws in SQL have contributed directly to problematic issues in its design and application that are compounded by legacy issues and cannot be satisfactorily addressed by retrospectively revising the standard.

In championing a comprehensive reappraisal of, or alternative to SQL as the standard relational algebra query language, Date and Darwen are battling against seemingly impossible odds. It is in some sense easy to recognise the notion that SQL will prevail, warts and all, as representative of what might be hermeneutic ‘truth’: the current status of SQL is surely human-dependent, but what kind of human agency could change it is wholly unclear. Contrast the status of SQL with that of the relational model whose role it has usurped. Beyond question, one could give a demonstration of the qualities of a pure relational algebra model that would show decisively why it is so exceptionally well-suited to the role of data representation and management. I do not know in what sense such a model can be construed as the product of human politics or artistry, and – as an algebraist by training who appreciates the inexplicable aesthetic and expressive qualities of mathematical constructions – I have every sympathy with the formalist who declares it to be an instance of human-independent truth. My purpose in contrasting the status of SQL with the status of the relational model in this way is to highlight the common experiential basis on which they rest. Whether or not SQL is to be deemed a “constructed reality”, or the relational model to be regarded as “a human-independent truth”, is in practice immaterial: the status of both is something that can be made apparent in our immediate experience, and it is hard to imagine an agency that can change either.