chip@dartvax.UUCP (Brig ) (12/04/83)
A recent correspondent claimed that strong-typing was necessary to prevent buggy programs. That is, I think, its official aim. There is a lovely, high-level language in the world called SETL. It comes from NYU and was Ada's first implementation language. One of its inventors was asked about CLU, Alphard, and the like. "They make it hard to write incorrect programs," he said, "but SETL makes it easy to write correct programs." So, when defending strong typing to the death, stop and think: is this the BEST way of writing clear, bugless programs? Or has the joy of Calvinism overcome all reason?
rpw3@fortune.UUCP (12/14/83)
#R:dartvax:-47200:fortune:15100003:000:3724 fortune!rpw3 Dec 14 03:21:00 1983 As one who used to use BLISS a lot, I agree. I much prefer a language that is easier to use right, than one that is hard to use wrong. The latter kind are generally terribly hard to use right, either. (I'm curious to see "Turing".) I liked BLISS. Compared to the choices on the PDP-10 in those days (1971), it was a winner. At a conference on machine-oriented higher-level languages (published by North Holland), Wulf said that even though BLISS was typeless, the errors they saw were NOT very often type errors. More often, it was logical errors in algorithms, etc. ***FLAME ON*** As far as strong-typed compilers go, NO compiler less than human will catch logic errors, and in fact, my experience is that type-checking "support" encourages people not to read their own code after it passes 'lint' (or eq.), much less read anybody else's code. The place for type-checking, in fact the place for compiling at all, is AFTER the program has been printed on paper (yes!), desk checked, walked through by others, and found "perfect". THEN submit it to the auto-test to catch that one last careless typo. The other way around (normal UNIX practice) is to hack it until it compiles, then hack it until it passes 'lint', then (maybe) get somebody to look at the (25-line) screen over your shoulder if there are still glaring non-functionalities. Such a procedure guarantees that the program will be as buggy as a late afternoon picnic. As long as it is easy to get the compiler to do what you want it to do, and the resulting (source) code is easy for others to read, the fine details of the language and its typechecking are irrelevant. A careful craftsman can use any good tool well; a poor one can break the finest tool. In fact, the tools that are "comfortable" to the average craftsman may, just may, be tools that actively impede quality results. Dijkstra's "...Truths That Might Hurt" are no less true for being painful. It is time we quit looking under the light of fancy languages/tools and faced the dark of ignor-ance of our real problem: the lack of rigorous disciplines to accomplish our tasks. We used to criticize the hardware guys, because their stuff was simpler. These days, the hardware people build more complicated programs (VLSI chips) with fewer bugs. Just goes to show that a very slow complier (6-10 weeks per "compile") can actually improve quality! Large (>200 chip) PC boards are routinely turned out on first "compile" (PC layout) with no errors by those skilled in the art. Can we find no method of achieving the same? A few methods have worked fairly well for me, such as those noted above (desk-checking, etc.) plus such things as designing all data structures before any code, etc. Others are mentioned in such highly recommended (by me) books as DeMarco's "Controlling Software Projects: Management, Measurement, and Estimation" (Yourdon Press 1982), and Gries's "Science of Programming" (Springer-Verlag 1981), to name a couple. They are no secret. All such methods are somewhat painful to get used to, as they work by cutting our speediness so as to give our intelligence a chance to work. It is much more fun to "quick! kill the next bug!" than it is to not have any in the first place. The truth is, by the time a program is released to its users, fewer than half of the defects will have been found (ref: DeMarco, p.226ff). Another quote from the same source: "When you see a roach climbing up the wall of a restaurant, you don't say, 'There goes THE roach', you say, 'The place is infested'." ***FLAME OFF*** Rob Warnock UUCP: {sri-unix,amd70,hpda,harpo,ihnp4,allegra}!fortune!rpw3 DDD: (415)595-8444 USPS: Fortune Systems Corp, 101 Twin Dolphins Drive, Redwood City, CA 94065