home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / edu / 1382 < prev    next >
Encoding:
Internet Message Format  |  1992-08-27  |  6.6 KB
  1. Path: sparky!uunet!cs.utexas.edu!sdd.hp.com!ux1.cso.uiuc.edu!news.iastate.edu!iscsvax.uni.edu!bohy6489
  2. From: bohy6489@iscsvax.uni.edu
  3. Newsgroups: comp.edu
  4. Subject: <None>
  5. Message-ID: <1992Aug27.145915.6303@iscsvax.uni.edu>
  6. Date: 27 Aug 92 14:59:15 -0500
  7. References: <1992Aug26.170100.6270@iscsvax.uni.edu> <1992Aug27.164424.249@linus.mitre.org>
  8. Organization: University of Northern Iowa
  9. Lines: 116
  10.  
  11. In article <1992Aug27.164424.249@linus.mitre.org>, crawford@church.mitre.org (Randy Crawford) writes:
  12. > True also for APL and forth?
  13.  
  14. Seems to me he said that APL is a functional programming language.  And he 
  15. never said *anything* about forth either way.  Then again, in all fairness the
  16. statement was quoted somewhat out of context (but not really).
  17.  
  18. > No doubt that would include Lotus 123 macros and C shell scripts.  I don't 
  19. > think that's a particularly useful statement except to an academic who doesn't 
  20. > have to program in this "language".  It smacks of a preoccupation with theory
  21. > and turing machine equivalency.
  22.  
  23. Actually, he *did* include macros and shell scripts as programming languages. 
  24. But you're right, he *is* quite preoccupied with theory.  In his defense, he
  25. wrote a heckuva text on language design, which many consider(ed) to be *the*
  26. programming languages text.  All in all, though, I found I was able to be
  27. interested in the things *he* was interested in throughout the semester. 
  28. Unfortunately, this was very seldom programming languages.
  29.  
  30.  
  31. >  
  32. >> I *still* maintain (as someone else has pointed out) that it is *not* the
  33. >> language which encourages bad programming style.  
  34. > 
  35.  
  36. > Whoa.  Languages differ greatly in what they _allow_ the programmer to write.
  37. > And because bad code is often a matter of poor programming style, bad C or bad
  38. > FORTRAN is much more common than bad Pascal or bad Modula where poor style is
  39. > more difficult.  I would agree with you, however, if you changed the word 
  40. > "encourages" to "guarantees".
  41.  
  42. Hmmm.  I don't know.  I think that someone who writes bad code in C is going to
  43. write bad code in *any* language, at least I have been able to observe this. 
  44. In fact, I have seen some *horrible* Pascal code.  Granted, most of the
  45. problems were due to indentation (non)standards, terrible identifier naming,
  46. etc.  Okay.  Make it "languages do not *guarantee* poor programming style". 
  47. BUT, regardless of the language, many programmers do have poor programming
  48. style.  I still cling to that.
  49.  
  50. > I think you are objecting to more than just parentheses when you deride Lisp. 
  51. > Functional programming languages are an acquired taste.
  52.  
  53. I'll buy that.  Though I do have my opinions (obviously) I also attempt to keep
  54. an open mind about these things.
  55.  
  56. > Teaching programming is more than teaching style.  If the programming language
  57. > cannot support structured types, then you cannot use it to teach structured 
  58. > types (or it becomes unnecessarily difficult)..  The same holds for data 
  59. > abstraction, abstract data types, advanced data constructs (linked lists, trees, 
  60. > heaps, stacks, etc), recursion, functional programming, etc.  In my opinion, 
  61. > FORTRAN, and BASIC are poor choices for such instruction, and C suffers for the 
  62. > poor machine abstraction it affords.  Ada is too complex and few compilers are
  63. > available/affordable on personal computers.  The same is true for Common Lisp. 
  64. > Pascal is not ideal in that few professionals  use it (like Algol or PL/1 or 
  65. > scheme or ML).  The same holds for Modula 2. 
  66.  
  67. There is the school of thought that programming should be taught as a building
  68. experience, i.e. if you can do this with a limited amount of tools, you can do
  69. it with the full set.  This idea has been incorporated into whole introductory 
  70. courses at one school, to the point that the students programmed in Pascal but
  71. were forced to do everything with character variables and files.  Whether or
  72. not this holds merit, I do not know.  I do know that an awful lot of students
  73. failed that course.
  74.  
  75. I do not agree with the above...
  76.  
  77. *But* I have implemented trees using arrays.  Sure, the allocation was not
  78. *dynamic*, but the concepts were the same.  We did this as an exercise in my
  79. data structures class (even used Pascal to do it).  And there is nothing wrong
  80. with that.  It does show some of the assembly language concepts like relative
  81. addressing and even motivates them.  Kind of nice, rather than having to just
  82. except that "it works".
  83.  
  84. I see nothing wrong with teaching a course in FORTRAN to beginning students. 
  85. My taking FORTRAN really helped me be a more organized Pascal programmer.  That
  86. may be a function of the instructor I had for both courses (who, incidentally,
  87. did not have a PhD and has never published but was one hell of a *teacher*).
  88.  
  89. > I think the conclusion among most academics who care is: teach programming in a
  90. > language which teaches good stylistic form and supports the constructs needed 
  91. > to learn more about computer science.  No language can be all things, but some 
  92. > are simply inappropriate to certain tasks.
  93.  
  94. I totally agree.  Something of a contradiction with your above statement, there
  95. *are* professionals programming in Pascal.  Not a lot, but they are out there. 
  96. I think the language has something of a bad reputation as being a toy.  I have
  97. found it to be very useful for anything I have ever wanted to accomplish.  What
  98. do I know, though?  I also prefer VMS to unix.  :-]
  99.  
  100. > (...well reasoned comments deleted...)
  101.  
  102. Thanks for thinking they were well-reasoned...
  103.  
  104. > Maybe we should divide universities the way some have suggested we divide
  105. > college sports: college athletics could become professional and non-academic,
  106. > and college research could follow its own non-academic track as well.  Let the
  107. > graduate programs become separate entities from undergrad, with different profs
  108. > and a different agenda (more applied).  Measure the undergrad profs as teachers
  109. > and contributors to the applied sciences.  Leave the theorists to write theory
  110. > and to produce other theorists.
  111.  
  112. Sounds good to me!
  113.  
  114. > -- 
  115. > 
  116. > | Randy Crawford        crawford@mitre.org        The MITRE Corporation
  117. > |                                                 7525 Colshire Dr., MS Z421
  118. > | N=1 -> P=NP           703 883-7940              McLean, VA  22102
  119.  
  120. ===============================================================================
  121. Jim Bohy                                        | "If you have to ask, you'll
  122. Graduate Student - Computer Science Education   |  never know..."
  123. University of Northern Iowa                     | 
  124. Cedar Falls, IA  50614                          | - Louis Armstrong, when asked
  125. bohy@att1.uni.edu                               |   what jazz is.
  126. ===============================================================================
  127.