kirby urner wrote: > About your prototyping experiments: I'm interested in learning more > about Self and would gladly attend lectures on same, at OSCON or > wherever. Then I could better follow your logic.
Save yourself the airline fair :-) and just watch online: http://video.google.com/videoplay?docid=5776880551404953752 or: http://www.smalltalk.org.br/movies/ At least to see the basics. 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." Now this perhaps paints an overly rosy picture of the solution. In practice, how libraries are written and what tools you use make a big difference too. And Python's use of namespaces make possible management of some of these issues in a different way. Still, I think there remains of core of truth to this, at least as a sense of the overall "tone" of development. You really need to see it in action, like with the video, to really grasp what is possible and what is different about, at the very least, the GUI development paradigm (which in some ways is not that unlike Delphi or VB, but applicable to even regular objects). > 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. > > That doesn't mean I think the lambda calculus people can't hack their > own brands. They already do, and quite successfully by the look of > things. This is a good question and a good related comment. In general, you are right of course. And I understand your point about language bigotry. I agree, and I think it is not bigotry to say a language does certain things well, and if you want to do those things well and easily, stick with its mainstream approach. Languages have cultures and paradigms, and you swim against them at your own cost (especially in terms of productivity). Still, I wonder if dominant paradigms in the future will be mainly OCaml (or a derivative) as a better C, and something derived from Self (maybe with Python syntax) as a better Smalltalk. I understood the value of OCaml much better when I stopped thinking of it as a Python or Smalltalk replacement but instead as a C/C++ replacement. I'm not even sure the OCaml community sees themselves that way; they almost certainly don't. :-) Python is stuck in the middle there, and sometimes that is a great place to be (especially at the right time), and sometimes it isn't (especially if times change, in part due to its own success). I feel Python as a community right now as it contemplates its own evolution is torn between types and prototypes. Like Squeak, it has developed its own approach to solving the type problem by having a mini-language in the PyPy project, but, while I think it is a neat thing to try, I am left wondering if perhaps it might be better to just use something like Ocaml for that purpose. As an analogy, I read there was a Basic English that all aircraft pilots and control tower operators were supposed to learn of a hundred or so English word to allow any pilot to land at any airport. Worked well for all the non-native English speakers, but the people who had problems with it were surprisingly the native English speakers, because they has problems remembering what they could say and what they could not. So, perhaps, except for a single purpose of maintaining a VM, a language like Squeak's slang or RPython will never have the value that something like OCaml will have as a general tool. So, back to my point of maybe types and prototypes being dominant paradigms, with types implementing performance critical stuff and prototypes supporting everything else. So, I see this PySqueak work as being a step into that future of Prototypes and types, but I'm working on the Prototype side, not to slight the types side. OCaml and relatives seems to have that nailed, because they are able to infer types, so you get the benefits of types without as much syntactic clutter. And clutter means programs that are harder to read and thus harder to maintain (which is why Java fails as a productive language in practice, even when you have tools to write the boilerplate for you; we really need a tool for Java that hides all that). But, still, to agree with your sentiment, who would want to use a buggy new system that in addition to all of Python's warts (*) http://www.amk.ca/python/writing/warts then adds in on top of that new paradigms and other clutter to learn? And makes difficult to use the old ways, which are well documented and well known? That is always the inventors or innovators' dilemma. There is always a strong constituency for the status quo, and so a new idea has many strong enemies and few half-hearted friends. And I think that is one reason I tend to start over from scratch on language projects; if no one is going to use it, then I might as well write it the way I want it to work then adopt someone else's compromises and legacy choices (which even they may no longer be happy with). On the other hand, progress is often most quickly made by focusing on one specific issue (though not always), so in this case focusing on prototypes gets me more mileage than focusing on syntax (which is the hardest thing for most people to learn it seems). Having agreed somewhat, still, as one inventor (Edison?) was quoted: "What is the value of a new baby?" 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." Makes me wonder why Python is still struggling with questions of what is the best GUI development tool for it? Or why we think CP4E is needed given Python exists? Is just a better IDLE what it is all about? What is missing? PythonCard is a great step in the right direction. But, I think part of what is missing in Python is the prototype-like notions which are behind HyperCard or Self, or even Delphi or VB GUI development, to a lesser extent. (HyperCard has a English-like language too, but I'll ignore that here, taking a more formal programming language syntax as a given.) Python also fails in practice with modifying programs while they run, which becomes a big issue for intermediate-level programs and their programmers. 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. You say Python has an easy paradigm to learn, but I think that is not quite true. Python has many inconsistencies and warts (consider the fraction email I just posted) and is approachable to many people in part precisely because they learned C or BASIC first (e.g. infix functional notation), and are looking for something better and more fun and powerful. (**) I feel adding stronger support for Prototypes, if not at the language level then at the tools and library level, would potentially help make Python more approachable for beginners. And I think the Self claims are in that direction. Still, Self is not the only approach to prototypes, see for example: http://www.dekorte.com/docs/protos/ And consider the statement there: "Prototype-based languages are object oriented languages where a new object instance is "cloned" from existing live object (a prototype) instead of being constructed by a class. This makes the language simpler by requiring one less data type and solving the infinite regress problem of classes (if you use a class to create an object, what do you use to create a class?). It is also ideal for systems such as GUIs where the pattern of creating one object by copying and modifying another is already handled by the language itself." 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. By having a culture of working with prototypes, one is more used to customizing specific set ups, and then having tools which help one integrate customizations. One is more used to splitting off a set of base classes and doing different things with them in an experimental ways, then all the careful work that goes into maintaining one common set of classes (Even if ultimately one may prefer to minimized the number of base classes one works with). I think work in that direction is a way to get the benefits of something like Squeak as a platform without all the drawbacks of continually having old code fail with every new small release. Still, in Python's defense (or condemnation :-) in practice it doesn't have a class side equivalent to Smalltalk. You can make one using wrapper functions, and you can use shared class variables, but in general, Python programs don't do things in the class way Smalltalk does. And since much Python code is written in text editors, there is also not the issue of a class side / instance side set of two buttons which every Smalltalk code browser has and can lead to confusion. Python has been creeping more in a class direction, but in practice Python code isn't written that way. So, in that sense, Python is already a lot more Prototype oriented than Smalltalk, plus Python supports instances having their own ad-hoc methods, so again more prototypish. However, even if Python does support this sort of development, in practice, Python examples are written in a more class-oriented way. And Python tools as well. A big part of what I am exploring right now is more how to make a library of Self-like Morph prototypes which can be used to build interfaces in a more Self-like way. Squeak introduced Morphs, but then made them into classes (and badly factored ones at that), which I think lost some of the power. By the way, here is a PataPata (PySqeuak) version that allows wx Widgets as Morphs (with some wrapping, which is only trivially done at this stage as a proof of concept for Buttons, TextEdits, and Sliders), http://svn.sourceforge.net/viewcvs.cgi/patapata/trunk/PataPata/PataPata.py?view=log I already have hit a wx bug with the version I use where Buttons don't display drag feedback because they capture mouse drag events when clicked, e.g. the same as probably here: http://groups.google.com/group/comp.soft-sys.wxwindows/browse_thread/thread/121a5068724c613/e077cfa418cbd5d3?lnk=st&q=wxwidgets+button+mouse+events&rnum=7&hl=en#e077cfa418cbd5d3 I can drag wx sliders or text fields correctly though. I saw the same problem when trying the latest version of PythonCard, but now think it is wxGTK not PythonCard. This new version uses a more generalized notion of properties than earlier versions in order to be able to wrap foreign widgets (though not Python's properties, which were too limited in some respects, and also would have not worked in Jython 2.1). Still, with this wx bug (I see no way around it, but that is par for the course when using native widgets or a C library), plus the extra layer of indirectness wrapping in properties requires, I am left wondering if I should just go push ahead with drawing my own widgets, perhaps building on wx OGL or one of the other widget sets people have made like Pyxel. http://bellsouthpwp.net/p/r/prochak/pyxel.html If I do my own widgets, then I could fairly easily make everything work as a Jython-based Java plugin, which would be a neat deployment vehicle. And if I keep the advanced property support, then wx or TK widgets are always a possibility for someone who wants them. --Paul Fernhout (*) and there are several not listed there I could mention, though I still agree with the author there that: "When viewed next to the large number of things which Python gets right -- a small language core, strong but dynamic typing, reuse of the idea of namespaces, always using call by reference [I think he means value], indentation instead of delimiters -- these flaws are small ones, and I can easily live with them". (**) 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.) _______________________________________________ Edu-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/edu-sig
