[Date Index]
[Thread Index]
[Author Index]
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/
Prev by Date:
** Re: Parametric Numerical Integral**
Next by Date:
**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**
| |