home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / edu / 1460 < prev    next >
Encoding:
Internet Message Format  |  1992-09-01  |  4.0 KB
  1. Xref: sparky comp.edu:1460 comp.lang.fortran:3351 comp.lang.misc:2857 comp.arch:9139 sci.math:10820
  2. Path: sparky!uunet!olivea!decwrl!purdue!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin
  3. From: hrubin@pop.stat.purdue.edu (Herman Rubin)
  4. Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc,comp.arch,sci.math
  5. Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
  6. Message-ID: <Btx4vF.Jx6@mentor.cc.purdue.edu>
  7. Date: 1 Sep 92 21:26:02 GMT
  8. References: <1992Aug31.170849.11927@mprgate.mpr.ca> <1992Aug31.195540.13074@ctr.columbia.edu> <1992Sep1.115849.13522@relay.nswc.navy.mil>
  9. Sender: news@mentor.cc.purdue.edu (USENET News)
  10. Organization: Purdue University Statistics Department
  11. Lines: 63
  12.  
  13. In article <1992Sep1.115849.13522@relay.nswc.navy.mil> bwallet@apssgi.nswc.navy.mil (Brad Wallet) writes:
  14. >In article <1992Aug31.195540.13074@ctr.columbia.edu>, shenkin@avogadro.barnard.columbia.edu (Peter S. Shenkin) writes:
  15.  
  16.             .................
  17.  
  18. >As I have said previously, you are getting computer scientists and 
  19. >software engineers confused.  Software engineering is the discipline
  20. >concerned with writing good code.  Software engineers study the design
  21. >process, design philosophy, testing, life style management, reliability,
  22. >and all that other stuff that defines good code.
  23.  
  24. >Computer science compares to software engineering much as math and physics
  25. >compare to the various engineering fields.
  26.  
  27. Software engineering is not that relevant in general.  What is relevant is
  28. the translating of the problem to be computed into the collection of bits
  29. which the machine can understand to accomplish the task.  This involves
  30.  
  31.     Knowing the algorithmic processes which can be applied, their
  32.     strengths and weaknesses, and what happens to them on the particular
  33.     machine when they are translated using the available languages.
  34.  
  35.     Evaluating the costs of using the tools.
  36.  
  37. If a procedure can use some of the machine instructions and the languages
  38. available to the programmer cause code to run considerably slower because
  39. the languages cannot use those instructions, the languages are inadequate. 
  40. No amount of software engineering, or compiler optimization, and get around
  41. this.  It is this feature which can make major differences in the relative
  42. speeds of computing on different machines.
  43.  
  44. The CS curricula exascerbate the problem by indoctrinating the student in
  45. the attitude that the machine instruction set is not to be considered in
  46. normal programming.  The design people then continue the process by producing
  47. hardware manuals in which the description of the operations, and considerations
  48. for producing good code, is written so as not to use any structure, and thus
  49. takes several times as many pages, and is hard to understand.  And the only
  50. adequate language to use the machine is an assembler language with an 
  51. atrocious syntax.  Often the HLLs do not have convenient ways of including
  52. the instructions.
  53.  
  54. There can, and should, be interaction at compile time between the compiler
  55. and the programmer.  The compiler also should be able to suggest rearranging
  56. machine instructions, not just the output from HLLs.  The translation of 
  57. other HLL-type operations into machine code should be essentially the same
  58. as that of such standard operations as + and *.  These can be provided, and
  59. should.
  60.  
  61. Current software seems almost designed to prevent the user from doing anything
  62. the HLL designers did not think about.  Then hardware leaves out what even a 
  63. fairly intelligent user will use, which the software does not get at.  And so
  64. it goes.
  65.  
  66. What we are teaching the CS students, and even the software engineers, is 
  67. essentially the mistake made in teaching methods without understanding in
  68. mathematics and statistics.  Someone who has only learned a particular
  69. collection of methods is extremely unlikely to consider anything not in
  70. that particular bag of tricks.  Training is not education.
  71. -- 
  72. Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
  73. Phone: (317)494-6054
  74. hrubin@pop.stat.purdue.edu (Internet, bitnet)  
  75. {purdue,pur-ee}!pop.stat!hrubin(UUCP)
  76.