Paul D. Fernhout wrote: > I just came across these links (bearing indirectly on the value of > Python emphasizing both procedural and Object-Oriented Programming > support as a language good for beginners and experts): > > See: > "Object Oriented Programming Oversold!" > http://oop.ismad.com/ > Or: > "Guide To Myths" > http://www.geocities.com/tablizer/myths.htm > > And: > "Why I Prefer Procedural/Relational Over OOP" > http://www.geocities.com/tablizer/whypr.htm > >From the last, for example: "It is my opinion that the division between > data and behavior in procedural/relational (p/r) applications also has > software design benefits. It allows a certain "contract" between the > database and the database user (application programmer). Contracts > usually have certain obligations and costs, but these costs are > worthwhile for the parties of the contract or else the contract would > not be entered into. The relational paradigm involves just such a > contract. If you follow your end of the bargain, then the other party, > the relational paradigm, will provide wonderful benefits. The > "limitations" required are not arbitrary, for they provide a powerful > intellectual rigor which is one of the greatest tools of modern software > technology in my opinion. Along with GUI's, relational technology is one > of the rare "wow!" technologies that is a fundamental leap forward in > software design. ... The contract of the relational paradigm basically > says, "If you put or keep your information (data) in a certain given > structure, then there are powerful and concise operations that you can > do on this information." E. Codd, the inventor of relational algebra, > opened the world's eyes to a powerful kind of "math" (with some help > from more practical-minded collegues). This math can reduce complex > structures and patterns into relatively simple formulas, or "relational > math"." > > Of course, one might argue relational databases are just well defined > objects... :-) But then the object paradigm starts to break dawn -- and > one is really thinking more in terms of "modules" then how "objects" are > usually discussed. As I previously wrote here (and on the Squeak list a > long while back): > http://mail.python.org/pipermail/edu-sig/2006-December/007483.html > "Personally, one way my opinions differer from Alan Kay's in a deep way > is on his, I think mistaken, notion that an object (or a class) can have > any meaning apart from the ecology of objects (or really classes) it is > embedded in. I think there is a deep philosophical (and practical) > point there which he is perhaps only slowly beginning to see. :-) But > it is reflected in the superiority of, say, Python's modularity in > practice compared to early Smalltalks, that is, if you think classes > stand alone, then there is no need for a higher level of "module", > whereas if you think classes need to be clustered to support each > other, than modules make a lot of sense." > > Still, I think the more general issue, present even in AK's new > proposal, is how one can simulate the world by objects but one also can > simulate the world (perhaps more accurately, if with more effort) as a > set of fields defined by relations (or by any other method). Whether > such fields are best implemented procedurally or via OOP is another > question. Anyway, when one delves this, it gets murkier and murkier -- > in part because people often confuse having a modeling layer of discrete > objects somewhere as meaning the models are all about Objects and OOP, > but there is no reason one cannot use objects to model other things > (fields) -- or even vice versa. Still, from a beginner point of view, > why should you have to get the metaphor of "objects" if what you are > interested in are "fields" (e.g an astrophysics simulation of particles > in an electrostatic gradient and/or gravity well)? I think the appeal of > APL based on arrays is in part the appeal of fields. > > One thing that makes this all confusing to understand is the human mind > has a layer (or module) that models the complex real world in terms of a > simplified representation of "objects" (as I wrote in my undergraduate > thesis in 1985: "Why Intelligence: Objects Stability Evolution and > Model"). William Kent explored this in his book _Data and Reality_: > http://www.bkent.net/ > For example, by numbers, people are about 90% bacteria, but we generally > don't see other people as walking bacterial colonies. :-) > "People Are Human-Bacteria Hybrid" > http://www.wired.com/medtech/health/news/2004/10/65252 > Yet if you want to understand some branches of holistic medicine (and > why using antibiotics might have lifelong health impacts) then you need > to think about people this way, as hard as it is. > http://www.findarticles.com/p/articles/mi_m0NAH/is_2_32/ai_83316363 > And then, if you want to understand bacteria, you have to see them more > as a vast worldwide supercomputer than isolated individuals: > "New Science Of Metagenomics to Transform Modern Microbiology?" > http://science.slashdot.org/article.pl?sid=07/04/02/2017249 > So, as Plato's "Allegory of the Cave" suggest it is sometimes hard to > see past these shadows (objects) to realize that reality is something > fundamentally different (deeper, more complex, more interrelated) than > the simple parsing into objects we do routinely. [Plato's analogy breaks > down here though in that he still thought of *ideal* forms of objects, > whereas I'm more arguing against even ideal forms, except perhaps in a > statistical sense sometimes.) Seeing the world in terms of objects may > have enormous survival value to life forms with big brains, but that > does not mean it is completely accurate (even as objects being a useful > idea does mean there is likely some statistical truth there (e.g. > statistical clustering), in terms of a field of relationships). > > Still, and I don't have it anymore, but about fifteen years ago I made a > list of about 20 reasons why (VisualWorks) Smalltalk was better than a > typical C++ (of the time) from a developer and maintainer point of view > -- intentionally not bringing in OOP specifically as a reason (although, > in retrospect, many of the benefits were enabled by OOP). Stuff like the > integrated debugger, the browser, the inspector, refactoring support, > garbage collection, the GUI library, edit/continue, and so on. Of > course, C++ now apes many of those features, but without the integration > or elegance. > > Still, having explored relational programming (via Pointrel) I can say > both approaches (OOP and Relational) have their merits. The right tool > for the right job. Or in this case, a flexibility with metaphor, so "teh > right metaphor for the right job". Or, looking at it even more > abstractly, "the right mathematical abstraction for the right job". And > from that point of view, should not a goal of computer education (and > CP4E) be to have people able to handle multiple metaphors as appropriate > for the situation? Programming a digital thermostat might require > thinking in terms of one kind of metaphor, whereas programming the GUI > on your car smith require a different kind of metaphor? Perhaps the > conflicts about "which programming language is best" really are just > obscuring the issue of "which metaphor is best" and the answer to that, > like when looking at a large library of fiction, is that lots of > metaphors are useful in the right situations, and only being able to > understand one kind of metaphor would mean you would not get very much > out of most fiction. So a programmer only capable of working within one > metaphor is not a very capable programmer. Still, if that metaphor is > very powerful, like with OOP, a single-metaphor programmer could still > get pretty far and do lots of useful things. And likely further than > simple relational programs. > > Anyway, food for thought. > > --Paul Fernhout > _______________________________________________ > Edu-sig mailing list > [email protected] > http://mail.python.org/mailman/listinfo/edu-sig > >
Not sure you can trust anyone using the phrase "appeal of APL". _______________________________________________ Edu-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/edu-sig
