Talk given at European Conference on Object-Oriented Programming. Paper available on Springer LNCS

1. Revisiting Information Hiding Reflections on Classical and Nonclassical Modularity K. Ostermann, P. G. Giarrusso, C. Kästner, T. Rendel University of Marburg, Germany

2. AOP Inheritance Mutable State Implicit Side Effects Reflection Failure-Oblivious Computing The Modularity Dichotomie Negation-as-Failure SML Modules Abstract Data Types Pure Functions Hoare Logic Design by Contract Existential Types

3. The Logic Dichotomie Truth-Preserving Deduction Closed-World Reasoning Precidate Logic Default Logic Nonmonotonic Logic Monotonicity Belief Revision Global Consistency Axiomatic Method Paraconsistent Logic Model Theory Inductive Reasoning Occam’s Razor

4. This talk Relating the modularity dichotomie to the logic dichotomie Philisophical justification for being on the dark side Doubts whether the Jedi side is as desirable as we think

5. The Pillars of Classical Modularity

6. Information Hiding and Abstraction Distinguish concrete implementation of a component from interface Supports “modular reasoning” Interfaces as “firewalls” for change propagation Substitutability: Can freely modify or replace component implementations if the interfaces are the same Examples: Control structures, procedural abstraction, abstract data types, …

7. Information Hiding and Classical Logic Interface = Set of axioms Implementation = Model of the axioms Substitutability: Same theorems hold for all models of the axioms Cannot distinguish different models within the theory

8. Reductionism and Compositionality Reductionism: Belief that complex systems can be understood by understanding its parts and the rules with which they are composed Reductionism is an implicit assumption of classical modularity Formally stated as compositionality Example: Denotational Semantics Substitutability: Can replace expression by another one with the same meaning

9. Reductionism and Compositionality in Classical Logic Proofs of theorems are compositional: Can split into lemmas and proof independently Substitutability: Sets of axioms can be replaced by other axioms with the same deductive closure without changing the set of theorems

10. Idealization Deal with complexity by concentrating on things relevant to the task at hand ignoring the rest for the time being Galileo’s laws of motion Dijkstra: Must idealize because “we have very, very small heads” Idealization is an implicit assumption of modularity:

11. Interfaces as idealizations From the Java API documentation of java.awt.Label Idealization: Clients can ignore whether setText updates the screen public void setText(String text) Sets the text for this label to the specified text. Parameters: text - the text that this label displays. If text is null, it is treated for display purposes like an empty string "". See Also: getText()

12. Idealization and Classical Logic The axiomatic method is a formalization of idealization

13. Monotonicity Idea: Properties of a system can be proved “once and for all” We never have to withdraw a conclusion when we “learn more” Hoare Logic, equational reasoning, … are all monotonic …as are classical logics

14. Classical modularity, recap Software components Have well-defined stable interfaces (by abstraction) Can be organized hierarchically to manage complexity (by idealization) Changes to implementation do not affect rest of the system (by compositionality) Correctness can be proved in isolation, composition preserves correctness (by monotonicity)

15. Classical Modularity Compositionality Monotonicity Abstraction Idealization Information Hiding Reductionism

16. Programming as Human Activity

17. Programmers use Inductive Reasoning Programmers infer a general software property from observing individual cases Tests meant as instances of a general theorem Generalize observed/inspected behavior of a library to other parts Aside: Inductive reasoning also successfully used by tools such as Daikon [Ernst et al]

18. Inductive Reasoning is hard-wired HebbianLearning:“Cells that fire together, wire together”

19. Default Reasoning and Occam’s Razor

20. Default reasoning about APIs An API function will not perform the side effect of formatting the harddrive unless explicitly specified public void setText(String text) Sets the text for this label to the specified text. Parameters: text - the text that this label displays. If text is null, it is treated for display purposes like an empty string "". See Also: getText()

21. Occam’s razor and debugging …a division by zero in line 3 of X.java

22. The actual code of X.java According to Occam’s razor we reject this explanation public class X { public static void main(String args[]) { System.out.println("Exception in thread quot;mainquot; “ + “java.lang.ArithmeticException: / by zero" +" at X.main(X.java:3)"); } }

23. Default Reasoning and Occam’s Razor Acknowledged by principle of least astonishment

24. Law of Prägnanz in Gestalt Psychology We order our experience in a way which is regular, orderly, symmetric and maximizes simplicity.

25. Negation as FailureClosed-World Reasoning Removing an API function is OK if it is not called in my code base One can try to avoid API changes, but this leads to “software asbestos”

26. Closed-World Reasoning in Linux “Get your kernel driver into the main kernel tree. If your driver is in the tree, and a kernel interface changes, it will be fixed up by the person who did the kernel change” From: “The Linux Kernel Driver Interface”, Greg Kroah-Hartman

27. Don’t blame the programmers Programmers are forced to use non-classical reasoning: They have no other choice! Many relevant properties cannot be established with classical reasoning! As logical theories, module interfaces are highly incomplete!

28. Revisiting Information Hiding

29. Interface Detail If a stakeholder reasons about “non-functional” properties, the abstraction barriers break Example: Choice of implementation of an ADT matters for some stake holders Example: Power consumption, heat production, stack usage, … Using more precise interfaces does not scale Reveal more and more implementation details Unclear how to specify non-modular properties

30. Large Systems Whenever information is hidden, there is potentially a stakeholder (or, concern) who is interested in that detail The larger the system, the more likely such a stakeholder exists Hence the more difficult to maintain the classical notion of information hiding Example: Torvalds’ argument against microkernel OS

31. Large systems and crosscutting concerns Crosscutting concerns are hard to modularize using classical modularity mechanisms Tangling/scattering prevents composability Destroys assumption of classical modularity Just hiding a scattered concern behind interfaces as if it does not exist does not work

32. The Dominant Decomposition The “tyranny of the dominant decomposition”: What can be hidden depends on the decomposition But there is no “best” decomposition What one stakeholder would hide is of primary importance to another

33. Software Evolution Parnas: Hide what is most likely to change But how do we know which changes are likely? If a design decision is part of an interface, it cannot be evolved modularly But if it is hidden behind an interface, evolution might bring a new stakeholder which needs to know about that decision

34. Software Evolution Interface method of java.awt.Label Assume a new composite GUI component which includes two labels How can we implement display update for setBothTexts(String,String) without flickering? public void setText(String text) Sets the text for this label to the specified text. Parameters: text - the text that this label displays. If text is null, it is treated for display purposes like an empty string "". See Also: getText()

35. Information Hiding and Classical Logic:McCarthy’s Qualification Problem “In order to fully represent the conditions for the successful performance of an action, an impractical and implausible number of qualifications would have to be included in the sentences expressing them” [John McCarthy, 1980]

36. Programming and Modeling

37. Programming and Modeling What is the cause of the failures of classical modularity? My hypothesis: Influence of natural sciences and mathematics on CS and programming Programs as (scientific) models But does this notion of modeling fit to software?

38. Software “Modeling”

39. Programs are not models! Software has to take into account the needs of many stakeholders at once It has to interact with the real world Simplifying assumptions may turn out to be wrong Software systems are more like a mix of many overlapping and interacting models Programs are not models of a part of reality; they are, when executed, a part of reality

40. Scientific Modeling “We are confronted with a patchwork of theories and models, all of which hold ceteris paribus in their specific domains of applicability.” [Hartmann&Frigg, “Scientific Models”, 2005]

41. In the paper… Several “dark side” modularity mechanisms correspond to non-classical logics Aspects explained in default logic Failure-oblivious computing and paraconsistent logics Shared mutable state and separation logic … Goal of modularity: Modularize relevant properties A property P is modularized (w.r.t. logic L) in a program unit U, if P can be proven from U in L

42. Conclusions Software is a form of human knowledge representationthat happens to be executable on a machine The human face of the dark side

43. Reflections on Denotational Semantics let f(x) = if x == 0 then 42 else f(x-1)in f (1000000000) A semantics which says that this program denotes 42 is broken.

44. Information Hiding: Examples Control structures hide details of control flow management Substitutability: Compilers can choose among different implementations of control structure Procedural abstraction hides implementation behind procedure signature/contract Substitutability: Can replace by different implementation of same contract, e.g. Dijkstra’s THE layer structure Objects of a class can be replaced by objects of a subclass Substitutability: Liskov substitution principle Abstract data types hide internal representation of data Substitutability: Reynold’s abstraction theorem

45. Large Systems The filesystems depend on the VM, and the VM depends on the filesystem. You can't just split them up as if they were two separate things (or rather: you cansplit them up, but they still very much need to know about each other in very intimate ways) Linus Torvalds about Modularity in Operating Systems