Edu-sig

Download

edu-sig@python.org

April 2007

15 participants
22 discussions

More OOP bashing (& which metaphor is best?)
by Paul D. Fernhout April 5, 2007

April 5, 2007

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

3 4

Re: [Edu-sig] [edupython] Python in Education Advocacy Article
by Laura Creighton April 3, 2007

April 3, 2007

In a message of Wed, 28 Mar 2007 00:25:40 +0200, Laura Creighton writes: >A first programming language should be interpreted not compiled. It >should also not have type declarations. > >Laura correction: it should not have type declarations, unless it is Haskell, which is another pretty good first programming language, but which also can be described as 'nothing _but_ type definitions, with a little bit of language tacked on that makes it possible to run programs. :-)'. People who are learning how to program are learning how to write executable alogrithms. They need to get to the algorithm part as quickly as they can, with as little superfluous junk as possible. Learning to write algorithms is hard enough as it is. Everything from braces and begin/end blocks, and all the stuff you learn in order to make things easier for the compiler or interpreter to generate code are things that only get in the way of the novice programmer actually learning how to write algorithms. Laura

5 7