Re: Mathematica Programmer vs. Programming in Mathematica

*To*: mathgroup at smc.vnet.net*Subject*: [mg63122] Re: Mathematica Programmer vs. Programming in Mathematica*From*: "Steven T. Hatton" <hattons at globalsymmetry.com>*Date*: Thu, 15 Dec 2005 03:06:31 -0500 (EST)*References*: <dnop91$2fd$1@smc.vnet.net>*Sender*: owner-wri-mathgroup at wolfram.com

Jens-Peer Kuska wrote: > Hi, > > "Programming in Mathematica" is the standard book for Mathematica > Programming, the "Mathematica Programmer" collects mainly Roman Maeders > articles in "The Mathematica Journal" and include interesting stuff like > his polyhedron code. But it focus *not* on the programming techniques ... > > Both books are excelent ... > > The classes.m package is designed to show, that object oriented > programming can be done in Mathematica. But nobody would consider it > as more than an example that even a wonderfull functional programming > language can be misused for nonsense like "object oriented programming". Maeder uses his Classes.m in _Computer Science with Mathematica_. OOP is really just an obvious extension of the concept of abstract data types. According to Stephen Wolfram "The C code in Mathematica is actually written in a custom extension of C which supports certain memory management and object-oriented features." Even ("the crap that is C++") Linus Torvalds asserts that there is much OOP in the Linux kernel. I don't know of any significant program that I use which doesn't explicitly use some elements of OOP in its implementation, with the one notable exception of Emacs. I'm not sure that OOP and functional programming paradigms are necessarily at odd with oneanother. I believe it would require a very judicious use of the features of both paradigms to produce a beneficial integration of the two. At its core, Mathematica seems to be neither a functional nor a procedural language. It's really a rule-based language of patternmatching and rewrite rules. Functions and procedures are illusions built on those rule-based foundations. I am inclined to describe something of an inheritance hierarchy in Mathematica's implementation as being rooted in an abstract class called expression which is realized in the form of subclasses of Atom. These subclasses are Symbol, String, Integer, Real, Rational and Complex. Of these, all but Symbol are - like Strings in Java - immutable. To my way of thinking, Complex should not be a fundamental data type. Complex numbers are constructed of more basic types, as are rational numbers. If we allow that complex numbers are as primitive as real numbers, then what of quaternions? Quaternions are a generalization of the complex numbers to three dimensions. Should they not also be treated as primitive? The only mutable data type in Mathematica is Symbol. Symbol itself appears to be very much like a class in traditional OOP. What we do not have is a way of inheriting from it. I'm really not sure why some people are so averse to OOP. For all of its detractors, it has the best track record of any particular programming paradigm in common use. To call it "nonsense" is not a very convincing nor persuasive argument as to why it is a bad concept. I acknowledge that OOP has its limitations, and may not be applicable to very many aspects of Mathematica programming. But I have not encountered any coherent analysis of its viability. Roman Maeder's Classes.m is not a fair representation of what could be accomplished with OOP in Mathematica because the objects instantiated as subclasses of Object are not first-class objects in the language. -- 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: Parametric Numerical Integral**

**Re: Re: Re: Solve Limitations**

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

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