OLPC related: pyGTK for cross-platform (Mac especially)?
I'm still in a state of flux about where to go next after PataPata Phase I (recently discussed here). Assuming I continue with Python (rather than moving more towards Smalltalk, either Squeak or one for the JVM), what interests me most is working on cross-platform applications (Mac, PC, GNU/Linux). Fro cross-platform work, I prefer Jython & Swing over a Python plus widget set solution. This is because Swing is cross platform, Sun has announced plans to put lots of Java under the GPL, the JVM lets me ship very portable Java code alongside the Jython code if needed for performance, and we have already used Jython in cross-platform Mac, PC, GNU/Linux commercial projects with some success (we've only used Python + wxWidgets on PC and GNU/Linux, not Mac). However, for the areas I am interested in, especially educational simulations, being able to run on the One Laptop Per Child (OLPC) platform would be a nice motivating plus. However OLPC does not currently run Java. And with its resource constraints, the best choice for the OLPC is the mainline supported system, which is Python 2.4 (maybe later) and GTK+. http://wiki.laptop.org/go/OLPC_Python_Environment (Some variant of Squeak Smalltalk is another possibility too, as there is work on that.) http://wiki.laptop.org/go/Etoys Now, I don't *need* to support OLPC, and the JVM might run there someday, but I would say that is my biggest sticking point going forward with Jython/Swing if I stick with Python over Smalltalk. Our garden simulator especially is a natural match for the OLPC goals (and we have previously had people in various developing nations interested in it). So, I know I brought up this topic of PyGTK etc. before only about six months ago, but the computing landscape continues to change rapidly. So, what do people have to say now about using GTK+ (which the OLPC supports) for cross platform educational work these days, especially on the Mac and PC (since GNU/Linux support will be excellent)? Previously when I asked this there was a big groan from the Macintosh side of the Python educational community (at least from Brad Miller, see below). However, since then there is a continuing move for Aqua support for GTK. See: http://developer.imendio.com/projects/gtk-macosx "This is the project site for the effort to port Gtk+ 2 to Mac OS X natively (so that you can run Gtk+ applications without X11 on Mac OS X)." And from:: http://www.pygtk.org/ "PyGTK 2.10.0 includes the following new features: ... MacOS X support" Brad Miller had written back in June: http://mail.python.org/pipermail/edu-sig/2006-June/006571.html "There is some work in GTK+ 2.9.x to get a native port of GTK working on the mac. Maybe when this effort is finally successful then native versions of vpython and other packages will be easier. .. But I also think that the effort required to get everything working under X11 would be too difficult for many beginners." So, is this still true six months later for shipping pyGTK based applications? Or should GTK now be considered a reasonable choice for applications to run under Mac and GNU/Linux? Anyone out there having easy success with pyGTK applications on the Macintosh? And if it works, is it still too bleeding edge to count on? As for Windows, it's long been working OK there as an easy install, right? Still, the installations I see seem to be separate packages, so it is not as easy as with wxWidgets, where I bundle the wxPython & wxWidgets libraries with the Windows application, right? So, I guess my general question is, is pyGTK now an acceptable choice for applications that want to run on Mac, PC, GNU/Linux and the OLPC project? And if it is not, perhaps because of the Mac, is it likely within, say, six months of being an easy install on the Mac? (Software takes a long time to write and debug, so that time frame is reasonable for cross-platform support.) For reference, my most recent google search: http://groups.google.com/group/comp.lang.python/search?q=mac+pygtk&start=0&scoring=d&hl=en& turns up this comment: http://groups.google.com/group/comp.lang.python/browse_thread/thread/2ceb94790c8077c2/4339b2fc9f2fba95?lnk=gst&q=mac+pygtk&rnum=1&hl=en#4339b2fc9f2fba95 "GTK is being ported to Aqua, but the port it is in its early stages." And also: http://groups.google.com/group/comp.lang.python/browse_thread/thread/2ceb94790c8077c2/20f9a2e4e653f5b9?q=mac+pygtk&lnk=nl&hl=en& "GTK 2.8 uses an abstraction layer for drawing widgets called "Cairo". Cairo can use OpenGL or Quartz as backends (still experimental). Thus, you can get a hardware-accelerated GUI from PyGTK if you are willing to use an experimental backend in Cairo." In any case, moving forward, for me, in Python, I think the choices are down to Jython + Swing vs. Python + pyGTK (assuming I don't try to write code at a level of abstraction that make the system mostly widget independent :-). --Paul Fernhout
Paul D. Fernhout wrote:
However, for the areas I am interested in, especially educational simulations, being able to run on the One Laptop Per Child (OLPC) platform would be a nice motivating plus. However OLPC does not currently run Java. And with its resource constraints, the best choice for the OLPC is the mainline supported system, which is Python 2.4 (maybe later) and GTK+. http://wiki.laptop.org/go/OLPC_Python_Environment (Some variant of Squeak Smalltalk is another possibility too, as there is work on that.) http://wiki.laptop.org/go/Etoys Now, I don't *need* to support OLPC, and the JVM might run there someday, but I would say that is my biggest sticking point going forward with Jython/Swing if I stick with Python over Smalltalk. Our garden simulator especially is a natural match for the OLPC goals (and we have previously had people in various developing nations interested in it).
Cairo will also be on the laptop (and I believe it's a priority to make it work well), but OpenGL may not be there (unless you bundle it) and will probably perform very badly. The JVM might be on there at some point, but Jython/Swing won't possibly perform reasonably in this generation of the machine. I suspect it's so far from performing well that even a possible later generation wouldn't run it reasonably. Running a local web server is also a valid development platform for the laptop, but probably doesn't fit what you want to do. -- Ian Bicking | ianb@colorstudy.com | http://blog.ianbicking.org
Paul D. Fernhout wrote:
I'm still in a state of flux about where to go next after PataPata Phase I (recently discussed here). Assuming I continue with Python (rather than moving more towards Smalltalk, either Squeak or one for the JVM), what interests me most is working on cross-platform applications (Mac, PC, GNU/Linux).
I am puzzled. Things are difficult enough. You prefer Smalltalk syntax, Squeak is on the OLPC, and you seem interested in the kinds of activities that Squeak, presumably is good at. Why is there an issue? Use Squeak. Can a Squeaklike environment be created in Python?? The answer is either yes, but so.... or no but so what... because there is already a Squeak, and Python folks presumably have better things to spend there time on. Like offering alternatives. Or so it seems to me. Art
Arthur wrote:
Like offering alternatives.
Like this new-on-the-scene effort http://pyglet.org/ """ Pyglet is a cross-platform multimedia library written in pure Python. """ Checked out the svn version. Exciting to see for - among other reasons - it seems to implement what had been kicked around here regarding VPython, i.e. a pure Python - via ctypes - fully native crossplatform windowing, OpenGL capable infrastructure. Humbling - the effort and background needed to pull something like this off. It is early, but with what has clearly been invested in it to date, one suspects the effort will continue to get it to wherever it needs to get. What I imagine to be the underlying axiom from an educational point of view is that it is more infrastructure for doing engaging things by writing pure Python from what - if it were up to me- would be the simplest possible edit/run environment. I don't have a name for the educational philosophy behind such thinking, and don't expect it to become ubiquitous. Justs makes me smile. Art
Arthur- Wow, thanks for the link (and thanks also to you and Ian for the other comments). This is a little like what I tried to do with the PataPata OpenGL window, but that never went very far. Wonder if this system would easily work on the OLPC system? The key point for me (as a lazy programmer :-) is maximum effectiveness for least effort. It's one thing to build a proof of concept or something fun for oneself, but when one starts thinking about how does the biggest audience share what you have made, then the issue becomes ease of installability and how open the license is and how likely the effort will not have legal problems. (On your other post, Squeak has some licensing issues still in flux; it's hard to assess how they will come out as they are not *fun* to deal with for most programmers; Python's legal situation seems much clearer). By the way, in outlining the programming style that makes you smile, you just rediscovered Squeak. :-) The ability to work in Smalltalk all the way down and into the VM is what many people like about it. When working in Python I keep hitting these brick walls or black boxes of the compiler or window libraries which require switching languages and development environments. Now if they could just solve licensing and modularity issues as well as Python had. --Paul Fernhout Arthur wrote:
Arthur wrote:
Like offering alternatives.
Like this new-on-the-scene effort
""" Pyglet is a cross-platform multimedia library written in pure Python. """
Checked out the svn version.
Exciting to see for - among other reasons - it seems to implement what had been kicked around here regarding VPython, i.e. a pure Python - via ctypes - fully native crossplatform windowing, OpenGL capable infrastructure.
Humbling - the effort and background needed to pull something like this off.
It is early, but with what has clearly been invested in it to date, one suspects the effort will continue to get it to wherever it needs to get.
What I imagine to be the underlying axiom from an educational point of view is that it is more infrastructure for doing engaging things by writing pure Python from what - if it were up to me- would be the simplest possible edit/run environment.
I don't have a name for the educational philosophy behind such thinking, and don't expect it to become ubiquitous.
Justs makes me smile.
Art
_______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
By the way, in outlining the programming style that makes you smile, you just rediscovered Squeak. :-)
Please don't say that. I still think you talk/imply/think about the producer/programmer/toymaker on one hand and the consumer/student/player on the other in a different way then what is implied by my smile. Or else, if I redisovered Squeak how hard could it have been to discover it the first time. Doing fun and challenging things on computers is fun and challenging. Did Alan Kay say that first. If so, sorry. Or perhaps I am just too humble to understand my own genius in coming to such a facntastic conclusion. Squeaks pretense issues, and its licensing issues, are - by the way - not unrelated when you look at it. Art
ajsiegel@optonline.net wrote:
Squeaks pretense issues, and its licensing issues, are - by the way - not unrelated when you look at it.
Sometimes I think something like that myself. :-) But, to elaborate on your point a little more (in a toned down way :-): Smalltalk came out of an industrial research lab (Xerox PARC). The people who invented and then built it and refined it were paid industrial employees working in the scope of their duties on company time (though very unusual ones, even by such R&D standards. :-) Its subsequent history for decades involved mainly development by commercial organizations (either as Smalltalk or also as the Macintosh OS which in some sense was a Smalltalk-derivative, but Steve Jobs just got the window system because he left too soon. :-). http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html "One of the best parts of the [1979] demo was when Steve Jobs said he didn't like the blt-style scrolling we were using and asked if we cold do it in a smooth continuous style. In less than a minute Dan found the methods involved, made the (relatively major) changes and scrolling was now continuous! This shocked the visitors, espeicially the programmers among them, as they had never seen a really powerful incremental system before." And: http://americanhistory.si.edu/collections/comphist/sj1.html "Steve Jobs: ... That's the real gem. I'll tell you an interesting story. When I was at Apple, a few of my acquaintances said "You really need to go over to Xerox PARC (which was Palo Alto Research Center) and see what they've got going over there." They didn't usually let too many people in but I was able to get in there and see what they were doing. I saw their early computer called the Alto which was a phenomenal computer and they actually showed me three things there that they had working in 1976. I saw them in 1979. Things that took really until a few years ago for us to fully recreate, for the industry to fully recreate in this case with NeXTStep. However, I didn't see all three of those things. I only saw the first one which was so incredible to me that it saturated me. It blinded me to see the other two. It took me years to recreate them and rediscover them and incorporate them back into the model but they were very far ahead in their thinking. They didn't have it totally right, but they had the germ of the idea of all three things. And the three things were graphical user interfaces, object oriented computing and networking. Let me go through those. Graphical interface: The Alto had the world's first graphical user interface. It had windows. It had a crude menu system. It had crude panels and stuff. It didn't work right but it basically was all there. Objects: They had Smalltalk running, which was really the first object-oriented language. Simula was really the first but Smalltalk was the first official object oriented language. Third, networking: They invented Ethernet there, as you know. And they had about two hundred Altos with servers hooked up in a local area network there doing e-mail and everything else over the network, all in 1979. I was so blown away with the potential of the germ of that graphical user interface that I saw that I didn't even assimilate or even stick around to investigate fully the other two." Essentially Xerox Parc in 1976 (thirty years ago!) invented the computing landscape most of us use now, and Alan Kay was part of that. What we have seen since is mainly just the dispersal and magnification of those ideas (often in a warped or dumbed down fashion, e.g. C++ instead of Smalltalk; XML instead of Lisp). Smalltalk's demise as a major player on the commercial scene in terms of VisualWorks and its predecessor ObjectWorks (*the* leading Smalltalk product, and still the most comprehensive and definitive and most cross-platform -- excepting perhaps Squeak is more cross-platform in theory) was mostly due to greed and mismanagement IMHO by a now defunct company (the current VisualWorks owners bought it cheaply from them). IBM's VisualAge Smalltalk's demise, on the other hand, was mostly due to IBM's decision to back Java (shortsighted and unfortunate I think as IBM had the clout to push Smalltalk syntax through to the masses IMHO). Smalltalk is still actively used by many, but is more of a niche player at the moment (like, say, OCaml or Haskell or Common Lisp), having been eclipsed by Java. The support community for Smalltalk was (at first) mostly commercially oriented, and remains so to some degree. While there were academic users, and in the past decade, especially with Squeak, the number of people using it for academic or free or open source type applications has grown, that has not been the bulk of the history. Even Squeak's most recent evolution was driven by work at Apple and then at Disney, with the Smalltalk principals reprising their roles as employees of large industrial research and development labs, with the licensing ambiguity that sometimes entails in navigating for-profit corporate waters in an emerging free-and-open-source way (i.e. Alan Kay claims Disney is OK with the Squeak changes done there being released, but there is no "peace of mind" letter from Disney signing off on them I am aware of, or related licensing statement in the code). Python on the other hand, was started as a hobby by one person who was based in an academic research lab. It was always given freely. Excepting one bobble with licensing issues (which was corrected and involved a not-for-profit), the licensing situation has always been pretty straightforward from a free software perspective (and is even now GPL compatible). For most of Guido's time with python (except the last few years) he was affiliated with one of two non-profits. Even now his job is at a pro-"open source" corporation which is also releasing several other free and open source projects. The community that grew around Python, while with many commercial users, had a very different emphasis to it. Part of that early community spirit was also from the "Monty Python" humorous yet playfully radical themes (although Guido has said by now he has heard enough Monty Python jokes. :-) Python also has one core definitive free code base as a reference standard implementation (even as there are spinoffs like Jython). Personally, I feel Smalltalk is the better syntax for kids to learn as that purpose was what it was supposedly designed for (if you ignore that most adult programmers come from Algol syntax and have trouble adapting to the syntax initially); Smalltalk keyword: syntax is certainly the easier syntax to use to maintain large bodies of code using powerful tools and is easily extendable by the end user programmer for many new uses including new control structures and iteration concepts; Smalltalk historically also has the better development tools (in part due to the syntax) and also has a better library architecture (e.g. Streams, Magnitude) and better VMs and garbage collection(especially in VisualWorks, and less so in Squeak), and also has benefited from a culture of Smalltalk all-the-way-down (as Squeak exemplifies); Smalltalk has a powerful notion of bracketed nameless code blocks and is a tour de force of one paradigm (objects and message passing). However, Python has the better community (from a free and open source perspective), better license and licensing history, and better breadth and modularity of libraries; Python also is more easily taken up by adult programmers who already know C or a similar Algol-style language because of its Algol-like syntax and also because you can use familiar text-oriented tools like emacs or vi or Scite with it (which makes it easier for it to gain commercial acceptance as a new thing); Python code is clear and concise and maintainable because of the decision to use significant indentation instead of braces or brackets (like Occam); Python also is a standard defined by a reference implementation, which is much better than a standard defined by an ambiguous or incomplete textual specification; Python is easier to do small projects in for people who only know a little of the language, so in that sense it has an easier learning curve as a system. I feel, especially with Ruby's increasing popularity [as effectively a Smalltalk with Algol syntax plus some other bells and whistles], that the *themes* in Smalltalk are the future of most programming. Even Python continues to get more Smalltalk-like, such as the "new classes" changes. Yet, I want to write some programs now, as part of a free and secure ecosystem of such programs. :-) Ironically, in my own case as a typical Smalltalk programmer, because of my own history as a Smalltalk developer working on commercial projects with commercial versions which nonetheless included source as most Smalltalks do, I am in some ways "contaminated" by that experience and the current overly broad reading of copyright and that puts into potential question anything I develop which is a Smalltalk-derivative (unless I do it very, very carefully, say by using mostly GNU Smalltalk sources); not to say I ever would use such commercial code, just that I might face the effectively impossible task of proving I had not if there was any coincidental similarity at all (which is a much smaller problem when I am working with something very different like Python). If I perhaps oversimplify, essentially the choice right now is between elegant syntax, uniform abstractions, and powerful tools, embodied in a system originally designed for kids by big corporate R&D (Smalltalk) versus practical syntax, uniform community history of freedom, and powerful economic forces, embodied in a system originally designed for adult programmers by an academic researcher as a hobby project which grew beyond initial expectations (Python). :-) Both languages along with their communities have different strengths and weaknesses, and also both have subcultures which are in opposition to the main (e.g. mostly commercial Smalltalk has several free versions, mostly free Python has heavy proprietary commercial usage where no doubt such users have large interesting and yet proprietary libraries). That the strengths and weaknesses are so different in different areas and that one must also assess where trends are heading when embarking on big projects is why I am in conflict about which to use (especially for writing educational simulations), and that is why I tried to mix the best features of the two in the PataPata experiment -- though perhaps ended up with the worst features of the two in some ways (Smalltalk's . :-). Barring moving that PataPata project forward somehow, I am left with a situation that I either have to put a lot of work into a free Smalltalk (Squeak, GNU, A Little Smalltalk, Bistro, Sharp Smalltalk, etc.) to make it more to my liking (e.g. mainstream widgets for Squeak, build tools for GST or Bistro, etc.) or I have can use Python + GTK or wxWidgets or Jython + Swing out of the box, and just accept greater maintenance issues down the road (e.g. debugging and modifying a running program is so easy in Smalltalk, in Python it doesn't quite work right, even with tools I have built to make it easier [posted to the Jython list]). While I haven't made a big point of it, in the past, my choice of Python in the past has also been motivated by the "contamination" issue I mentioned above as well. It may well be the deciding factor once again, sadly -- ironic to not be able to use and improve a wonderful thing you have experienced precisely because you have experienced it.(*) :-( Happy Solstice. --Paul Fernhout (*) Note: most people may not be as concerned about such a theoretical "contamination" issue as I am, since obviously this is a major problem for almost all Squeakers, and most likely for all the major developers on that project. And, on a practical point, I can Agree with Alan Kay who maintains that most copyright issues are not settled by any sort of logic (more by jury emotion in reaction to vague or inconsistent laws) and so there is at least some justification for ignoring *potential* problems related to the edge of copyright. Still, I feel better avoiding even the appearance of potential controversy of that sort (I navigate too many oceans of controversy of other sorts, e.g. unschooling, transcending war through sustainable development, designing self-replicating space habitats, returning to a a gift economy, etc.. :-)
Paul D. Fernhout wrote:
ajsiegel@optonline.net wrote:
Squeaks pretense issues, and its licensing issues, are - by the way - not unrelated when you look at it.
Sometimes I think something like that myself. :-)
But, to elaborate on your point a little more (in a toned down way :-):
It is hard to know how to respond. I don't know how to tone down on this particular issue any more than I have. If you want to call it an obsession, OK. You can search the archives of edu-sig and find me obsessively attacking Kay and not Squeak itself, but Kay's positioning of Squeak, from the earliest days here, and suffering attacks here for doing so as: a) being presumptuous. b) being irrelevant. Let's leave it that I fully accept the standard history, the importance of Smalltalk, the role of Kay during the period of history which you recount. And the fact that he is un-shy about recounting it, and having others recount it on his behalf, provides him with certain powers, but with certain responsibilities. I am not a fan of how he has handled that power and those responsibilities. But that if I have not yet successfully communicated why I firmly believe his later efforts, his later approach and most particularly his later "rap" is more destructive than productive, I guess that I have to resign myself to the fact that I never will. I assure you, I am making perfect sense to myself - however. Art
Arthur- Sorry, to be clear my point here on "toned down" was mainly about the specific statement you made, or rather the use of the specific word "pretense". I toned "pretense" down in my mind and replied more to specific issues relating to Smalltalk history and the funding of Squeak's core developers for a long time, and how Squeak has perhaps struggled to meet those objectives and hopes and aspirations for it (including many educaitonal ones) in part because of that history. :-) Whereas Python and its core community is in those ways on a more solid footing. On a practical reality, I fired up the latest Squeak the other day and beyond my usual confusion with it relating to not mapping right mouse to popup a context-determined menu, :-) within minutes I was generating exceptions and so on as I tried to use other-than-trivial code included with the system (e.g. running the script to change underscores to colon equals, as well as some other things I forget off hand). I knew more than one person who in years past inspired by an Alan Kay presentation have tried Squeak only to encounter lots of bugs and problems with the core tools or trying to duplicate the demos he shows. Python never has done that to me. That's why I tend not to recommend Squeak to anybody but either die-hard Smalltalkers or people looking specifically to stretch their minds (which of course in theory includes kids :-). Whereas almost all the people I recommend Python to, on a practical basis, come away impressed and become users; Python fits into their ecosystem of tools and existing ideas fairly easily. That makes me sad because I know Smalltalk does not have to be that way; I know if I recommended, say, VisualWorks to people, they would not be experiencing those basic problems (and there is no reason Squeak's features like eToys or 3D Croquet could not run on such a stable platform, in theory). Unfortunately VisualWorks is not "free" in a "free as in freedom" sense the mainline Python version is. Of course I could fix Squeak's specific problems (as I see and experience them) with enough effort (in theory, with enough free time, which is limited at the moment), since the source is there. But then I am left with the licensing issues including the status of Disney contributions (which the community is slowly moving to resolve). And then I have my own fork to maintain, which is extra effort. I have wrestled with the Squeak community before on those issues, and realized, like any community and mailing list, a self-selection process has already gone on a long time there, so if you don't like Squeak how it already is, you are probably not hanging around on the main lists there. So there may be plenty of people who want a different Squeak, but most of them are not easily reachable (at least via the Squeak mailing list). The Python community is more inclusive by comparison, in the sense that Python as a language is much more agnostic on several points (including GUI and tools). So there is more room for experimentation there in some ways. Or, at least, there is a bigger potential audience of users and collaborators for a successful experiment, like perhaps the Pyglet OpenGL GUI system you mention. Python better supports such effort in some ways because of its modularity and community history (which I outlined previously). Some Squeakers have been so defensive for so long (often, though not always, with good reason) that innovation or adopting certain standards is harder there (witness a recent conflict about whether keyboard input focus should follow the mouse (Squeak) or follow a mouse click to shift focus (almost everyone else), not to say there isn't a good argument for the Squeak way). Plus, the copyright "contamination" issue sadly will always remain; there is no denying I have exposed to the source of commercial Smalltalk incidentally in the process of using them. I could never work in a Smalltalk-rebuilding "clean room" effort. In other free software development contexts, say, people working on GNU ClassPath as an alternative set of libraries to Java, the biggest "no, no" is to have seen a related vendor's source and then contribute to that project. Example: http://developers.slashdot.org/article.pl?sid=05/03/17/0155235 "Read the fine license, in particular the definition of Modifications in SCSL 2.3. Sun claims copyright on any code independently implementing any portion of the SCSL-licensed technology *if* you agree to their license. So please don't look at their code if you intend to contribute to free runtimes in the future. It's the same as Microsoft's Shared Source in a different wrapping." There is probably almost no significant Squeaker who has not been exposed to the core code of one of VisualWorks, Smalltalk/V, Dolphin, VisualAge, or a few other commercial Smalltalks. Of course, how well an overly broad attempt against Squeak would stand up in court is a different issue; it certainly also would not play well politically in terms of negative PR to the vendor. In some ways, in the end, this single issue may mean the death of free Smalltalks long term (barring one major vendor freeing their version) -- the fact that Smalltalk was "open source" (taken literally) embodied in proprietary products for so long but not "free". Which is one reason Richard Stallman dislikes the term "open source" as it deemphasizes the freedom aspect. :-) In essence, the history of Smalltalk is "brilliance shackled". Since its conception, the history of Python is "pragmatism unshackled". :-) Still, I abhor having to, like Daedalus, turn away from brilliance for pragmatic reasons, even though I know what happened to his son Icarus when he did not. :-) http://thanasis.com/icarus.htm Especially considering Python was designed as a workhorse, and Squeak was supposedly designed for kids and education (both the focus of this mailing list, and an interest of mine). [Of course the metaphor is inverted here since Smalltalk is really the older of the two and if anything more like conceptually the father of Python. I need another myth where the father encounters disaster the son avoids because the sun is plugged into a different community spirit or Zeitgeist. :-)] --Paul Fernhout Arthur wrote:
Paul D. Fernhout wrote:
ajsiegel@optonline.net wrote:
Squeaks pretense issues, and its licensing issues, are - by the way - not unrelated when you look at it.
Sometimes I think something like that myself. :-)
But, to elaborate on your point a little more (in a toned down way :-):
It is hard to know how to respond.
I don't know how to tone down on this particular issue any more than I have. If you want to call it an obsession, OK. You can search the archives of edu-sig and find me obsessively attacking Kay and not Squeak itself, but Kay's positioning of Squeak, from the earliest days here, and suffering attacks here for doing so as:
a) being presumptuous. b) being irrelevant.
Let's leave it that I fully accept the standard history, the importance of Smalltalk, the role of Kay during the period of history which you recount.
And the fact that he is un-shy about recounting it, and having others recount it on his behalf, provides him with certain powers, but with certain responsibilities.
I am not a fan of how he has handled that power and those responsibilities.
But that if I have not yet successfully communicated why I firmly believe his later efforts, his later approach and most particularly his later "rap" is more destructive than productive, I guess that I have to resign myself to the fact that I never will.
I assure you, I am making perfect sense to myself - however.
Paul D. Fernhout wrote:
If I perhaps oversimplify, essentially the choice right now is between elegant syntax, uniform abstractions, and powerful tools, embodied in a system originally designed for kids by big corporate R&D (Smalltalk)
I've never met a kid who wrote an iota of Smalltalk. Do I conclude that Smalltalk was a failed R&D project, with lucky side-effects? I don;t need to.particularly, but can adjust my thinking if it better reflects the history. The very successful people I *can* lunch with (and there are a few who will deem to have lunch with me) tend to have some sense and appreciation of right place, right time. Art
participants (4)
-
ajsiegel@optonline.net -
Arthur -
Ian Bicking -
Paul D. Fernhout