Re: Re: Mathematica Programmer vs. Programming in Mathematica

*To*: mathgroup at smc.vnet.net*Subject*: [mg63160] Re: Re: Mathematica Programmer vs. Programming in Mathematica*From*: "Steven T. Hatton" <hattons at globalsymmetry.com>*Date*: Fri, 16 Dec 2005 07:22:14 -0500 (EST)*References*: <dnrmus$pub$1@smc.vnet.net>*Sender*: owner-wri-mathgroup at wolfram.com

Owen, HL (Hywel) wrote: > > >> -----Original Message----- >> From: Steven T. Hatton [mailto:hattons at globalsymmetry.com] To: mathgroup at smc.vnet.net >> 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. How long ago did they graduate? I'm talking about new people graduating from, or still in college. I cannot imagine they have had no exposure to Java or something similar. >> "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. I'm speaking from the perspective of someone who just wanted to get the job done. Mathematica did not behave as I expected it to. Right now I am dealing with the conflicting paradigms of the complex structure J:R^2->R^2 verses Complex[] verses v={x,y}. Trying to coerce Mathematica to deal with these in general and compatable ways is not straightforward. I believe you may be missing the point of saying expressions should be presented as recursive data structures. I'm not talking about some elaborate expostion on data structures, I'm talking about "pointer diagrams", the kind found in K&R. Showing the traversal of the expression tree is an essential prerequisite to teaching about UpValues, DownValues, attributes, evaluation order, etc. Forget Mathematica! That is how mathematics should be taught! >> 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! You can't have the second part without the first part. -- The Mathematica Wiki: http://www.mathematica-users.org/ Math for Comp Sci http://www.ifi.unizh.ch/math/bmwcs/master.html Math for the WWW: http://www.w3.org/Math/

**Re: Why is y a local variable here?**

**Re: Hinton diagrams**

**Re: Re: Mathematica Programmer vs. Programming in Mathematica**

**Why is y a local variable here?**