home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / sci / math / symbolic / 3015 < prev    next >
Encoding:
Text File  |  1992-11-17  |  3.7 KB  |  90 lines
  1. Newsgroups: sci.math.symbolic
  2. Path: sparky!uunet!utcsri!newsflash.concordia.ca!mizar.cc.umanitoba.ca!access.usask.ca!news
  3. From: jake@skatter.usask.ca
  4. Subject: Re: Serious Programming (was: Re: MAPLE resources reccomendation)
  5. Message-ID: <1992Nov17.232239.9748@access.usask.ca>
  6. Sender: news@access.usask.ca (USENET News System)
  7. Nntp-Posting-Host: skatter.usask.ca
  8. Organization: University of Saskatchewan
  9. References: <1eb8j4INNld2@agate.berkeley.edu>
  10. Date: Tue, 17 Nov 1992 23:22:39 GMT
  11. Lines: 77
  12.  
  13. From article <1eb8j4INNld2@agate.berkeley.edu>, by fateman@peoplesparc.Berkeley.EDU (Richard Fateman):
  14. > In article <BxuxC6.Dxz@news.cso.uiuc.edu> Richard J. Gaylord <gaylord@ux1.cso.uiuc.edu> writes:
  15. > 
  16. >>
  17. >>the basic question iswhat do you want out of your cas? if you are going
  18. >>to do serious programming,  mathematica  is totally in front of the
  19. >>others.
  20. > 
  21. > I think that if you are doing serious programming, the mandatory use of
  22. > Mathematica's built-in interpreted user language is a serious handicap
  23. > for many purposes.  It's ok for fiddling around, but if it were really
  24. > good, then there wouldn't be 400,000 (or more) lines of C in the
  25. > system.  Most add-ons written in the Mathematica language have
  26. > serious efficiency problems, and some are outright crocks that break
  27. > when stressed.
  28. > 
  29. > While I am not a fan of the Maple syntax, it is certainly
  30. > possible to write serious programs in it, as demonstrated by the Maple
  31. > group's having written most of Maple in it.  It has been shown on this
  32. > newsgroup that Maple has similar functional-programming style
  33. > features, and is fast.
  34. >
  35.  
  36. Having recently discovered (?) and read with some interest Mr. Fateman's
  37. review of the Mathematica system, and now this particular comment, I begin
  38. to wonder if any system, anywhere in whatever stage of development, can
  39. be said to embody a syntax of which Mr. Fateman would be a "fan".
  40. This is not intended to abuse Mr. Fateman, I rather am seriously interested
  41. in these issues and would like to see him state exactly what, in his opinion,
  42. the ideal design trade-offs in a CAS are. 
  43.  
  44. It is quite possible that he has done so in a forum of which I am ignorant,
  45. and if so,  I would appreciate knowing. How one goes about constructing such
  46. systems is a topic of my interest every since I first came into contact
  47. with these systems.
  48.  
  49. > 
  50. > A system built on top of Common Lisp (like Macsyma, Reduce, Weyl, 
  51. > Mock-MMa) can in principle provide all those (very serious) features.
  52. > Some of them, like the Common Lisp Object System, are not available
  53. > in Mathematica, and, some might argue, represent a serious deficiency.
  54. > The lack of any appropriate structure for maintaining
  55. > assumptions is another major deficiency in Mathematica's design.
  56. >
  57.  
  58. This is a good point. (IMHO) In an article in the Mathematica Journal, it was
  59. (reportedly) said by Mr. Wolfram that the problem is in organizing and
  60. propagating through all the various bits of information.  However, it
  61. seems to this poster that all of the other systems seem to have been
  62. able to deal effectively, with perhaps varying degrees of success, with this
  63. problem.
  64.  
  65. > Most implementations of Common Lisp allow for links to other languages
  66. > such as calls to Fortran or C, if that is "serious" also.  
  67. > 
  68. > So for serious programming, I'd put Mathematica near the end of the list.
  69. > For non-serious programming, it is much more appealing, especially
  70. > if you can exercise some restraint in how much of it you use, and you
  71. > are able to avoid questions of scope, evaluation, and limited data
  72. > structure choices.
  73. > 
  74. > 
  75. > 
  76. > 
  77. > 
  78. > -- 
  79. > Richard J. Fateman
  80. > fateman@cs.berkeley.edu   510 642-1879
  81.  
  82.  
  83. jake
  84.  
  85.  
  86. --
  87. Jason C. Breckenridge                 jake@skatter.usask.ca
  88.  
  89. Sometimes the world is a mighty fine place to be dead to.
  90.