home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / lang / misc / 4062 < prev    next >
Encoding:
Internet Message Format  |  1992-12-21  |  6.5 KB
  1. Path: sparky!uunet!psinntp!dg-rtp!sheol!throopw
  2. From: throopw@sheol.UUCP (Wayne Throop)
  3. Newsgroups: comp.lang.misc
  4. Subject: Re: Safety.  Was: Re: Pointers
  5. Message-ID: <724658686@sheol.UUCP>
  6. Date: 18 Dec 92 03:19:29 GMT
  7. References: <724312516@sheol.UUCP> <Bz9FL2.9rp@mentor.cc.purdue.edu> <724478076@sheol.UUCP> <BzCxs6.9oC@mentor.cc.purdue.edu>
  8. Lines: 126
  9.  
  10. ::: The notation is more clumsy, and definitely does not convey the intention.
  11. :: Herman is apparently seriously claiming that
  12. ::       g(0xABCD)
  13. :: is less clumsy and conveys more information than
  14. ::       g(iasf(0xABCD))
  15.  
  16. : From: hrubin@pop.stat.purdue.edu (Herman Rubin)
  17. : Message-ID: <BzCxs6.9oC@mentor.cc.purdue.edu>
  18. : I have never seen iasf before.  
  19.  
  20. Now we find that Herman proclaimed one notation "less clumsy"
  21. than another WITHOUT EVER LOOKING AT EITHER NOTATION.  Forgive me,
  22. but I really can't see how to carry on an interaction with somebody
  23. who simply shouts down all comers without even listening to what
  24. they say.  But I seldom let such trivial difficulties discourage me.
  25.  
  26. : But it would be better written as
  27. : asf, but is asf "as floating" or "as fixed"; the idea is that the 
  28. : compiler does not look at how things got there, except to find them. 
  29.  
  30. Yes, fine, wonderful.  But totally irrelevant.
  31.  
  32. : But I am more interested in this for variables than for constants,
  33. : although it is often needed at the present time for constants.
  34.  
  35. If Herman had been paying even the most cursory attention, he
  36. would have seen that the definition I gave for iasf works for
  37. variables just fine.
  38.  
  39. :: Herman specifically requested that students be exposed to situations
  40. :: where code would "really crawl" unless heroic and often
  41. :: architecture-specific measures are used to optimize it.  Such cases are
  42. :: extremely rare, whether or not you believe in a catch-22 deadlock
  43. :: between hardware features and language features, or between developer
  44. :: capabilities and language features. 
  45.  
  46. : If the actual code is not used, this may be difficult, but even the
  47. : initial idea that a computer manipulates objects, and that how it does
  48. : this, and what objects it manipulates, are important.  But the idea of
  49. : bit-twiddling, etc., seems to have been "obvious" to the early people in
  50. : computing, and the use of binary in the mathematical literature before
  51. : that time was extremely small. 
  52.  
  53. This is simply confusing issues of implementation with issues of
  54. notation (and abstraction) yet again.  To focus on the concrete early
  55. and to the exclusion of other material is counterproductive.
  56.  
  57. Specifically, an early focus on the logical objects that computers
  58. manipulate primitively for reasons of physical design in preference to
  59. focussing on the logical objects that the users wish to manipulate is a
  60. mistake.  I say "is a mistake" because I've encountered lots of folks
  61. who focus in this way as a programming stance, and their code is
  62. invariably more difficult to extend, understand, reuse, and "port",
  63. because the code embodies the computer's concerns instead of the
  64. concerns of the problem it sets out to solve.
  65.  
  66. Herman gets away with conflating the abstractions of binary notations
  67. with the implementation issues of computer arithmetic, simply because
  68. the two domains overlap.  But most programmers do not have the luxury
  69. to be so sloppy.
  70.  
  71. ::: What proportion of current programmers, even those who have had
  72. ::: "advanced" courses, are aware of the important mathematical types of
  73. ::: fixed point (NOT integer) and rational?
  74. :: I'd say virtually 100%.  Well...  maybe as few as 90%. 
  75. : I was NOT talking about these types from mathematical programming
  76. : languages, but from the standpoint of mathematics.
  77.  
  78. Ok, fine.  But the answer is STILL virtually 100%, since these subjects
  79. are treated in elementary and high school.  At least, they were in *my*
  80. elementary and high schools, and still are in those of young folk of my
  81. aquaintance.
  82.  
  83. : I submit that the number of people who know about rational and
  84. : fixed-point is larger than those who know any programming language, and
  85. : may very well be more than those who know about the floating-point
  86. : kludge.  It very definitely is a kludge mathematically. 
  87.  
  88. Yes, and all this is covered in elementary courses in numerical
  89. analysis, which was a required course for CS students in my time.
  90. So We've established that the general mathematical notions are taught
  91. early, and that the shortcomings of various attempts to approach these
  92. mathematical notions on computers are routinely taught to CS students.
  93.  
  94. So, what's the problem?  What about this is Herman proposing to change?
  95.  
  96. :: CS students under Herman's regime would have much to unlearn before they
  97. :: could read, write, or even think about portable, maintainable software. 
  98. :: These issues may not be important to Herman, but Herman is the
  99. :: exception. 
  100.  
  101. : They would have to unlearn nothing.  Starting out with the idea that
  102. : there is a large variety of objects, and that machines operate on them in
  103. : various ways, WILL cause them to question why the languages place
  104. : obstacles in their use. 
  105.  
  106. Yes, exactly so.  They will be focussing on what computers can do
  107. instead of what they want to get done.  Exactly the wrong thing
  108. for them to focus on, and hence they'll have a LOT of unlearning
  109. to do before they can get their head out of worrying about what
  110. the computer can do for them, and start worring about what they
  111. can do with the computer.
  112.  
  113. :: But the concepts of and theory of mathematics do not have much to do
  114. :: with the bit-bumming he recommends early exposure to, so Herman's point
  115. :: is obscure in the extreme. 
  116.  
  117. : The bit operations are just the binary version of the "standard" decimal
  118. : operations, and are by no means esoteric, except in the minds of those
  119. : who would have people grow up ignorant of them. 
  120.  
  121. Well, for all practical purposes, the set of "those who would have
  122. people grow up ignorant of [..binary notations..]" is the empty set, 
  123. so Hermans's point is moot on the face of it, as well as being obscure.
  124.  
  125. But again, the point is  NOT to keep people in ignorance.  It is quite
  126. a perversion of what I have been saying to conclude that.  No, the
  127. problem is one of priorities.  In solving a problem, should one focus
  128. on the accidents of the implementation, or on the essentials of the
  129. abstract model that captures the problem?  Certainly, one must be
  130. *aware* of the characteristics of the implementations available, to one
  131. degree or another.  But I still find placing the primary focus on
  132. accidental features over essential ones very wrong-headed.  Yet this
  133. is what Herman seems to be saying (even if it isn't what he means).
  134. --
  135. Wayne Throop  ...!mcnc!dg-rtp!sheol!throopw
  136.