Re: Re: Mathematica Programmer vs. Programming in Mathematica

*To*: mathgroup at smc.vnet.net*Subject*: [mg63149] Re: [mg63136] Re: Mathematica Programmer vs. Programming in Mathematica*From*: "Owen, HL \(Hywel\)" <h.l.owen at dl.ac.uk>*Date*: Thu, 15 Dec 2005 07:14:08 -0500 (EST)*Sender*: owner-wri-mathgroup at wolfram.com*Thread-index*: AcYBalITORlev/sZS+iOot9DvBzUegAAi/+A

> -----Original Message----- > From: Steven T. Hatton [mailto:hattons at globalsymmetry.com] To: mathgroup at smc.vnet.net > Sent: 15 December 2005 10:30 > Subject: [mg63149] [mg63136] Re: Mathematica Programmer vs. Programming > in Mathematica > ...... > > I wonder what value there woudl be in trying to explain what makes > > Mathematica "functions" different from functions in > languages such as > > C in a book addressed to readers most of whom have no > knowledge of C > > and are not particualry interested in getting it? > > I suspect you will not find very many people who have never > programmed in Java, C#, or C++ and are likely to use > Mathematica extensively. I'm not really saying the > introduction should use these languages extensively as a > means of contrast. I'm saying that Mathematica should be > introduced very differently from the way these general > purpose languages are introduced. Hang on for a minute - our entire corridor is full of scientists who use Mathematica every day. And only a couple have used even C. Most scientists have grown up with Fortran, right? (at least judging from the way they use Mathematica! ;) So your statement that most Mathematica people start from Java or C is incorrect. > "Everything is an expression" should be explained in terms of > recursive data structures, which they are. Obviously, such a > presentation should include tree diagrams showing the > decomposition of expressions. A brief explanation of how the > expression tree is traverse during evaluation should also be > given at this point. I completely disagree - I think for most people who want to understand Mathematica to get a job done, this actually confuses the issue. It's of course an interesting topic in computer science, but not really relevant for people who just want to do something with Mathematica. > Symbols should be explained in relative detail. UpValues, > DownValues, OwnValues, SubValues, and attributes should be > presented as part of the introduction to Symbols. Again, an > example showing how these properties of Symbols impact > evaluation should be given, and it should use the same tree > traversal approach as is used in the introduction of expressions. I agree with this though! Etc.... H >