MathGroup Archive 2005

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

Search the Archive

Re: Mathematica Programmer vs. Programming in Mathematica

  • To: mathgroup at
  • Subject: [mg63138] Re: Mathematica Programmer vs. Programming in Mathematica
  • From: Andrzej Kozlowski <akoz at>
  • Date: Thu, 15 Dec 2005 05:30:05 -0500 (EST)
  • References: <> <> <> <>
  • Sender: owner-wri-mathgroup at

On 15 Dec 2005, at 17:02, Steven T. Hatton wrote:

> On Wednesday 14 December 2005 19:33, Andrzej Kozlowski wrote:
>> *This message was transferred with a trial version of CommuniGate 
>> (tm) Pro*
>> 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.

You would be surprised. One example is, of course, myself: I have  
written tens of thousands of lines of Mathematica code and not a  
single line of Java or any version of C (although I did learn Algol  
and Pascal in my undergraduate days). And I am certainly not an  
exception: most people whom I know personally and who are extensive  
mathematica  users have not programmed in any of the languages you  
mention, although most have used Lisp.
> 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.

As far as I can remember this is essentially how most books approach  
the teaching of Mathematica. Most tend not to assume any previous  
knowledge of programming.
> 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.
> 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

Yes, all that is there. I don't have these books anymore as they  
belonged to the university I used to teach at and not to me  
personally. Nevertheless it is true that with the possible exception  
of these chapters, both books are collections of independent articles  
form the Mathematica journal (which is why never bothered to buy them  
for myself since I have the relevant copies of TMJ).
>>   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.

. But so what? I can't see why not having this explained in a book  
should make it harder for someone to understand Mathematica. Perhaps  
the best policy is, after all, to forget all you know about other  
programming languages.
> 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.

Well, OK. But a lot of people are writing pretty good Mathematica  
code without also having ever found this "first book" you are looking  

Andrzej Kozlowski

  • Prev by Date: Re: Mathematica Programmer vs. Programming in Mathematica
  • Next by Date: Re: Unexpected non-evaluation problem
  • Previous by thread: Re: Mathematica Programmer vs. Programming in Mathematica
  • Next by thread: Re: Mathematica Programmer vs. Programming in Mathematica