home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / lang / cplus / 13445 < prev    next >
Encoding:
Text File  |  1992-09-09  |  3.5 KB  |  80 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!zaphod.mps.ohio-state.edu!cs.utexas.edu!csc.ti.com!tilde.csc.ti.com!mksol!mccall
  3. From: mccall@mksol.dseg.ti.com (fred j mccall 575-3539)
  4. Subject: Re: GOTO, was: Tiny proposal for named loops.
  5. Message-ID: <1992Sep9.210632.25891@mksol.dseg.ti.com>
  6. Organization: Texas Instruments Inc
  7. References: <2318@devnull.mpd.tandem.com> <rmartin.715001372@thor> <4192@papaya.bbn.com> <1992Sep2.131733.20676@terminator.cc.umich.edu> <r <KERS.92Sep4082931@cdollin.hpl.hp.com> <rmartin.715618743@thor>
  8. Date: Wed, 9 Sep 1992 21:06:32 GMT
  9. Lines: 69
  10.  
  11. In <rmartin.715618743@thor> rmartin@thor.Rational.COM (Bob Martin) writes:
  12.  
  13. >kers@hplb.hpl.hp.com (Chris Dollin) writes:
  14.  
  15. >|In what sense do you claim that ``these rules'' (by which I understand you to
  16. >|mean the usual rules of structured programming) have been ``proven'' to be
  17. >|``workable''? 
  18.  
  19. >Only that it has been proven that gotos are unecessary.  That any
  20. >algorithm can be written in terms of sequence, selection and
  21. >repetition.
  22.  
  23. And I will reiterate that the fact that something has been proven to
  24. be possible does NOT necessarily mean it is always a good idea.  As I
  25. said before, one can also implement any algorithm in terms of 'goto'
  26. and a conditional jump.
  27.  
  28. >Yes, so lets forget the psychological part and focus on the
  29. >mathematical part.  Constructiong your algorithms based on SP causes
  30. >you to separate paths that you might otherwise combine (with gotos).
  31. >This separation decouples the paths from each other, so that changes
  32. >made in one path do not affect the other paths.
  33.  
  34. The fact that goto CAN be abused is hardly a good rationale for saying
  35. that it is always bad, either.  
  36.  
  37. >We don't use SP because it makes the code "prettier" or
  38. >psychologically more gratifying.  We use it because it separates the
  39. >code fragments and reduces coupling.  This makes the code easier to
  40. >maintain.
  41.  
  42. Sorry, but that's hardly the reason.  Where is the 'coupling' or the
  43. difficulty in maintenance when goto is used for things like error
  44. handling or error returns?  Frankly, I find those Pascaloid disasters
  45. of code containing an 8-deep nesting of 'if' and flags to be a lot
  46. less readable and a lot less maintainable than code that makes
  47. judicicious use of what you would categorize as 'bad' constructs.  I
  48. don't think I'm alone in this (or even in the minority, if you want
  49. the truth).
  50.  
  51. >|There's a
  52. >|lot of empirical evidence to suggest that traditional SP ``works'', ie, that 
  53. >|for very many programming problems, they are an effective solution. [The
  54. >|evidence is the large number of programs written effectively in that style.]
  55. >|But there's also evidence that they're not *enough* -- that other control
  56. >|structures are needed for clarity -- consider
  57.  
  58. >|    * procedures
  59. >|    * FOR-loops (of various kinds)
  60. >|    * N+1/2 times loops
  61. >|    * Scheme-style use of tail-call
  62. >|    * Co-routines
  63. >|    * Higher-order functions
  64.  
  65. >|for example.
  66.  
  67. >Agreed.
  68. >The last thing I advocate is a reduction of all code to one linear
  69. >stream of sequence, selection and repetition.  
  70.  
  71. But that is exactly your rataionale for why structured programming
  72. 'works'; that it is possible to implement anything using sequence,
  73. selection, and repetition.
  74.  
  75. -- 
  76. "Insisting on perfect safety is for people who don't have the balls to live
  77.  in the real world."   -- Mary Shafer, NASA Ames Dryden
  78. ------------------------------------------------------------------------------
  79. Fred.McCall@dseg.ti.com - I don't speak for others and they don't speak for me.
  80.