RE: Re: Re: Not quite a Swell FLOOP?
- To: mathgroup at smc.vnet.net
- Subject: [mg37489] RE: [mg37463] Re: [mg37440] Re: [mg37430] Not quite a Swell FLOOP?
- From: "DrBob" <drbob at bigfoot.com>
- Date: Fri, 1 Nov 2002 01:43:33 -0500 (EST)
- Reply-to: <drbob at bigfoot.com>
- Sender: owner-wri-mathgroup at wolfram.com
I used to be a huge OO fan. I wrote white-papers on it for DoD, etc. I haven't seen the hoped-for benefit, however. Projects and programmers still break on the rocks of complexity. I really like Smalltalk as a language, and it has a very rich class library, but the latter makes for a steep learning curve. When we want to DO something, we must study a host of objects that know how to do that, and somehow pick out one that has all the right characteristics. Writing interesting classes from scratch is fun, but getting good use of existing classes is difficult. (To all that complexity, C++ users add a bloated syntax that produces an unmatched ability to write code the C++ expert next door can't decipher.) Complexity in design and programming (not a scarcity of language features) is usually the enemy, and OO is an incomplete countermeasure at best. As for OOP and Mathematica in particular, it seems that computer algebra is far more about operations than data. If we write x+y as an algebraic expression, we care only that Plus is Orderless and Flat, no matter what kind of things x and y are. True, Plus can be a method of UndefinedSymbol and most objects can inherit from that, but we have the same behavior already through Pattern matching. FlatOperation and OrderlessOperation classes could lead us to a whole matrix of operation and data classes interacting together -- and a class library that boggles the mind. In effect, that's what we already have, but we get to concentrate on the operations, and on objects for which optimized operations exist. We have to concentrate on SOMETHING, I think, so mixing OOP and functional programming seems a recipe for confusion. Bobby -----Original Message----- From: Alexander Sauer-Budge [mailto:ambudge at MIT.EDU] To: mathgroup at smc.vnet.net Subject: [mg37489] [mg37463] Re: [mg37440] Re: [mg37430] Not quite a Swell FLOOP? Your visualization sounds fun. As far as programming paradigms for implementation, I have a hopefully helpful suggestion on structuring your implementation. Object-Oriented Programming (OOP) is certainly more than just data encapsulation, a feat which modular programming performs just fine. Probably not the definitive reference, but FOLDOC's definition of OOP <http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?object- oriented+programming> mentions both encapsulation and inheritance. Furthermore, OOP does not imply a particular syntax. For example, "myinstance.mymethod(args)" and "mymethod(myinstance,args)" are both perfectly legitimate OOP syntaxes. One of the primary benefits of OOP is that you can subclass pre-existing classes, _without modifying or recompiling_ the existing class code, and objects designed for the superclass can use the subclass without knowing it. This greatly facilitates the REUSE of code and increases the flexibility of libraries. What amuses me is that the wild popularity of OOP seems to be _partly_ due to the "new OOP languages" having better module systems (than C, for example) as well as a syntax which encourages the use of modularity, and _partly_ due to people finding the metaphors of OOP helpful in structuring their thinking. The pervasiveness of the OOP paradigm has made it seem somewhat like "the one true way to structure a program," but I think a moments reflection leads most people to concede that, while wonderful, it is not a panacea (e.g. the Standard Template Library for C++ is less OOP and more functional programming). One of the difficulties of OOP's pervasiveness is that it is the only paradigm many people know, so when they approach a problem in a language that does not support OOP, they both do not understand the new paradigm well enough to structure their thinking appropriately for the language and they do not know the necessary idioms to effectively express chunks of computation. All that said, you can build basic data hierarchies in your Mathematica programs quite easily if you encode the collection of data associated with an object as a list of rules and specialize function definitions ("methods") using pattern matching. Here is a simple example: obj={name->"instance of superclass",data->1}; printname[{___,name->name_,___}]:=Print[name] printname[obj] getdata[{___,data->data_,___}]:=data getdata[obj] subobj={name->"instance of subclass",data->2, subdata->{20,30}}; printname[subobj] getdata[{___,data->data_,subdata->subdata_,___}]:={data,subdata} getdata[subobj] getdata[obj] You can formalize this is various ways, by defining object constructors and so on. At the very least, you want to avoid typing these pattern matches all the time. Assigning the pattern to a variable essentially defines a class type: class={___,name->name_,data->data_,___}; subclass=Join[class,{subdata->subdata_,___}]; mymethod[class,a_]:=a*data mymethod[subclass,a_]:=a*data*{1,1}.subdata mymethod[obj,2] mymethod[subobj,2] Of course, there are other ways to this, but this is just an example of simple and natural way to provide basic data inheritance with method specialization in your Mathematica programs. Alex