Autcsrgv.345 net.followup utzoo!utcsrgv!donald Tue May 11 15:55:20 1982 Mathematics and Programming I must say the opinions of D.J. Molny and John Winterton are appalling! It reveals the pervasive attitude that mathematics means evaluating integrals and inverting matrices. This is by no means what is meant by "mathematics" in the context of programming. If it makes you feel bet- ter, substitute "logic" for "mathematics". I think Dijkstra just wants to put programming on a more formal, logical footing, and if this isn't "mathematics", I don't know what is. John makes much of the "fluid" specifications of programs, but I think he is confusing bad development techniques with prototyping. In a poorly developed system the specifications change frequently (if the specifications were ever precise in the first place!), a result of the user not knowing exactly what he wants. In any context other than software development this would be intolerable! Try building a skyscraper in which every other day the required dimensions change. The proper thing to do is to perform prototyping and experimentation so that the user finds out what he does or doesn't want in his system, and once that is properly defined, to go ahead and implement it for real. *AND* the process of implementation should have a solid formal basis so that we do it right! That's where the "mathematical" approach comes in. I might mention that I vehemently detract from the "commercial" languages (FORTRAN, COBOL, PL/I), yet I have written many so-called "serious" (i.e. real, commercial, for $$$$) programs in all three. The point is that all three (with the possible exception of PL/I) are clumsy ("Neanderthal" is the term used by Andy Tannenbaum) tools which hinder the natural expression of an algorithm. These languages fight the attempts of the programmer to properly abstract data, modularize programs, and in general produce good programs. I might also mention that COBOL I/O is grossly system-dependent and not as nice as John suggests. FORTRAN and COBOL are no more inevitable than the horse and buggy. After all, at the turn of the century there was a considerable investment in the latter. Consider the development of OS/360 as a programming project and the construction of the World Trade Center as an engineering project. What would we have said if the World Trade Center fell down several times a week? Yet people fatalistically accepted the analogous behaviour of OS/360. That is why engineering is a science and programming is a black art. Until we can construct programs with the same degree of reliabilty as buildings, it will remain a black art. Don Chan, utcsrgv!donald ----------------------------------------------------------------- gopher://quux.org/ conversion by John Goerzen of http://communication.ucsd.edu/A-News/ This Usenet Oldnews Archive article may be copied and distributed freely, provided: 1. There is no money collected for the text(s) of the articles. 2. The following notice remains appended to each copy: The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996 Bruce Jones, Henry Spencer, David Wiseman.