Path: utzoo!mnetor!uunet!tektronix!reed!percival!littlei!ogcvax!pase From: pase@ogcvax.UUCP (Douglas M. Pase) Newsgroups: comp.software-eng Subject: Re: Is it Art or is it Engineering Message-ID: <1553@ogcvax.UUCP> Date: 10 Feb 88 19:25:45 GMT References: <6879@agate.BERKELEY.EDU> Reply-To: pase@ogcvax.UUCP (Douglas M. Pase) Organization: Oregon Graduate Center, Beaverton, OR Lines: 26 In article decot@hpisod2.HP.COM (Dave Decot) writes: >I agree that the distinguishing characteristic between what this >"industry" does and engineering is the general unexpectation that what >is produced will perform exactly as specified. ^^ ^^^^^^^^^ There's the rub. If we had a notation sufficiently precise to completely specify what our programs were supposed to do, we would use this specification language as a programming language, write a compiler, and then they would perform exactly as specified. Denotational semantics has been pushed in that direction (if I'm not mistaken). In a sense, the programming language is a specification of the program behavior -- if it doesn't work right, it's because the programmer didn't specify the behaviors correctly. This, by the way, is a favorable argument for using higher-level languages (functional, logic, etc.) when it is possible to do so, and teaching people how to use them without introducing "impurities" into their code. If used correctly, they could boost code reliability, and certainly our understanding of common problems. Code verification for "pure" functional/logic programs is far easier than for imperative languages, to the point of being relatively trivial. Implementations of such languages are becoming efficient to the point of rivaling imperative languages, so efficiency is no longer a problem. They are not yet widely available, nor is there a large programming force that could use them if they were. Maybe that will come later. -- Doug Pase -- ...ucbvax!tektronix!ogcvax!pase or pase@cse.ogc.edu (CSNet)