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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,CP1252 X-Google-Thread: 103376,ddc669e8cf09b24 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-07-15 16:33:05 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!arclight.uoregon.edu!wn13feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi.com!rwcrnsc52.ops.asp.att.net.POSTED!not-for-mail Message-ID: <3F148F30.4010602@attbi.com> From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Debugger Rant (was Re: How to debug an Ada program) References: <254c16a.0307110505.463b1cc0@posting.google.com> <3F0ED3FF.65497AEE@raytheon.com> <3F0F04F1.7080903@attbi.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit NNTP-Posting-Host: 66.31.71.243 X-Complaints-To: abuse@comcast.net X-Trace: rwcrnsc52.ops.asp.att.net 1058311985 66.31.71.243 (Tue, 15 Jul 2003 23:33:05 GMT) NNTP-Posting-Date: Tue, 15 Jul 2003 23:33:05 GMT Organization: Comcast Online Date: Tue, 15 Jul 2003 23:33:05 GMT Xref: archiver1.google.com comp.lang.ada:40311 Date: 2003-07-15T23:33:05+00:00 List-Id: Alexander Kopilovitch wrote: >>Shrug! I guess I have internalized a style of programming once known as >>"Design to test." In other words, all (formal) requirements are >>testable, and you design and code from day one to make passing those >>tests as easy as possible. > While being absolutely true, this is surprisingly hard to remember. > Every time when I read this position I wholeheartly agree with it; > moreover, several times I tried it (at least partially) in practice, > and in each case a reward was excellent... and nevertheless, I'm unable > to keep it in mind and apply regularly. And I know well that I'm not > alone with this strange kind of "disability". Why it is happened, and > how one can "internalize this style of programming" (using your words) ? The answer to that is easy. When I sit down to write even a short program, I take out a piece of paper, or open Notepad, or whatever, and start doing requirements. All it takes to internalize design to test is to recognize that even when you are doing a ten line example, THIS is faster, THIS is better, THIS is much more likely to be bug free, and THIS is much less stressful. That time with the (real or virtual) notepad, often both, IS painful. And a lot of stuff gets scribbled out as you realize that THIS IS A REQUIREMENT and you can't test it. But what you do end up with is a design where each component has an associated test, and that mapping eventually means that all sorts of if and case statements go away, or only get tested in one place. Fortunately by now, when I don't do this, I stop after about twenty lines of code and go back and do it right. I'm too old to do things the hard way. When I do this, I can knock out over a thousand lines of tested code a week. (Not counting test programs, but counting some documentation.) Comparing my work with the sort of work done by government contractors, my block comment headers are much smaller, I use more whitespace, and I accomplish about ten times as much per line of code! At first I thought this was crazy, then I took some existing code I hadn't examined, plus the requirements document--which I knew well--and rewrote a couple of units. The big difference, and it was HUGE, was that I moved a lot of checking into the interfaces (including data types), while functional decomposition propagates it down into the leaves (subprograms). > PS. After writing above words, one fantastic vision occured to me - I imagined > Web-based master class - yours, "Programming using Ada". Why not? You have > tremendous experience, rock solid skills and views, you are alive to hidden > errors and potentially dangerous solutions, you are apparently willing to > share your knowledge, and you don't like to write books and articles > (I searched the Net and found only one your article, and it was on quite > specific issue). This is extremely suitable combination for a master class > instructor. Well, I understand that one more component is needed - there > should be example problems, and it isn't a simple/pleasant task to collect > good ones. But my vision included even this side - in the form of real-world > examples from several first chapters of the book "Problem Frames: Analyzing > and Structuring Software Development Problems" by Michael Jackson. I have significant parts of the book written, some of it was presented as lectures around 1986. However, I have been seriously disabled for a while now. Right now I am up to using the computer (and up to thinking, which is more important), so I may be able to finish that book and a couple of others. -- Robert I. Eachus �In an ally, considerations of house, clan, planet, race are insignificant beside two prime questions, which are: 1. Can he shoot? 2. Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and Steve Miller.