home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / sci / math / symbolic / 3027 < prev    next >
Encoding:
Internet Message Format  |  1992-11-18  |  3.9 KB
  1. Path: sparky!uunet!destroyer!cs.ubc.ca!unixg.ubc.ca!reg.triumf.ca!orwell
  2. From: orwell@reg.triumf.ca (BALDEN, RON)
  3. Newsgroups: sci.math.symbolic
  4. Subject: The Real Meaning of Efficiency?  (Re: Serious Programming, etc.)
  5. Date: 18 Nov 1992 17:53 PST
  6. Organization: TRIUMF: Tri-University Meson Facility
  7. Lines: 62
  8. Distribution: world
  9. Message-ID: <18NOV199217533011@reg.triumf.ca>
  10. NNTP-Posting-Host: reg.triumf.ca
  11. News-Software: VAX/VMS VNEWS 1.41    
  12.  
  13. Regarding the issue of the relative "efficiency" of programming languages
  14. available in different mathematical/symbolic computation systems I would 
  15. note that years ago I started off playing with SMP (and eventually did some
  16. real work with it) on a VAX-780 which typically had 20 users; now
  17. I can run Mathematica on a DECstation 3100 or 5000 all by myself.
  18. The ratio of the hardware power available to me now to that then is
  19. something like 50-100; thus differences in the *runtime* "efficiency" of
  20. programming languages of factors of 4 -- or even more -- in what are
  21. *supposed to be Very-High Level (VHL) programming languages* (following
  22. in the lineage of APL, the first widely-used VHL language) --
  23. leave me quite cold.  What is important to me is the
  24. total time spent formulating and solving a problem.  
  25.  
  26. [I note that the same relative timing ratio may be significant
  27. or not depending on context -- a difference between 2 and 20 seconds
  28. for a single operation is important to me when working away on
  29. the interactive simplification of a large expression, because
  30. psychologically you're twiddling your thumbs waiting for the result,
  31. but the difference between 1 hour and 10 hours is not important --
  32. they're both batch jobs where I can go and think about something
  33. else.] 
  34.  
  35. These "efficiency" arguments have all appeared before in the history
  36. of computing when the first FORTRAN compiler appeared to challenge
  37. assembly language; "those who do not know history are condemned to
  38. repeat it".  (See the comments of John Backus, the "father
  39. of FORTRAN" in his Turing Award Lecture:  "Can Programming Be
  40. Liberated from the von Neumann Style?  A Functional Style and
  41. Its Algebra of Programs?"  I believe Backus also discusses
  42. these issues in the "History of Programming Languages" conference
  43. proceedings edited by Richard Wexelblat (1978)).  
  44.  
  45. To me, it seems that Maple is certainly a VHL programming system in
  46. terms of the facilities available, but that it does not quite have a
  47. VHL programming language as linguistic glue to weld together its different
  48. facilities -- that its lineage is basically from what Backus calls
  49. "Von Neumann" (ALGOL/FORTRAN/Pascal) languages.   (In a somewhat
  50. similar vein, the IMSL scientific subroutine library offers individual
  51. VHL numerical problem-solving facilities, but you still have to use
  52. "low-level" FORTRAN to weld together various IMSL routines in a
  53. stand-alone program.)  In contrast SMP/Mathematica's (spiritual,
  54. at least) programming lineage comes more from APL.
  55.  
  56. Finally, it seems to me disingenuous to attack the Mathematica
  57. user-level programming language on the grounds of "if it is so good,
  58. why don't the developers of Mathematica use it to bootstrap their own
  59. system?"  (To me, a bit like asking, "if the set-theoretic query 
  60. languages of relational database management systems are so good, why
  61. aren't they written in SETL?")  The whole point of VHL languages is to
  62. insulate the *user* from details which reflect the details of the
  63. computer hardware architecture.  But given that you're actually going
  64. to run the system on a `Von Neumann' architecture, the *developers* of
  65. the system can hardly afford to be ignorant of these details. 
  66. If the developers at WRI sweat away and write in C to get
  67. factors of 4 difference in runtime, then good for them -- their
  68. effort is amortized over the whole Mathematica user community.
  69. But after all, we're paying them for their sweat.  What I care
  70. about is my effort in using their system, not their effort
  71. in creating it.
  72.  
  73. Ron Balden
  74.  
  75.