home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / edu / 1378 < prev    next >
Encoding:
Text File  |  1992-08-27  |  5.0 KB  |  101 lines
  1. Newsgroups: comp.edu
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!agate!linus!linus.mitre.org!crawford
  3. From: crawford@church.mitre.org (Randy Crawford)
  4. Subject: Re: programming languages, education, unanswered questions, loose threads
  5. Message-ID: <1992Aug27.164424.249@linus.mitre.org>
  6. Sender: crawford@church (Randy Crawford)
  7. Nntp-Posting-Host: church.mitre.org
  8. Organization: The MITRE Corporation, McLean, VA
  9. References:  <1992Aug26.170100.6270@iscsvax.uni.edu>
  10. Date: Thu, 27 Aug 1992 16:44:24 GMT
  11. Lines: 88
  12.  
  13. In article <1992Aug26.170100.6270@iscsvax.uni.edu>, bohy6489@iscsvax.uni.edu writes:
  14. > I had a programming languages course with Bruce MacLennan while at the
  15. > University of Tennessee.  He made three statements which (I think) contribute
  16. > very nicely to this thread during the course of that semester:
  17. > 
  18. >         1) "Every language since FORTRAN, with the possible exception of
  19. >             functional programming languages, is just warmed-over FORTRAN."
  20.  
  21. True also for APL and forth?
  22.  
  23. >         2) "A programming language is defined as a language in which you can
  24. >             write *any* program."
  25.  
  26. No doubt that would include Lotus 123 macros and C shell scripts.  I don't 
  27. think that's a particularly useful statement except to an academic who doesn't 
  28. have to program in this "language".  It smacks of a preoccupation with theory
  29. and turing machine equivalency.
  30.  
  31. > I *still* maintain (as someone else has pointed out) that it is *not* the
  32. > language which encourages bad programming style.  
  33.  
  34. Whoa.  Languages differ greatly in what they _allow_ the programmer to write.
  35. And because bad code is often a matter of poor programming style, bad C or bad
  36. FORTRAN is much more common than bad Pascal or bad Modula where poor style is
  37. more difficult.  I would agree with you, however, if you changed the word 
  38. "encourages" to "guarantees".
  39.  
  40. > With the possible exception
  41. > of LISP (which IMHO is unreadable), anyone can write a readable program in any
  42. > language.  
  43.  
  44. I think you are objecting to more than just parentheses when you deride Lisp. 
  45. Functional programming languages are an acquired taste.
  46.  
  47. > So the argument of what language should we use to teach CS is, in some sense,
  48. > rather pointless.  We all have our preferences.  I too think that C lets you do
  49. > some *very* ugly things.  I like Pascal and FORTRAN.  Not because they are what
  50. > I learned (I learned BASIC first), nor even because they are what I used most
  51. > (though they are).  It is almost an asthetic thing for me.
  52.  
  53. Teaching programming is more than teaching style.  If the programming language
  54. cannot support structured types, then you cannot use it to teach structured 
  55. types (or it becomes unnecessarily difficult)..  The same holds for data 
  56. abstraction, abstract data types, advanced data constructs (linked lists, trees, 
  57. heaps, stacks, etc), recursion, functional programming, etc.  In my opinion, 
  58. FORTRAN, and BASIC are poor choices for such instruction, and C suffers for the 
  59. poor machine abstraction it affords.  Ada is too complex and few compilers are
  60. available/affordable on personal computers.  The same is true for Common Lisp. 
  61. Pascal is not ideal in that few professionals  use it (like Algol or PL/1 or 
  62. scheme or ML).  The same holds for Modula 2. 
  63.  
  64. I think the conclusion among most academics who care is: teach programming in a
  65. language which teaches good stylistic form and supports the constructs needed 
  66. to learn more about computer science.  No language can be all things, but some 
  67. are simply inappropriate to certain tasks.
  68.  
  69. (...well reasoned comments deleted...)
  70.  
  71. > What sickens me most is that individuals with the knowledge and capability to
  72. > teach are being pushed out of schools in favor of those with a knack for
  73. > publishing (but could not teach their way out of a paper bag).  *THIS* is the
  74. > educational crisis in America, at least in post-secondary schools...
  75. ... 
  76. > 
  77. > ps - some other statements from Programming languages with MacLennan:
  78. > 
  79. >         "PL/I is the swiss-army-knife approach to programming language design."
  80. > 
  81. >         "After publishing the second edition of my book, I quit doing research
  82. >          in programming language design.  There's nothing new."
  83. > 
  84. >         (you could tell by the way he taught the course that he had lost much
  85. >          interest in the subject, I'll tell you that)
  86.  
  87. Sounds like it. 
  88.  
  89. Maybe we should divide universities the way some have suggested we divide
  90. college sports: college athletics could become professional and non-academic,
  91. and college research could follow its own non-academic track as well.  Let the
  92. graduate programs become separate entities from undergrad, with different profs
  93. and a different agenda (more applied).  Measure the undergrad profs as teachers
  94. and contributors to the applied sciences.  Leave the theorists to write theory
  95. and to produce other theorists.
  96. -- 
  97.  
  98. | Randy Crawford        crawford@mitre.org        The MITRE Corporation
  99. |                                                 7525 Colshire Dr., MS Z421
  100. | N=1 -> P=NP           703 883-7940              McLean, VA  22102
  101.