home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / alt / msdos / programm / 3054 < prev    next >
Encoding:
Internet Message Format  |  1992-12-30  |  2.9 KB
  1. Xref: sparky alt.msdos.programmer:3054 comp.os.msdos.programmer:11711 comp.sys.ibm.pc.programmer:709 comp.lang.c++:18585 comp.lang.c:19059
  2. Newsgroups: alt.msdos.programmer,comp.os.msdos.programmer,comp.sys.ibm.pc.programmer,comp.lang.c++,comp.lang.c
  3. Path: sparky!uunet!munnari.oz.au!metro!extro.ucc.su.OZ.AU!maxtal
  4. From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
  5. Subject: Re: Newbie Wants Advice on C-Programming
  6. Message-ID: <1992Dec31.043002.24014@ucc.su.OZ.AU>
  7. Sender: news@ucc.su.OZ.AU
  8. Nntp-Posting-Host: extro.ucc.su.oz.au
  9. Organization: MAXTAL P/L C/- University Computing Centre, Sydney
  10. References: <1hdpluINN1lv@agate.berkeley.edu> <1992Dec25.070024.15672@grebyn.com> <FISCHER.92Dec30223532@orange.iesd.auc.dk>
  11. Date: Thu, 31 Dec 1992 04:30:02 GMT
  12. Lines: 52
  13.  
  14. In article <FISCHER.92Dec30223532@orange.iesd.auc.dk> fischer@iesd.auc.dk (Lars Peter Fischer) writes:
  15. >
  16. >>>>>> "Michael" == Michael Malak (malak@grebyn.com)
  17. >
  18. >Michael>    1) It has structured syntactic blocks for constants, types and
  19. >Michael>       variables.
  20. >
  21. >Which is not much of an advantage. Look at all the pain Knuth has gone
  22. >through to work around it.
  23.  
  24.     Could you explain? Seems to me that the simple concept
  25. of nesting the symbol table so that symbols go out of scope
  26. at the end of the block is very nice.
  27.  
  28. >
  29. >Michael>    2) It has nested procedures.
  30. >
  31. >Sound like a neat idea but isn't a big deal in practice. Modules in
  32. >much better. If you keep your modules (files in C) small, and keep
  33. >functions local (static) you rarely need nested procedures. Note that
  34. >Wirth is abandoning the idea, too.
  35.  
  36.     Dont quite agree. Many 'mess-arounds' in C could be avoided
  37. if nested proceedures were supported. C's failure to provide them
  38. possibly results from being designed with archaic architectures
  39. in mind.
  40.  
  41.     Functional decomposition is a valid technique in my opinion.
  42. So is partitioning the state space with objects. Forcing the programmer
  43. to use data decomposition because functional decomposition is not
  44. properly supported is against the spirit of C++ in my opinion.
  45.  
  46. >
  47. >Michael>    3) Most importantly, the good structured programming professors
  48. >Michael>       wouldn't be caught dead teaching C (biggotry in my opinion).
  49. >
  50. >A professor that believes the notion of structured programming is tied
  51. >to a specific language should be teaching gardening instead.
  52. >
  53.     But C cannot be used easily for functional decomposition
  54. because it doesn't provide proper support for nested functions.
  55. Structured design may not be tied to a specific language,
  56. but structured programming in a structured language is certainly
  57. easier than in a non-structured one. Do you really want to
  58. write code in the old BASIC (you know, the one with line numbers
  59. and GOSUB without parameters?)
  60.  
  61. -- 
  62. ;----------------------------------------------------------------------
  63.         JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
  64.     Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
  65. ;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
  66.