From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,9a0ff0bffdf63657 X-Google-Attributes: gidfac41,public X-Google-Thread: 1108a1,9a0ff0bffdf63657 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,4b06f8f15f01a568 X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,9a0ff0bffdf63657 X-Google-Attributes: gidf43e6,public From: mfinney@lynchburg.net Subject: Re: Software landmines (loops) Date: 1998/09/10 Message-ID: X-Deja-AN: 389584217 References: <6rfra4$rul$1@nnrp1.dejanews.com> <35DBDD24.D003404D@calfp.co.uk> <6sbuod$fra$1@hirame.wwa.com> <35f51e53.48044143@ <904556531.666222@miso.it.uq.edu.au> <6sgror$je8$3@news.indigo.ie> <6sh3qn$9p2$1@hirame.wwa.com> <35ece7ee.1489912@news.erols.com> <905134925.147581@iris.nyx.net> <35f34bbd.7903825@news.erols.com> <35f44e7d.8607016@news.erols.com> <35F5C625.A99336AC@ist.flinders.edu.au> <35F70F41.67AC4347@earthlink.net> X-Complaints-To: Abuse Role , We Care X-Trace: newsread.com 905389547 208.229.14.206 (Wed, 09 Sep 1998 21:05:47 EDT) Organization: Lynchburg.net (lynchburg.net) Reply-To: mfinney@lynchburg.net NNTP-Posting-Date: Wed, 09 Sep 1998 21:05:47 EDT Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada Date: 1998-09-10T00:00:00+00:00 List-Id: In <35F70F41.67AC4347@earthlink.net>, Charles Hixson writes: >The problem is that with the limited range of structures comes a limited >range of errors that can occur. The se/se school is limiting a >particular set of errors: If you use their approach you WILL NOT make >the errors that they have excluded. On the other hand, advocates of, >e.g., early returns, feel that by testing for errors early you can >remove complications from the code, and thus remove a DIFFERENT source >of errors. The two are incompatible. You can choose which you consider >more important, but you only get to pick one. The use of non se-se control structures to match the problem's "structure" is really an important concept. The use se-se did originate to reduce the number of errors, and as a first attempt, was a very good thing. The problem is that the first attempt at anything is almost never the "correct" answer. I believe that what we need to do is to study many, many programs and find out what the "natural" structure of the programs are (in the small scale). Then we need to design control structures to match each of the patterns that we find. There are, of course, an infinite number of patterns but we can limit ourselves to those which we find repeated on a somewhat regular basis. Many authors have looked at control structure variations such as the n 1/2 loop problem. There are others such as exit from a binary tree insert which has three different exit conditions with different actions occuring at each exit (add left, found it, add right). Knuth introduced situation labels to assist with problems like this. I have made a study of many control structures for years as a hobby and virtually all of them are tree-structured, but they are not structured. It is clear that many people feel that the original se-se structures are just too limiting, but they still want "structure". When considering control structure improvements, the right place to put the line seems to be tree- structured instead of structured. It gives just the right amount of flexability and still maintains a regular program structure. As far as "provability" is concerned, any of the "regular" control structures can be constructed from the se-se control structures with the possible addition of extra flags and tests. That means that if se-se is provable then these additional control structures are also provable -- and probably in a much more direct manner. In a different post, I have a minimum set of control structures from which all tree-structured code can be built. I'm sure that nice properties for those can be found which assist proving program correctness. However, proving program correctness is kind of a moot point at the moment because nobody can do it for any kind of a sizeable program. I have hopes that the advances in theorem proving combined with OO built using preconditions/invariants/postconditions from the ground up could give major advances in proving program correctness. The use of program transformations which start with a predicate and then use transformations which provably retain correctness to convert the predicate, step by step, to an executable program can also assist in that area. I feel that combining all of these things together (better control structures, OO grounded with invariants and program transformations) can result in large programs which are provably correct -- but not by hand. As always, the tedious details are where computers are useful. Even Robert agrees that the use of a particular se-se control structure should be based on costs and benefits. Of course, the major problem with that is that nobody knows what the costs and benefits really are when compared to slight variations such as exit from the middle of a loop. We all believe that there are significant benefits from the use of structured programming compared to the original unstructured programming. But there is no evidence that I have seen that the original structured programming is better or even as good as some of the "improvements" in control structures that have been invented over the last 20 years or so. I personally believe that these control structures *do* improve things by reducing errors both in coding and in maintenance because they improve the programmer's ability to reason about the program in a "natural" manner. However, that is just my opinion and is only backed up by my experience (which is around 28 years or so, perhaps not quite as long as Robert's, but hopefully just as good ). I do know that I apply the principles above as much as possible (and would do a lot more if I had the computer support I need) and the results have been very good -- but perhaps the results would be just as good anyway. There you get the question of the programmer vs the process. Michael Lee Finney