[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
>
Prev by Date:
**Re: Unexpected non-evaluation problem**
Next by Date:
**Re: Re: Re: Re: Solve Limitations**
Previous by thread:
**Re: Mathematica Programmer vs. Programming in Mathematica**
Next by thread:
**Re: Re: Mathematica Programmer vs. Programming in Mathematica**
| |