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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1108a1,9a0ff0bffdf63657 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,4b06f8f15f01a568 X-Google-Attributes: gid103376,public X-Google-Thread: fac41,9a0ff0bffdf63657 X-Google-Attributes: gidfac41,public X-Google-Thread: f43e6,9a0ff0bffdf63657 X-Google-Attributes: gidf43e6,public From: Tim Ottinger Subject: Re: Software landmines (loops) Date: 1998/09/09 Message-ID: <35F6A611.2DD979FD@oma.com>#1/1 X-Deja-AN: 389422750 Content-Transfer-Encoding: 7bit References: <35f23ce2.7649859@news.erols.com> <6snn1b$c90$1@hirame.wwa.com> <35ef7dff.24318728@news.erols.com> <35f79e53.98130474@news.erols.com> Content-Type: text/plain; charset=us-ascii Organization: Object Mentor Mime-Version: 1.0 Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada Date: 1998-09-09T00:00:00+00:00 List-Id: Matthew Heaney wrote a very fine, well-researched note here. I think it was great, except that he took "reason about..." to mean "understand...". To understand a code fragment is not the same as to reason about it. Understanding is necessary, but insufficient. From practice, we know that 'easy to understand' is desirable, but not enough. What about robustness, reentrancy, absence of race conditions, atomicity, ease of change, efficiency, etc? There is a lot more to consider than just simplicity, though we always strive to keep as much simplicity as we can stand. But this is not the point of "reasoning about" structure, either. It's about understanding the full character of the code that's written, so I'll return to the idea of 'reasoning about' structure... It's not enough to merely understand an instance of a structure of code. The goal was to do much more than this, and establish a formal or semi-formal practice... an 'engineering discipline'. When Dijkstra mentions reasoning about structures, he is talking about proofs and the like... the ability to characterize (perhaps mathematically) the structure of the code, to measure it, to draw correlations between it and other things, to prove it correct or incorrect, to apply transformations (read: optimizations) to the structure. There are patterns of structure, and there can be patterns of structure intentionally applied. I wonder if the /Nature Of Order/ won't even have us starting to drive towards some kind of formalism in code structure. I won't say that I go as far as many in the path of formalized structure, but I am increasingly appreciating the goal and the value of a more formalized way to reach it. That said, I have to plan to go restructure a little code, and catch up on reading /Structured Programming/ (Dahl, Dijkstra, Hoare, academic press "computer science classics" series, ISBN 0-12-200550-3). Bye now.