home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / lang / c / 18922 < prev    next >
Encoding:
Text File  |  1992-12-28  |  4.3 KB  |  119 lines

  1. Newsgroups: comp.lang.c
  2. Path: sparky!uunet!grebyn!daily!malak
  3. From: malak@grebyn.com (Michael Malak)
  4. Subject: Pascal as road to C (was Re: Newbie Wants Advice on C-Programming)
  5. Message-ID: <1992Dec28.045707.11191@grebyn.com>
  6. Organization: Grebyn Timesharing
  7. References: <1992Dec24.172333.7339@grebyn.com> <1992Dec25.070024.15672@grebyn.com> <1992Dec27.031157.27179@mole-end.matawan.nj.us>
  8. Date: Mon, 28 Dec 1992 04:57:07 GMT
  9. Lines: 108
  10.  
  11. In article <1992Dec27.031157.27179@mole-end.matawan.nj.us> mat@mole-end.matawan.nj.us writes:
  12. >In article <1992Dec25.070024.15672@grebyn.com>, malak@grebyn.com (Michael Malak) writes:
  13. >> In article <1hdpluINN1lv@agate.berkeley.edu> faustus@ygdrasil.CS.Berkeley.EDU (Wayne A. Christopher) writes:
  14. >> >In article <1992Dec24.172333.7339@grebyn.com> malak@grebyn.com (Michael Malak) writes:
  15. >
  16. >> >> ...  I feel the following must be learned in order:
  17. >> >>   1) Pascal, with two semesters experience
  18. >
  19. >> >IMHO, Pascal has nothing useful that C doesn't have, except for array
  20. >> >bounds checking.  You you use C++ you can use a vector class that
  21. >> >gives you that.
  22. >
  23. >> Pascal has the following advantages over C:
  24. >>    1) It has structured syntactic blocks for constants, types and
  25. >>       variables.
  26. >
  27. >This is no advantage.
  28. >
  29. >A program is a model: an abstraction expressed in a representation.  The
  30. >Pascal seperation of constant, type, and variable classifies the tools of
  31. >representation; it is irrelevant within a program.  Would you require a
  32. >cook to measure out all the ingredients specified by tablespoons before
  33. >measuring any ingredient specified by cups?
  34.  
  35. No, but I would require the cook to do the following in order:
  36.     1) Purchase the ingredients
  37.     2) Prepare the courses
  38.     3) Serve the meal
  39.  
  40. In Pascal, types are derived in part from constants, and variables are
  41. derived from types and constants.  I feel that separating out into
  42. blocks these declarations is a good practice to carry over to C.  Now I
  43. believe you're arguing that it's better to clump related definitions
  44. together, even though some may be constants and others types or
  45. variables, such as:
  46.  
  47. #define BUFFER_SIZE 10000
  48. char buffer[ BUFFER_SIZE ];
  49.  
  50. I.e., do not have "constant blocks" and "variable blocks".  There are
  51. strong arguments for both ways, _but_ the Pascal organization is better
  52. than none at all.
  53.  
  54.  
  55. >>    3) Most importantly, the good structured programming professors
  56. >>       wouldn't be caught dead teaching C (biggotry in my opinion).
  57. >
  58. >Besides which, people who learn Pascal first seem to take three or four
  59. >times as long to learn how to use C pointers as people who don't learn
  60. >Pascal at all, and Pascal introduces people to some really poor habits.
  61. >
  62. >The classical Pascal expression of a loop-and-a-half cannot be written
  63. >as a while() because Pascal's expression syntax is too weak.  It cannot
  64. >be written as a loop-and-a-half because Pascal doesn't allow a `break'
  65. >from a loop.  What results is a circumlocution involving more code in
  66. >control flow and temporary variable managing than in solving the problem;
  67. >worse, one branch of an  if-then  is related to the circumlocution and
  68. >one to the problem to be solved.  This is a very bad form of incohesion:
  69. >
  70. >    if not X
  71. >        manage the loop
  72. >    else
  73. >        solve the problem
  74. >
  75. >This seems to me as damaging to potential software designers as BASIC
  76. >is claimed to be to potential programmers.
  77.  
  78. Actually, it's a good use of nested procedures.  In C, we have:
  79.  
  80. while ( TRUE )  {
  81.  
  82.            :
  83.     /* pre-check stuff */
  84.            :
  85.  
  86.     if ( X )
  87.         break;
  88.  
  89.            :
  90.     /* post-check stuff */
  91.            :
  92. }
  93.  
  94. In Pascal, we have:
  95.  
  96. pre_check_stuff();
  97.  
  98. WHILE NOT X
  99.     BEGIN
  100.  
  101.                :
  102.         /* post-check stuff */ 
  103.                :
  104.  
  105.         pre_check_stuff();
  106.     END
  107.  
  108. where pre_check_stuff() is a nested procedure.  In my opinion, the C
  109. "break" is a bad thing simply because you can have more than one per
  110. loop.  It can also lead to bugs, e.g., in nested loops.  "break" and
  111. "continue", as well as mid-function "return"s are nothing more than
  112. "goto"s in disguise.  Which is not to say that they should never be
  113. used, just that it takes experience to know when to use them.  It's a
  114. prime example of how C gives beginners enough rope to hang themselves.
  115. Someone who's suffered through the strictness of Pascal can appreciate
  116. exactly when to use "break"s, "continue"s, "goto"s, and mid-function
  117. "return"s.
  118.  
  119.