home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / sci / math / symbolic / 3040 < prev    next >
Encoding:
Internet Message Format  |  1992-11-19  |  2.4 KB
  1. Path: sparky!uunet!cs.utexas.edu!wupost!darwin.sura.net!spool.mu.edu!agate!peoplesparc.Berkeley.EDU!fateman
  2. From: fateman@peoplesparc.Berkeley.EDU (Richard Fateman)
  3. Newsgroups: sci.math.symbolic
  4. Subject: Re: The Real Meaning of Efficiency?  (Re: Serious Programming, etc.)
  5. Date: 19 Nov 1992 17:43:49 GMT
  6. Organization: University of California, Berkeley
  7. Lines: 44
  8. Distribution: world
  9. Message-ID: <1egjolINNk2e@agate.berkeley.edu>
  10. References: <18NOV199217533011@reg.triumf.ca>
  11. NNTP-Posting-Host: peoplesparc.berkeley.edu
  12.  
  13. In my view one of the most powerful abstractions for programming
  14. mathematical algorithms is recursion.  If a user writes a recursive
  15. program in Mathematica, it appears that there is an enormous
  16. efficiency penalty, at least compared to using built-in Map-like
  17. commands.  This is quite unfortunate.  It leads to intellectual
  18. inefficiency.  If recursion and pattern matching were so good, perhaps
  19. we wouldn't see so much claptrap in "fast Mathematica" programs
  20. with # and &, which (I suspect) are merely ways to AVOID pattern matching
  21. and the usual function call overhead.
  22.  
  23. digression ...
  24. When IBM came out with the IBM-360 design in the mid 1960s, they
  25. missed the boat on recursion and subroutine calling generally.
  26. The architects seemed to not know about stacks:
  27. They left out instructions to increment a stack pointer, and indeed
  28. even screwed up by not having more than 16 bit relative addresses
  29. (limiting the size of a stack). A subroutine call in PL/I was initially
  30. INCREDIBLY expensive (for C fans, consider calling malloc at every
  31. subroutine call for space to save registers).
  32.  
  33. Some people think the IBM 360 set back the progress of programming
  34. languages by 10 years or more.
  35.  
  36. end of digression...
  37.  
  38. Tools -->and their efficiency <-- affect the way you think.
  39.  
  40. Mathematica is, in my view, poor in this regard. It encourages you
  41. to think inefficiently because, in spite of providing so many tools,
  42. it does not promote the right ones, or provide efficient versions of
  43. them.  (Recursion being one; information hiding a second prominent one.)
  44.  
  45. Stephen Wolfram's ambition (according to an interview in an article in
  46. The Chronicle of Higher Education some months ago) appears to be
  47. to have the Mathematica language replace all others as a first
  48. programming language (i.e. instead of Pascal, Modula II, Scheme,
  49. Ada, ... etc).  I am not enthusiastic about this prospect.
  50.  
  51. RJF
  52.  
  53.  
  54. -- 
  55. Richard J. Fateman
  56. fateman@cs.berkeley.edu   510 642-1879
  57.