Re: Mathematica Programmer vs. Programming in Mathematica

*To*: mathgroup at smc.vnet.net*Subject*: [mg63136] Re: Mathematica Programmer vs. Programming in Mathematica*From*: "Steven T. Hatton" <hattons at globalsymmetry.com>*Date*: Thu, 15 Dec 2005 05:30:04 -0500 (EST)*References*: <200512130841.DAA08238@smc.vnet.net> <200512142222.jBEMMaKZ009591@ljosalfr.globalsymmetry.com> <00F1F63A-4CBA-4237-A3AC-43703227311C@mimuw.edu.pl>*Sender*: owner-wri-mathgroup at wolfram.com

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

**References**:**Mathematica Programmer vs. Programming in Mathematica***From:*"Steven T. Hatton" <hattons@globalsymmetry.com>