4 ms·

> No such theory exists for programming. The complex application you designed has no theory behind it at all. The theory isn't a theory of programming or softw

> No such theory exists for programming. The complex application you designed has no theory behind it at all. The theory isn't a theory of programming or software engineering, but of the problem domain. From the paper: > In term's of Ryle's notion of theory, what has to be built by the programmer is a theory of how certain affairs of the world will be handled by, or supported by, a computer program. I've worked on plenty of commercial software with a theory of how some particular domain ought to be handled. A business process is almost always the starting point for the theory. Similarly, software like Make (targets + recipes), Xorg (client-server model) or TiddlyWiki (reusable content + transclusion) have specific theories about how their respective tasks ought to be thought of.

corethree 3y ago
So can you prove things with this "theory" are there theorems? What are the axioms? More like there is no theory. You just build it off of your gut feeling. Maybe you use big words like "dependency injection" or "domain knowledge" to make it feel like you have a theory but really you don't. When you have a theory, aspects of the design are calculated. Diagraming the architecture on a whiteboard is not theory. It's still gut feelings.
- mmcdermott 3y ago
  The underlying model can be thought of as the axioms. Going back to the Make example, it is trivial to think about axioms that describe the system's base abstraction ("Let T be a set representing targets...."). Generally speaking, the theory backing a system gets used to prove a few things. 1. Given a set of requirements we want to make sure that our model for the system can satisfy those requirements. If you cast your model as a series of logical formulae, then you can certainly decide to frame questions of requirement satisfaction as proofs or derivations. 2. Does a given codebase implement the theory/model we postulated? This is generally a code or design review conversation, but could certainly be the subject of formal verification. 3. Given a new requirement (formula) can we handle it with the existing system? The third option feeds into another of Naur's points throughout the paper, namely that there are limits to the evolution of a theory before it must be tossed out. If you are thinking of some systems that you have maintained that have ceased to make any kind of sense (a programmer described a system we were working on as a Winchester House for this very reason), then you have reached the point where the theory is lost which is equated with program death in the paper. I do find it curious that you refer to design patterns and diagramming. In my mind, design patterns are a way to communicate implementation details to others working on the codebase. Saying a service uses dependency injection is like saying a building uses an A-frame. Useful information to be sure, but no one thinks of "use an A-frame" as an architecture in itself. Similarly, diagramming is always a method of communicating. The map is not the territory. Some methodologies (I'm looking at you, UML craze) forgot that but it this paper far predates that particular period of folly.

corethree 3y ago

So can you prove things with this "theory" are there theorems? What are the axioms? More like there is no theory. You just build it off of your gut feeling. Maybe you use big words like "dependency injection" or "domain knowledge" to make it feel like you have a theory but really you don't. When you have a theory, aspects of the design are calculated. Diagraming the architecture on a whiteboard is not theory. It's still gut feelings.

mmcdermott 3y ago
The underlying model can be thought of as the axioms. Going back to the Make example, it is trivial to think about axioms that describe the system's base abstraction ("Let T be a set representing targets...."). Generally speaking, the theory backing a system gets used to prove a few things. 1. Given a set of requirements we want to make sure that our model for the system can satisfy those requirements. If you cast your model as a series of logical formulae, then you can certainly decide to frame questions of requirement satisfaction as proofs or derivations. 2. Does a given codebase implement the theory/model we postulated? This is generally a code or design review conversation, but could certainly be the subject of formal verification. 3. Given a new requirement (formula) can we handle it with the existing system? The third option feeds into another of Naur's points throughout the paper, namely that there are limits to the evolution of a theory before it must be tossed out. If you are thinking of some systems that you have maintained that have ceased to make any kind of sense (a programmer described a system we were working on as a Winchester House for this very reason), then you have reached the point where the theory is lost which is equated with program death in the paper. I do find it curious that you refer to design patterns and diagramming. In my mind, design patterns are a way to communicate implementation details to others working on the codebase. Saying a service uses dependency injection is like saying a building uses an A-frame. Useful information to be sure, but no one thinks of "use an A-frame" as an architecture in itself. Similarly, diagramming is always a method of communicating. The map is not the territory. Some methodologies (I'm looking at you, UML craze) forgot that but it this paper far predates that particular period of folly.