Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!seal.cis.ohio-state.edu!ogden From: ogden@seal.cis.ohio-state.edu (William F Ogden) Newsgroups: comp.software-eng Subject: Re: recap so far Message-ID: <81769@tut.cis.ohio-state.edu> Date: 29 Jun 90 02:15:33 GMT References: <30852@cup.portal.com> <102100011@p.cs.uiuc.edu> <31097@cup.portal.com> <1568@oravax.UUCP> <8488@jpl-devvax.JPL.NASA.GOV> <81688@tut.cis.ohio-state.edu> <8529@jpl-devvax.JPL.NASA.GOV> Sender: news@tut.cis.ohio-state.edu Reply-To: William F Ogden Organization: Ohio State University Computer and Information Science Lines: 62 In article <8529@jpl-devvax.JPL.NASA.GOV> kandt@AI-Cyclops.JPL.NASA.GOV writes: ... >I claim that anything that we build -- a command and control system, a >flight reservation system, an operating system, and so on -- has a >conceptual basis; if they didn't we couldn't build them. One must be careful to distinguish between mathematical domain languages and programming languages here. Generally, mathematical domain languages being declarative and nonconstructive are more powerful than programming languages. That makes them useful for concisely expressing precise specifications for software components -- provided you can find a suitable mathematical domain within which to represent a particular software component domain. For example, it might be the case that the reusable components for flight control systems could appropriately be represented in the mathematical theory of partial differential equations, or that those for airline reservation systems could best be described using graph theory. If furthermore, there turned out to be a Find_Flights operation among the airline components which `finds all flights from airport A to airport B of duration less than T leaving on date D', this operation would have a precise graph theoretical specification which would answer any questions about what it would do. Note here that mathematical domains and programming domains differ in that Find_Flights belongs to the latter, but not the former. If by a `conceptual basis' you mean a mathematical domain in which components from a programming domain can be specified exactly, I expect your claim, taken literally, is correct. The real problem, of course, is to find an APPROPRIATE conceptual basis [mathematical domain] for describing components. For example, choosing number theory to describe airline reservation components (using say Godel numbers), while technically quite feasible, would produce totally useless specifications. I presume accordingly that your claim should be interpreted as postulating the existence of appropriate mathematical domains for describing any reusable components that will be created. That seems far from obvious. > The notation >for each of these domains can be described by a language which would >provide the syntax, semantics, and even pragmatics for the modeled >domain. If one did not know how difficult it is to work out the concepts and theory for a new mathematical domain, this could almost be read as suggesting the creation of a theory for each programming domain. > Individuals can be easily taught this new "notation", it would >not be any more difficult to learn than another programming language, or 4GL. Most of us find it fairly challenging to learn a new mathematical domain. It's not, however, the 'notation' of differential equations or category theory that gets to you; it's the insights about the concepts and the theory that takes the time and effort to learn. Unfortunately, a superficial knowledge of a mathematical theory won't suffice for programming. A new age programmer who learned his number theory from a pocket calculator might not know that a program that sums up an array of integers from bottom to top gets the same result as one that sums from top to bottom, even though he understands addition perfectly well at a notational level. /Bill