Warp wrote:
>   Dijkstra advocated structured programming as a replacement for the
> heavily "goto-based" programming of the time. 

Actually, this discussion lead to an interesting insight (for which I 
thank you).

The real problem with "goto" is not so much the "goto" as the "come 
from". I.e. you see a label, and anything in scope of that label might 
branch there. In something like COBOL or (dartmouth) BASIC, anywhere in 
the entire program might branch to any label in the entire program.

If you refactor a program to take some commonality out of a handful of 
functions, and that commonality doesn't really stand on its own, you 
haven't really structured it. You've just used a function as a goto.

I have a bit of program that takes an audio sample and tries to find a 
match. It does some stuff up front, and then depending where it looks 
for it, it makes different decisions to see if it "matches". It may or 
may not take timezones into account. It may or may not take time into 
account at all. It may or may not take the character set of the returned 
metadata into account, or the source of the metadata.  Depending what we 
match it again, there's four or five or six (depending on how you count) 
matching routines. I remember at one point wishing I had the FORTRAN 
"entry" declaration available. :-)

In any case, when I refactored the part that actually ran on *that* 
particular sort of computer, I actually wound up with a routine that's 
pretty much meaningless outside that matching mechanism, and which gets 
a whole bunch of variables that used to be local and don't make any 
sense as independent parameters (e.g., the logging information so far 
onto which I append more heuristic results so I can tell why it does or 
doesn't work after the fact, which of the fault-tolerance servers were 
queried and whether the first one worked or not, which column of the 
database to pull character set information out of, etc.) Stuff going in 
and out which you'd never have put in there had you not ripped the 
routine out of three copy-and-paste(*) functions and modularized it.

That's really not structured programming. That's three functions all 
using "goto" to go to the start of that function and passing any locals 
it uses in and out as parameters.  It's just another way of writing a 
goto, and it really doesn't clarify the code any as you might otherwise 
expect from "lifting common functionality into a subroutine."

Interesting.



(*) That's maybe the fourth or fifth time here I've changed 
"cut-and-paste" to "copy-and-paste" on this forum. I'm not sure whether 
to thank Warp for correcting me or be annoyed at him. ;-)

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message