home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / arch / 11030 < prev    next >
Encoding:
Text File  |  1992-11-23  |  5.1 KB  |  103 lines
  1. Newsgroups: comp.arch
  2. Path: sparky!uunet!mcsun!Germany.EU.net!incom!orfeo!qb!vhs
  3. From: vhs@rhein-main.de (Volker Herminghaus-Shirai)
  4. Subject: Re: Hardware Support for Numeric Algorithms
  5. Message-ID: <1992Nov22.192342.10288@qb.rhein-main.de>
  6. Sender: vhs@qb.rhein-main.de (Volker Herminghaus-Shirai)
  7. Reply-To: vhs@rhein-main.de
  8. References: <1efg1gINNm6c@network.ucsd.edu>
  9. Date: Sun, 22 Nov 92 19:23:42 GMT
  10. Lines: 91
  11.  
  12. In article <1efg1gINNm6c@network.ucsd.edu> mbk@lyapunov.ucsd.edu (Matt Kennel) writes:
  13. > akao@.com (Adam Kao) writes:
  14. > : In article <Bxv2t2.4FH@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman  
  15. Rubin) writes:
  16. [lament deleted] 
  17. > Poor ideas or confusing notation in mathematics disappears with the next
  18. > journal issue, but computer software and languages tend to stay around
  19. > for a long time, and so even more so than math, they require substantial
  20. > thought put in their design.
  21.  
  22. The poorest idea mathematicians had was to use only single characters as
  23. variable names and optimize the multiplication symbol away. This definitely
  24. did not disappear with the next journal issue (there were no journals at
  25. that time). Instead, it led to using all sorts of special characters like
  26. greek or ancient german ones (for matrices) due to name space overcrowding.
  27. BTW I read an article here some time ago by a statistician who complained
  28. about keyboards that couldn't enter these special characters :-)
  29.  
  30. > Also remember that Usenet, and especially these newsgroups, have a very
  31. > CS-centric view of things, and I think that more people than you expect
  32. > "out there" have feeling similar to mine or Herman's.
  33.  
  34. Well, usenet runs on real computers, not on mathematical theories.
  35.  
  36. > I certainly believe us "o'dinry fo'ks" out here have things to learn from
  37. > computer scientists, especially w/r/t the social realities of software
  38. > engineering, and I hope the computer scientists ought to try to learn some
  39. > from us.
  40.  
  41. Just as much as from any other professional group. The bankers would probably
  42. kick our butts if CS only created languages with mathematical notations,
  43. orphaning their Cobol superprogrammers ;-)
  44.  
  45. > Incidentally, my favorite computer language, Sather, (a simplified
  46. > speedified Eiffel), was designed by Steve Omohundro, a computer whiz,
  47. > who got a PhD in high-energy physics.  Somehow, it just feels "right".
  48.  
  49. If it feels "right" for you, use it. I doubt I would like it, though.
  50. If Mathemathics can create demand high enough to support (also
  51. financially) the development of a special language, CS will eventually
  52. do it. Just as for other sciences and professions.
  53.  
  54. > Back to prof. Rubin's point.  I think it would be nice if language
  55. > designers would recognize that *hardware WILL change*, and that
  56. > they design it in a way such that it becomes natural or easy for
  57. > future implementors to put in new operations that don't interfere with
  58. > old ones.  The idea is not to freeze into a single model of computing,
  59. > and have hardware extensions treated as pariahs, only for use by grungy
  60. > hackers, and so we shouldn't give much though to them, and as a result
  61. > everybody has a different ugly way of doing them.  It's just a change of
  62. > attitude, mostly.
  63.  
  64. Too bad we never know in advance just *how* hardware will change.
  65.  
  66. > Scientists, especially in the high-performance world, have a more concrete
  67. > view of computers, that may be sometimes short-sighted, but in other cases
  68. > may be more refreshing.
  69. > 
  70. > As an example, consider a Connection Machine---it's hardware is so fundamentally
  71. > different, and so to even have a chance of writing intelligent programs, it's
  72. > essential to be able to express these fundamentally new methods in software.
  73. > (And yes, they do it.)  Herman's point is that more computers than you think
  74. > may need this, especially as supercomputer-research-type stuff starts coming
  75. > down to earth.  We don't want 87 completely different dialects of C, or tricky
  76. > obscure code that compiles into something simple. We accept the necessity
  77. > of hardware dependence, but we want it tamed, rather than excommunicated.
  78.  
  79. In the very moment you get hardware dependent you also lose portability. If
  80. you accept loss in portability, do it in assembler. If you need a portable
  81. assembler with elementary type-conversion and safe subroutine calls, symbolic
  82. names for variables and little overhead, use C. That's about as close to
  83. assembler (as hardware dependent) as you can get without resorting to assembler.
  84. I also can hardly imagine what a language would look like that had some special
  85. operators for e.g. "FP division by integer value with remainder saved" on one
  86. architecture but would compile and run on another one.
  87. Other than #define-ing some assembler macros for each machine and inlining the
  88. expansions.
  89.  
  90. > : Adam
  91. > : "Those French people have a different word for _everything_!!!"
  92.  
  93. Right, the word for "everything" is "tout" in french, which is indeed
  94. a different word from "everything" :-)
  95.  
  96. --
  97. Volker Herminghaus-Shirai (vhs@rhein-main.de)
  98.  
  99. Computer industry: Industry in which the number of units sold of any
  100. given product is inversely proportional to its technical excellence.
  101. See also: MS-DOS, Windows, IBM-PC, X, QWERTY,
  102.           80x86, TrueType, Survival of the shittest.
  103.