Re: OOP in Mathematica
- To: mathgroup at smc.vnet.net
- Subject: [mg38620] Re: OOP in Mathematica
- From: atelesforos at hotmail.com (Orestis Vantzos)
- Date: Wed, 1 Jan 2003 03:39:47 -0500 (EST)
- References: <D528A86C-1ABC-11D7-B88E-00039311C1CC@mimuw.edu.pl> <aur8s0$8g7$1@smc.vnet.net>
- Sender: owner-wri-mathgroup at wolfram.com
Wow, Steve is definitely overwhelming... Anyway, I am both a mathematician and an experienced(IMHO) Mathematica user, and I have expressed my general view of OOP-MMA many times...I won't repeat it here. I must note though, that I first studied OOP in order to implement it in Mathematica; I had no previous experience of it! I saw it through a Mathematica user's view and found it interesting enough to devote a lot of my time to it. Anyway, I have two points to make: a) Having studied half a dozen OOP subparadigms, I find the 'pure OOP' and 'prototyping model' concepts to be the most promising. Since noone is seriously suggesting that we make Mathematica, as it is, purely OOP-based, my suggestion is that we can 'translate' the fundamental Mathematica operations in OOP language and make our OOP subset of the language as 'pure' as possible, thus enabling one to think uniformly about OOP-MMA. I have repeatedly described in this forum, how the "symbols evoke rules" model can be understood in terms of message passing. My favourite 'pure OOP' language is, ofcourse, Ruby. With its patterns, it is very reminiscent of Mathematica..check it out at www.ruby-lang.org .. The 'prototyping model' dictates that we don't really need any classes, simply objects that receive messages and, under certain conditions, pass them to other objects called 'delegates'. I find this very agreeable, given Mathematica's symbols and their evident lack of hierarchy. It seems to me that the designers meant for a rather 'democratic' environment, where symbols are created equal be they constants,procedures,functions or mere options. Self is a great implementation of 'delegation OOP' and I found its documentation invaluable (research.sun.com/research/self/). b) OOP-MMA attempts this far have completely ignored Mathematica's own proramming culture, a fact which accounts IMHO for their pure reception from the Mathematica community. I think that we must search for a 'native way' for OOP to be implemented in Mathematica; Mathematica should not just be a hidden layer on which objects live, but objects should be made to fit in Mathematica's worldview instead. We should not try to 'simulate' OOP over Mathematica, but bring forth the hidden 'objectiveness' of Mathematica. Therefore, I disagree with Steve on one thing: an OOP-MMA should initially focus on Mathematica applications and not in cooperation/translation of Mathematica code in other languages, especially C++/Java which are very alien to Mathematica's way of programming. My experience is that when OOP-procedural models mix with Mathematica, havoc is ensured;-). At a later stage we could begin to interface with (or even migrate objects to) scripting languages like Ruby or even Java. I would like to keep the discussion to much fundamental issues for now though... like 'what does 'object' mean in Mathematica?' Orestis
- Follow-Ups:
- Re: Re: OOP in Mathematica
- From: "Hermann Schmitt" <schmitther@netcologne.de>
- Re: Re: OOP in Mathematica