Re: Peter Chen and Charles Bachman

Brian Inglis <Brian.Inglis_at_SystematicSw.Invalid> wrote:

>On Tue, 25 May 2004 19:01:45 -0700 in comp.databases.theory, Gene
>Wirchenko <genew_at_mail.ocis.net> wrote:
>
>>Leandro Guimaraens Faria Corsetti Dutra <leandro_at_dutra.fastmail.fm>
>>wrote:
>>
>>>Em Thu, 20 May 2004 16:00:37 -0700, Gene Wirchenko escreveu:
>>>
>>>> Leandro Guimaraens Faria Corsetti Dutra <leandro_at_dutra.fastmail.fm>
>>>> wrote:
>>>>
>>>>>Em Wed, 19 May 2004 23:22:34 -0700, Gene Wirchenko escreveu:
>>>>>
>>>>>> I see no advantage to
>>>>>> being stuck with having to do something one way only.
>>>>>
>>>>> Have you ever grokked _GOTO considered harmful_, or Codd's
>>>>>rules?
>>>>
>>>> The former most definitely; the latter, not yet. There are times
>>>> when a well-placed goto will aid program clarity.
>>>
>>> Only if the language is poor.
>>
>> You are too doctrinaire for me.
>>
>> One of the fast sorts has a structure whose symmetry wrt to two
>>variables is obvious with a couple of gotos, but which is lost with
>>structured code.
>
>Are you perhaps referring to the quicksort partitioning step?
>If solution symmetry is lost in "structured" code, blame the
>programmer's poorly structured thinking, and not the poorly structured
>code.

     When the code is structured the symmetry is not in the code. The two variables appear quite different in use. Do you have a version that retains the symmetry IN THE CODE?

>Some intuitively grok structure, some find structure in the spaghetti,
>and many have structure thrust upon them.

     I am in the first category, have had to deal with the second, and shudder at looking at code from someone in the third category.

>Most CS students are probably in the latter camp; they've been told:
>don't use GOTO, it's bad, which is a useful first order approximate
>model.

     An excellent one, but after a year or so, they should be told about goto.

>Students probably haven't read Bohm and Jacopini, or Dijkstra, Dahl,
>and Hoare, to find out why the GOTO should be unnecessary for writing
>portable code in a well designed and implemented language; how well
>structured designs can lead to better implementations; and why it's
>okay to break the rules when language design or implementation fall
>short of the ideal.

     That is why I would wait a year. They would have a body of code that did not need goto.

>Exercises in restructuring (aka refactoring) real life examples of
>spaghetti code (and data) should be mandatory to teach students why
>well structured code is better than poorly "structured" code or
>unstructured spaghetti code.

     After the year, when they can appreciate it.

>You can learn a lot about structure by studying code with GOTOs and
>poorly "structured" code to find where the implementation breaks the
>structure of the solution, and how to structure a better design and/or
>implementation.

     Quite. If you have to maintain such code, you can go [|not so] quietly crazy, too.

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:

     I have preferences.
     You have biases.
     He/She has prejudices.