home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / edu / 1598 < prev    next >
Encoding:
Internet Message Format  |  1992-09-09  |  3.7 KB
  1. Xref: sparky comp.edu:1598 comp.lang.misc:2985
  2. Path: sparky!uunet!gatech!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.misc
  5. Subject: Re: Programmers
  6. Message-ID: <BuBuyI.G7D@mentor.cc.purdue.edu>
  7. Date: 9 Sep 92 20:15:53 GMT
  8. References: <BuBBoJ.un@rice.edu>
  9. Sender: news@mentor.cc.purdue.edu (USENET News)
  10. Organization: Purdue University Statistics Department
  11. Lines: 85
  12.  
  13. In article <BuBBoJ.un@rice.edu> sabry@rice.edu (Amr Sabry) writes:
  14.  
  15. >Many people on this net implied that whoever can write a matrix
  16. >multiplication subroutine in Fortran is a programmer.
  17.  
  18. >Based on courses here at Rice University, here is a minimum list of
  19. >*concepts* that a real programmer should know:
  20.  
  21. This has some not needed by even an excellent mathematical programmer,
  22. but is lacking in some very very basic stuff.
  23.  
  24. >- Inductive definitions.
  25.  
  26. Very necessary.
  27.  
  28. >- Parsing.
  29.  
  30. This is for the compiler writer, but not for the programmer.
  31.  
  32. >- Types: Unsafe, dynamically typed, and statically typed languages.
  33.  
  34. Also, type conversion and "type overlay" (unions).
  35.  
  36. >- Constructed data: data representation independence.
  37.  
  38. >- Lexical scope and procedures: implementing (call-by-value and
  39. >call-by-name) closures.
  40.  
  41. Call-by-name and call-by-value are far from enough; call-by-reference is the
  42. only one in Fortran.  There are other ways as well.  
  43.  
  44. >- Store: assignements, static scope versus dynamic extent, garbage collection.
  45.  
  46. Also temporary storage in registers.  A real programmer should be aware of the
  47. use of registers, especially when the compiler does not know how to do it.
  48. Also, when extra stores are actually cheaper.
  49.  
  50. >- Paramter passing techniques: by reference, copy-in-copy-out, by value.
  51.  
  52. >- Object-oriented languages: objects, classes, inheritance ...
  53.  
  54. >- Local control: Iteration via tail recursion.
  55.  
  56. And by many other means.
  57.  
  58. >- Non-local control: errors, exits, coroutines, goto ...
  59.  
  60. >- Continuations and continuation-passing style.
  61.  
  62. >- Macros: hygienic expansion.
  63.  
  64. One thing missing here is a more versatile macro expansion.  Something
  65. which includes macros, #defines, the use of types and overloading in
  66. macros, etc. 
  67.  
  68. >- Time pre-emption and light weight processes.
  69.  
  70. >A person that understands the above concepts can design or implement
  71. >any programming language. Furthermore, they can code an algorithm in
  72. >any existing programming language efficiently. Finally, learning any
  73. >new language amounts essentially to learning a new syntax.
  74.  
  75. Such a person might be able to design or implement a HLL using "standard"
  76. operations, but not one where "non-standard" operations should be introduced.
  77.  
  78. Such a person might be able to minimize the size of a program, but not the
  79. time it takes to run; the material presented includes nothing on running
  80. time and costs such as disk reads/writes, context switches, etc.  
  81.  
  82. Could such a person do a decent job in assemby language?  It is a much 
  83. simpler language, but with a very rigid and unnatural syntax.  I doubt
  84. it, because nothing is included on choice of algorithms at the machine
  85. level, machine dependent optimizations, etc.
  86.  
  87. In short, what you have presented as what a student gets in the program
  88. is how to program in a language with no consideration of efficiency in
  89. the algorithm.  Now this is relatively easy, but produces poor code.
  90. The infamous 4.2BSD frexp() was a straightforward HLL portable method of
  91. doing the job.  Unfortunately, it frequently took 100 times as long to run
  92. as using machine representation, which is only partially portable.
  93. -- 
  94. Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
  95. Phone: (317)494-6054
  96. hrubin@pop.stat.purdue.edu (Internet, bitnet)  
  97. {purdue,pur-ee}!pop.stat!hrubin(UUCP)
  98.