Xref: utzoo misc.misc:6162 comp.misc:6106
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wasatch!cetron
From: cetron@wasatch.utah.edu (Edward J Cetron)
Newsgroups: misc.misc,comp.misc
Subject: Re: The "evil" GOTO (Was: 25 Years of BASIC)
Message-ID: <1827@wasatch.utah.edu>
Date: 15 May 89 00:49:49 GMT
References: <1791@ubu.warwick.UUCP> <1436@onion.reading.ac.uk> <1814@ubu.warwick.UUCP> <24044@agate.BERKELEY.EDU> <2861@cps3xx.UUCP> <1745@wasatch.utah.edu> <46@telxon.UUCP>
Organization: Morrison-Knudsen, Industrial Buildings Division, SLC, UT
Lines: 53

In article <46@telxon.UUCP> gorpong@telxon.UUCP (Gordon C. Galligher) writes:
>In article <1745@wasatch.utah.edu> cetron@wasatch.utah.edu (Edward J Cetron) 
<  writes:
<<	This entire GOTO debate seems to be indicative of the quality of 
<<programmers currently available today.  To them, STRUCTURE is EVERYTHING.
<<They've even forgotten (or never learned WHY structured concepts are good).
<<But MOST IMPORTANTLY the forget that somewhere, somehow, a computer HAS to
<<execute these programs. 
<<I would
<<rather have a clearly written program (structured or not) which accomplishes
<<what the PROGRAM is intended to do, without excess baggage and }'s JUST to
<
<So you really don't care if anyone else can read this code to manage it?  

Didn't I say clearly written? Maintainable code can be written which DOES NOT
have lots of {}'s with no purpose but to meet some example of structured
programming style, not for clarity.

<Believe it or not, but 80% of all code is in the maintenance stage ...
<...the job, then you might as well advocate just throwing the program out and
<rewrite it to do the new tasks because it would be faster to do that  than to
<try to read the code that the person wrote.

I realize that maintainabilty is important, but the type who uses structured
techniques for the sole purpose of using them is likely to also to write code
which is poorly maintainable for other reasons. 

<<	Maybe that's why I only hire hardware oriented people.  You can teach
<<a h/w person to program, but most s/w types are confused by hardware.
<
<I'm not going to TOUCH this!! :-).

Teaching s/w is an exercise is logic, organization, problem solving etc...
Most students have background in these concepts h/w or s/w.  Teaching hardware
usually requires a more involved background in some EE, etc....  I didn't say
that the s/w are any less intelligent, just less knowledgeable.

<
<<	Sorry for the flame, I'm just tired of interviewing smug new CS
<<students who know nothing about reality and using the right tools for the
<<job.  They make great followers, but we desparately need thinkers and leaders.
<
<Have you ever thought about trying to HELP these "smug new CS students" by
<giving them some of your ideas, or are you too tied up trying to rewrite soft-
<ware you want to reuse? :-)

No, between teaching, lecturing, assisting new students, managing a software
team to 'do it write', and taking on the brain-damaged instructors who created
these students, I don't even get to write much code at all anymore.  Besides,
I much prefer recycled software to re-used software :-)

-ed cetron
cetron@wasatch.utah.edu