[Date Index] [Thread Index] [Author Index]

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
>