Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!mcvax!cernvax!cgch!warw From: warw@cgch.UUCP (Anthony R. Wuersch) Newsgroups: comp.software-eng Subject: Re: Rhetoric and Software Engineering Message-ID: <828@cgch.UUCP> Date: 25 May 89 10:34:30 GMT References: <1886@ccncsu.ColoState.EDU> <11766@well.UUCP> Sender: news@cgch.UUCP Organization: WRZ, CIBA-GEIGY Ltd, Basel, Switzerland Lines: 105 shf@well.UUCP (Stuart H. Ferguson) writes: >I've always maintained that business of programming computers is a lot >closer to the artistic and technical practice of writing and word-smithy >than that of building bridges. For a good analogy, use railroads instead of bridges. Let a program be a railroad network, i.e., tracks, switches, and stations, which trains, (i.e., computing machines) run on. Trains transport goods from boarding stations to deboarding stations. You need a train schedule, price list, money, and means to get to the train station to use the railroad. [ Thanks to Albert Meier for writing the article with this analogy ] Derailments, missed connections, changing schedules and prices, disabled track, overpacked trains --- all are possible. But they don't occur too often (I hope). If you agree that railroads are a good analogy, then show me a railroad schedule which reads like an essay. The best railroad schedules, such as Switzerland's three volume set, are packed with path maps, indexes, codings, and graphical symbols. Their amount of text is small. Also, their readers don't all speak the same language. >But computer people seem to reject this notion, and I don't really >understand why. Perhaps it's because we generally dislike the "humanities" >and did poorly at them in school -- I don't know -- anyway, it's not a >popular opinion. Donald Knuth is maybe its biggest exponent. The CACM had a series called ``Literate Programming.'' Documentation and specification people stress it. Many computer people accept the writing analogy. It's a popular opinion. Don't confuse a rhetorical opening --- claiming the enemy's point of view is dominant in order to use it as a strawman --- with reality. >Although there are certainly places where the analogies are strained a >bit, they are at least as good as the "bridge building" analogy, if not >better, so I think it's possible to learn something from them. There are no decent analogies from writing to issues of process and flow control. With the loss of these issues, one can't grip issues of how a system performs in an operating environment. And such issues lie at the heart of engineering, as I understand it. A railroad schedule, on the other hand, lists thousands of performance promises. >Language, particularly rhetoric, has the capability to create worlds, and >to allow people to share them. Writing encapsulates not just some particular >information, but the entire set of background assumptions that make those >facts or ideas possible at all. Aristotle's definition of rhetoric is the study of the available means of persuasion. That is, there is always a persuader [speaker], i.e., someone who wields those means, and an audience (or audiences) to be persuaded. There is no assumption in a rhetorical point of view that the speaker and the audience(s) share assumptions. And there's no restriction of the means of persuasion to written linguistic forms alone. The encapsulation thesis is very questionable. At any time, potentially available means of persuasion are much wider than writing, and today they also go beyond what was possible in Greek and Roman times. And you can't just unify assumptions by taking their union. I doubt that one can unify assumptions except in very well-defined cases. If one could, then PT Barnum could rule the world. (PT Barnum: "you can fool some of the people all of the time, and all of the people some of the time, but you can't fool all of the people all of the time.") In general, spreading the idea of unifying assumptions (or "worlds") is pernicious. One makes a nearly impossible idea sound simple and natural. >Badly designed code is mearly [sic] a collection of statements that do >something without any underlying reason beyond the world of the programming >language itself. The result is code that can't be extended or maintained >and is full of the kinds of bugs that come from a lack of a reasoned structure. I'm not sure that code requiring almost no maintenance requires grotesque machinery to protect the maintainer. If the product requires very little maintenance, you could pay a qualified engineer to repair it. A saying: when a Japanese product has a problem, the manufacturer sends an engineer. When a American product has a problem, the manufacturer sends a FAX. Maybe this means that the American product is better designed --- its maintenance only requires a FAX. But I doubt it. Think of how many FAXes get sent, and how much time the customer loses reading them. Repetez: the best products require almost no maintenance. Code is a product. Toni Toni Wuersch (CIBA-GEIGY Scientific Computing Center) c/o CIBA_GEIGY AG, R-1032.3.32, P.O.Box, CH-4002 Basel, Switzerland UUCP: warw@cgch.UUCP ( ..!mcvax!cernvax!cgch!warw ) Internet: warw%cgch.uucp@uunet.uu.net Phone: (+41) 61 697 31 43 BITNET: warw%cgch.uucp@cernvax.bitnet Fax: (+41) 61 697 32 88 First order logic disclaimer: `forall x ( "Toni wrote x" --> "CIBA-GEIGY endorses x" )' is unsatisfiable.