Paul D. Fernhout wrote: > For textual statement of the key issue, see: > http://en.wikipedia.org/wiki/Self_programming_language > "The problem: Traditional object languages are based on a deep-rooted > duality. Classes define the basic qualities and behaviours of objects, and > instances are a particular object based on a class. ... Unless one can > predict with certainty what qualities the objects will have in the distant > future, one cannot design a class hierarchy properly. All too often the > program will evolve to need added behaviours, and suddenly the whole > system must be re-designed (or refactored) to break out the objects in a > different way. Experience with early OO languages like Smalltalk showed > that this sort of issue came up again and again. Systems would tend to > grow to a point and then become very rigid, as the basic classes deep > below the programmer's code grew to be simply "wrong". [My note: I think > Squeak got to that point of rigidity long ago. :-) ] Without some way to > easily change the original class, serious problems could arise. ... In > general, such changes had to be done very carefully, as other objects > based on the same class might be expecting this "wrong" behavior: "wrong" > is often dependent on the context. ... The problem here is that there is a > duality, classes and instances. Self simply eliminated this duality. ... > This may not sound earth shattering, but in fact it greatly simplifies > dynamism. If you have to fix a problem in some "base class" because your > program has a problem, simply change it and make copies of that new object > instead. No other program will see this change. ... This dramatically > simplifies the entire OO concept as well. Everything might be an object in > traditional system, but there is a very fundamental difference between > classes and instances. In Self, there isn't."
I think there's two issues: classes and inheritance. I don't think inheritance is a particularly respected structure in Python. isinstance() is considered poor form in many situations. Some of Smalltalk's biggest sins, IMHO, come from using inheritance in clever ways, often to a don't-repeat-yourself end, but DRY isn't always such a good idea. The fact that all the classes are opened up to you -- not just technical, but practically actively encouraging you to fiddle with them -- is not very helpful either. So, I think Python avoids some of that fragility, and I think that's just as much about community sentiment as the particular things that are possible. Probably Zope 2 was a big lesson for everyone who touched it in the perils of important and deep class hierarchies. Inheritance is a sometimes useful implementation technique. I think it's wrong to think of it as more than that. Probably we need better support for some other competing techniques. I think that would be most useful if they can be supported without requiring different paradigms. So prototype-based programming and cloning might be easier described in a Python context as delegation (though that's not exactly right). Or whatever it might be -- it doesn't need to be in conflict with what Python has now, because the promises are already pretty loose, and generally Python programmers have no problem with different object models. Every so often you get someone on comp.lang.python who really cares about is-a vs. has-a and all that stuff, but I think that's just a byproduct of poor education and it wears off in time. There's also other ways of doing this stuff out there. Generic functions are a very different approach than either classes or prototypes. And, ignoring some (really fairly minor) syntactic issues, they fit nicely in Python, right alongside other techniques. (Live and persisten objects, however, are not such a good fit into Python, and maybe that's more of what you are pining for?) >>My layman's question, after reading your posts, is: why not just keep >>Python pythonic and Self selfish? >> >>In other words, Python already has a very strong paradigm, very simple >>to learn. Why mess with that? I guess I'm a purist in that regard. >>But that doesn't make me a language bigot, as I fully respect the right >>of other languages to define themselves around equally strong, yet >>different, paradigms. I'm also biased towards OO. I don't see the strong paradigm you do. Python has a bunch of under-appreciated functional constructs that people use a lot, but since they don't look Lispy people don't realize they are functional. > Python as it is solves whole classes of problems well (text processing, > file handling, sockets, gluing C libraries, but lots more). > Still, it has weaknesses, especially for entry-level GUI programming. > Compare it to HyperCard which met many of CP4E's goals twenty years ago: > From: http://en.wikipedia.org/wiki/HyperCard > "HyperCard was a huge hit almost instantly. Many people who thought they > would never be able to program a computer started using HyperCard for all > sorts of automation and prototyping tasks, a surprise even to its > creator." Or from: > http://www.wired.com/news/mac/0,2125,54365,00.html > "The result is both simple and powerful. Fifth-graders get to grips with > HyperCard in minutes, building databases of their Pokemon cards. Cyan, the > game publisher, used it to create fiendishly complex games like Myst and > Riven." I really got to get me a copy of HyperCard, but I still can't quite decide what's important about it. Anyway, it's quite possible that HyperCard is best seen as a constrained object model, probably much more constrained than prototype programming in general. Where all your objects are instances of Card, for instance. > In this case, here are two big arguments for "Self" and a > prototype oriented mindset. One issue it tries to address is something > that by now you may take for granted but may still be a stumbling block > for new programmers, which is how people usually reason from particular to > general. And so they may be better off learning to program a particular > object then to program a class of objects. So, in Logo, teaching "Fred" > how to draw a spiral may be easier than thinking about a "Fred" class of > objects that all draw spirals. Why not just use a spiral() function? Specifically here, but also generally. Functions are nice. > The second big area is the "fragile base class problem" or more generally > the issue that people want to customize their images or programs, yet that > messes up anyone else who want to import the code. Functions are practically the pinacle of reusability. Of course, with *only* functions it's not that easy to do work, lamda calculus aside. Maybe records (objects with no methods), plus functions, extended with generic functions for smart polymorphism? > (**) For another example, if you look at it from a > documenting-intent point of view, Smalltalk's keyword syntax (e.g. Window > showAtX: 10 y: 20." ) makes reading programs much easier than reading > functional syntax where arguments have no hints (e.g. "Window.show(10,20)" > ) and reading programs is what most programmer's spend most of their time > doing. :-) So, if you really want programmers to have happy lives, > teach everyone keyword syntax. :-) Of course, I am living with Python's > functional syntax in order to gain some of the other benefits of it, but > that doesn't mean I am happy about that aspect of it, or that I think it > is good for beginners either. Actually, another Python wart is that > variable names in a function definition become part of the API (e.g. > "myfunction(x=10, y=20)" which is a gross violation of the notion that a > function definition, including local variables, should be independent of > specifying how it is called.) File layout becomes the module structure too. A little bit of a problem, but not a huge one. I think py3k's extended signature syntax improves this. _______________________________________________ Edu-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/edu-sig
