MathGroup Archive 2001

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

Search the Archive

Re: OOP Revisited

I am one of the people who have expressed reservations the use of OOP in 
Mathematica though not as vehemently as Jens Kuska. I have to say 
however that I have recently become converted to the opposite view 
point. The reason is that I have become acquainted with object oriented 
extensions of Lisp which make it possible to deal with highly structured 
areas of mathematics like algebraic topology in a remarkably natural way 
( <> while staying 
entirely in the functional paradigm.  In fact similar things are done 
for algebriac geometry by Macaulay II 
( which is also functional and 
object oriented. Since I prefer Mathematica to Lisp or Macaulay III 
would like to be able to implement similar things in Mathematica and I 
hope that maybe Orestis package will make it easier.

Andrzej Kozlowski

Toyama International University

On Tuesday, November 27, 2001, at 04:47  PM, Orestis Vantzos wrote:

> This post is (partialy) a response to several posts in the 'Creating
> an object' thread.
> Several people, with Jens-Peer Kuska as a prime example, claimed that
> seeking to apply OOP(Object-Oriented Programming) concepts and methods
> in Mathematica programming is false.
> I believe that it is actualy perfectly natural to use the OOP
> methodology when programming in Mathematica! Allow me to elaborate:
> a) The whole concept of symbols is pure OOP. We have a persistent
> entity that caries its own data AND methods. Is that functional
> programming? Not realy - the fundamental Mathematica entity (the
> symbol) is NOT a function (in the funct.progr. sense). It looks much
> more like an object to me, with its Downvalues, Upvalues, etc. It may
> masquerade as a function, but it is much more like an object
> pretending to be a function(again in the functional programming
> sense).
> b) The Mathematica language contains several features which are almost
> pure OOP. CompiledFunction, InterpolatingFunction, NotebookObjects,
> etc. are refered to as objects in the Mathematica Book, and they are
> strongly encapsulated, in typical OOP style.
> c) OOP is more a way to organize large pieces of code, rather than
> writing code in the first place. Take C++; it is obviously procedural
> programming organized in classes according to the OOP spitrit. CLOS is
> an OOP extension to LISP, which proves in my eyes that functional and
> object-oriented programming are not incompatible. In general, OOP
> works in different scales to most other programming styles; the only
> pure OOP language I know of is Smalltalk, as almost every other OOP
> language is a combination of OOP with functional,procedural or other
> styles.
> d) Packages provide strong encapsulation(the 1st fundamental OOP
> concept) for Mathematica code; I don't hear anyone complaining that
> they are incompatible with functional programming! The whole concept
> of contexts (which allows organized hierarchies of symbols with
> similar names- hence 'dynamic method binding'-the 2nd fundamental OOP
> concept) provides a flexible environment which cannot be used
> effectively by the one-liner school of programming: the relentless
> nesting of functions towards a single function that solves the problem
> at hand. One-liners can be little gems, I admit it, but they are not
> an intelligent way to produce and maintain professional code. Keep
> them organized in classes and a different picture emerges. Functional
> programming works in a smaller scale than OOP, so there really is no
> conflict.
> To sum it all up, the world has moved on; OOP has been proven to be
> THE way to program medium to large projects. You can write your
> methods in functional, procedural, or rule-based style; it doesn't
> really matter, as far as OOP is concerned. I strongly believe that it
> is time for the Mathematica language to mature and establish itself as
> a viable(and effective) solution to scientific programming needs. And
> the availability of effective OOP facilities, is an important step
> toward that direction.
> Orestis Vantzos
> PS. I am currently working on a package that implements all the
> afforementioned major OOP concepts (plus inheritance ofcourse), with
> an eye towards seamless integration with the functional style and
> effectiveness both in speed and memory usage. I do intend to back my
> opinions, as expressed here, with code.

  • Prev by Date: Re: integral function
  • Next by Date: Re: mathematica on os x
  • Previous by thread: OOP Revisited
  • Next by thread: Re: OOP Revisited