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: 103376,4b06f8f15f01a568 X-Google-Attributes: gid103376,public From: Matthew Heaney Subject: Re: Software landmines (was: Why C++ is successful) Date: 1998/08/30 Message-ID: #1/1 X-Deja-AN: 386109653 Sender: matt@mheaney.ni.net References: <6rnh8p$dno$1@nnrp1.dejanews.com> <6rs6is$6ck$1@nnrp1.dejanews.com> <6s6h4a$ha9$1@nnrp1.dejanews.com> NNTP-Posting-Date: Sun, 30 Aug 1998 02:27:17 PDT Newsgroups: comp.lang.ada Date: 1998-08-30T00:00:00+00:00 List-Id: dennison@telepath.com writes: > > Saying that strong typing gets in your way is a little like saying that > > using a speedometer gets in your way, because you can't see how fast the > > wheel is rotating. > > My point exactly. Why doesn't this same logic apply to goto's vs. more > structured flow control statements? The premise to your argument is that goto-less ("more structured") control flow statements are better then using a goto directly. What we are debating is whether to accept this premise. My only criterion for goodness is whether something makes the program easier to understand. Is the program more or less complex by using the statement? This question can only be answered by the human programmers that write programs using the statement. Bohm-Jacopini showed that only 3(?) constructs were necessary to implement all control flow. But so what? They weren't saying don't use other constructs. In one of his books, Dijkstra spoke of minimizing the "intellectual distance" between the problem and its solution (in the form of a computer program). If using a goto makes the implementation of an algorithm simpler, then I'm all for it. The goal IS "make the program simple to understand." The goal is NOT "don't use a goto." When I write a state-based abstraction - for example, just about any task - then the first thing I do is write a little state transition diagram. This is my problem. Now I want to transform this problem into a solution. To reduce translation error, I want be able to translate the STD more or less directly into program text. The _simplest_ way, in my opinion, is to use a goto. This allows me to easily navigate among the states, directly, just like in the STD. Now this doesn't mean a solution using "more structured" control flow statements isn't possible. Of course it's possible. But what we're debating is whether this alternate solution is better than the goto. What is deemed "better" is a social phenonmenon. God did not decide that goto-less control flow is better. You did, by making a personal choice. Other programmers (like me and Robert) have made a different choice. One can come up with a theory about whether something is better, but any theory must stand the test of observation. Any theory which contradicts observation should be thrown out. Any theory about using (or not using) a programming construct needs to be tested against observation, by performing an empirical study that measures the defect rates of programmers using the construct. If theory says use a construct, but observation reveals that programmers who use the construct produce more errors, then the theory needs to be thrown out. For example, there's a pernicious myth that exiting (or returning) from the middle of a loop is bad, and that the only proper way to write a loop is to state the termination condition explicitly, as a predicate appearing at the top of the loop. This theory was indeed put to the test, and guess what? Programmers using a test-and-exit from the middle of the loop produced fewer errors than those programmers who tried to put the test at the top of the loop. The researchers found that the exit-from-the-middle construct had a better "cognitive fit" than the other constructs. If you want to read the gory details, the article is Cognitive Strategies and Looping Constructs: An Empirical Study Soloway, Bonar, Ehrlich CACM, Nov 83, Vol 26, No 11, p 853-860 The goodness of a language construct should not be determined by doctrinaire computer scientists or mathematicians. The only thing that matters is whether working programmers think it's easier to understand, and whether by using the construct programmers inject fewer errors into the code. I think it was Stroustrup who said, "Programming is a human activity. Forget that, and all is lost."