MathGroup Archive 2005

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

Search the Archive

Re: Mathematica Programmer vs. Programming in Mathematica

On Wednesday 14 December 2005 19:33, Andrzej Kozlowski wrote:
> On 15 Dec 2005, at 07:22, Steven T. Hatton wrote:
> > He also says: " It is to be hoped that there will soon be a
> > hard-wired version in the underlying Mathematica C code."
> It seems prety obvious now it is not going to happen. I for one do
> not regret it.

I'm interested in the rationale behind the choice.  I can think of some places 
where OOP might make some sense.  For example, in interfacing with external 
programs which themselves are OO.  The example of a fundamental quaternion 
type is another possible candidate.

> 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.  
"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.

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.

Patterns and rules should be explained sufficiently to support an explanation 
of how Set and SetDelayed operate in terms of rules.

> Nevertheless I still do
> not think this is a good book to start learning Mathematica
> programming form. On the other after I read Wagner's book I could
> easily read Programming in Mathematica and other Mathematica books
> and although I found useful things in them I don't think I ever
> discovered any more fundamental principles I that were somehow missed
> by Wagner.

Out of print and hard to find.

> As I and others have already explained: each chapter is on a totally
> different topic. They are unrelated and and do not naturally lead
> from one to another.

That's not the impression I get from the TOC.

1 Introduction
2 Abstract Data Types
3 Polymorphism and Message Passing
4 Object-Oriented Programming 

Combine ADTs with polymorphism and message passing (I assume that means 
manipulating ADTs via functions), add data protection, and you have OOP.

> I don't understand you here, though I suspect that is because our
> background and interests are quite different.
>   I have never had much interest in "how Mathematica works
> differently from traditional procedural and functional languages" and
> honestly do not have much now either. 

In the major general purpose programming languages a function (method, 
procedure, whatever) is a basic construct, and assignments are strictly lhs 
gets rhs.  In Mathematica Set and SetDelayed are not fundamental operations, 
and do not do what they appear to do when viewed as similar to assignment in 
most languages.  There are several other important differences.

> I don't think not knowing that 
> was ever any obstacle to my understanding of Mathematica. I knew a
> bit of Lisp at the time when I started learning Mathematica (and that
> was entirely due to reading Chaitin's "algorithmic Information
> Theory" ,

That is probably a much better starting point in many ways.  Had I had some 
real understanding of Lisp when I started learning Mathematica, I suspect 
things would have fallen into place much faster.  There are many similarities 
between Mathematica and Lisp.  The most important one is probably the fact 
that both are weakly typed languages inwhich the type of an object is bound 
to the data and not the symbol used to refer to the data.

> In fact my approach was entirely different from yours. I had been
> using Mathematica for a number of years without any programming but
> then I got an idea about a specific project I wanted to implement for
> the classes I was teaching. I found that I had to learn to program to
> do that. I could not find any information that I needed in the
> Mathematica book (it was of course all there, but the problem was I
> did not know  how to look for it).

The Master Index in the HelpBrowser is certainly not foolproof.  There are 
some significant omissions.

> After reading "Programming in Mathematica"  I was not much closer.
> But after I read David Wagner's book it became almost trivial to
> implement my project; the whole program turned out to be less than a
> page long. 

I believe you are missunderstanding what I mean by programming in Mathematica.  
I did make mention of writing some MathLink code a couple months back, but 
that was mostly out of utter frustration with the Motif "GUI" provided for 
the Linux version.  What I meant by understanding the Mathematica programming 
language really has to do with things that I will apply to mathematics.  Much 
of that is learned by reading TMGB-P.  But that really should be a second 
book.  I have yet to find the first book.



  • Prev by Date: own package doesnt work correctly?
  • Next by Date: Re: Mathematica Programmer vs. Programming in Mathematica
  • Previous by thread: Re: Mathematica Programmer vs. Programming in Mathematica
  • Next by thread: Re: Mathematica Programmer vs. Programming in Mathematica