Thursday, 6 February 2020

Ten Aphorisms

Alan Perlis was the first winner of the Turing Award in 1966. In 1982 he published [1] a set of 130 epigrams on programming. His aim, he explained, was to capture—in metaphors—something of the relationship between classical human endeavours and software development work. "Epigrams," he wrote, "are interfaces across which appreciation and insight flow." This post offers a few aphorisms. My dictionary tells me that an epigram is 'a pointed or antithetical saying', while an aphorism is 'a short pithy maxim'. Whatever they may be called, I hope that these remarks will evoke some appreciation and insight.

1.  The products of normal engineering have requirements, but the products of radical engineering have only hopes and aspirations.
2.  Premature formalisation cripples understanding of the physical problem world.
3.  Successful search for design errors demands a method that tells you where to look.
4.  Large structures can emerge only from bottom-up assembly; small structures may sometimes emerge from top-down decomposition.
5.  Declarative properties can be deduced from causal models, but not vice versa.
6.  Administrative systems can sometimes define problem world states in terms of the computer state; cyber-physical systems must be more honest.
7.  You can't determine what went wrong unless you understand exactly what going right would have been.
8.  To ask whether the software for a cyber-physical system is 'correct' is like asking whether your house is 'correct'.
9.  A system is not a device: devices have users, but systems have participants.
10. We lack suitable formalisations for causality, but the physical world doesn't know that.

[1] A J Perlis; Epigrams on Programming; ACM SIGPLAN Notices 17,9 September 1982.

Links to other posts:
 → Top-Down: Why top-down development is so often a mistake


  1. I very much enjoyed this. Thank you Michael. Perhaps you should now try some ‘misleading’ aphorisms along the lines of Hoffnung’s advice to tourists!

  2. Ah yes, Anthony, do your observations 28 years ago about the software development process and its immaturity count as aphorisms?


    A Finkelstein, "A Software Process Immaturity Model," ACM SIGSOFT, Software Engineering Notes, Vol. 17, No. 4, October 1992, pp. 22-23.

    PS: Thank you, Michael. An excellent piece.

  3. Michael: I really enjoy reading every aphorism in this post! I guess each reader has his or her own level of understandings depending on his or her own experiences. Here are mine:

    Aphorism 1. The physical world is deterministic (for CPS problems, there is no need to worry about quantum mechanics since it only applies to quantum world), so causality applies. Despite the fact that hopes or aspirations can sometimes have direct or indirect impact on social and physical worlds, their influences still have to be executed through physical phenomena in the world, which can be captured as events or states. Perhaps methods or tools from data science might help with describing them in a concrete way,by which causal reasoning can be applied, though radical design still needs trial and error, and innovation.

    Aphorism 10. Many CPSs impose some levels of control over physical or social phenomena, which needs formal languages that can describe and quantify phenomena in an asymmetric notation so that causal reasoning can be mechanised and automated. The "!" symbol indicating direction of control in Michael's problem diagrams provide opportunities for doing this. Traditional mathematics or statistics usually prefers the "=" notation or correlation for description whilst Wright's causal diagrams and Pearl et al's formalisation can avoid this kind of bias.

    Reference on Wright's causal diagram and its asymetric representation (page 12):

    Judea Pearl, THE BOOK OF WHY: THE NEW SCIENCE OF CAUSE AND EFFECT, New York: Basic Books, Published May 15, 2018