Andreas- Welcome onboard Edusig. I guess your appearance here signals a real interest in the core Squeak team in Python? (For those of you who do not know Andreas, he did the original Squeak port to Windows, plus many other neat Squeakish things, especially 3D ones.)
Thanks for your clarifications; I was responding mainly to the intent outlined here, http://www.redhat.com/archives/olpc-software/2006-April/msg00035.html which seemed a little more ambitious. Also, having dealt with this issue of stuff in a browser in other settings, I think it is wandering into an area that is a little more complex than is alluded to (as nice as the ideas you suggest are, including dynamic translation to multiple backends, like Jython already can do for Python on Java). For the biggest example problem, people expect the "Back" button in a browser to do certain things. So, in LogoWiki, does the back button reset the simulation? Not saying whether it should or not -- just that this is the kind of area where expectations tend to get violated. For another example, people expect URLs to be a good description of state. So when I press the run button, and then cut and paste the URL, does that produce the identical output bitmap for another user? Again, I'm not saying whether it should or not -- just that this is another potential area of violated applications -- because you are trying to use a browser in a way people have little experience with. I'm not saying what the LogoWiki team has done is not interesting, or a great demo (if I could see it :-), but I am saying that trying to put complex content in a web browser is fraught with lots of perils, because you end up trying to map a complex set of possibilities made possible by simulation and interactive editing into a very specific set of expectations derived from dealing with hypertext. Let me give a more concrete example of a "thin client" for a complex task failing in practice, from here: http://www.theserverside.com/tt/articles/article.tss?l=NakedObjectSeries_5 "What is really beginning to force the issue, however, is the growing awareness of the limitations of the browser interface from a user perspective. Our opening example is one of many. A couple of months ago we met with a large company in the engineering supplies business. They had launched an online application that allowed their frequent customers to order supplies, and provided other functionality to help those customers manage certain aspects of their own businesses. The new application has already been very successful in business terms. With a familiar browser-based interface it was easy for their customers to learn. Within weeks of the launch, however, the most active customers were beginning to express frustration with the user interface: not just because of the slow response time but with the strong modality. Keeping multiple jobs open at once, moving or copying objects between those jobs, dealing with a phone enquiry in the middle of a task - all the realities of their customers' businesses - are difficult if not impossible on the browser-based system." That article goes on to make a very important distinction: "The web browser was designed for navigating hypertext documents; it has adapted well to very simple business transactions, but not to more complex tasks. Alan Cooper made a useful distinction (see http://www.cooper.com/articles/art_your_programs_posture.htm ) between 'sovereign' applications (used intensively) and 'transient' applications: his point being that they have very different user interface needs. The thin client architecture can often meet the needs of a transient application: Amazon.com and its one-click ordering is possibly the epitome of this approach. But a browser-based interface, with its strong sequentiality and modality, is totally unsuited to sovereign applications." So, a deep question for an educationally-oriented developer is, do you want to focus on supporting "transient" educational experiences or "sovereign" educational experiences? Since I personally think the educational value in an interactive programming environment is more in how it lets kids learn by doing, I personally am far more interested in providing learners and designers with open ended tools (which was also Kay's original emphasis) than canned "educational" content. Although I'll admit that if a learner can find such "canned" content when they want it, that is a very good thing, so I'm not entirely against such content -- just a matter of emphasis. And, at the very least, even if you want to deliver such content with the web (e.g. Ajax or Flash or Java applications derived from Python or Smalltalk), that does not mean that your development environment also has to run on Ajax (or Flash, or Java, or whatever). I also think the analogy to Wikipedia is somewhat problematical and may miss the forest for the trees. Sure, Wikipedia has a lot of specific interesting pages which users wander onto. But "Wikipedia" is a complex platform both in a social sense and in a technological sense, even if the content is served through a web browser. It's kind of like looking at Squeak and its community and saying, well, that's just about clever use of BitBlit, so let's make BitBlit better. I feel that just trying to make more dynamic pages misses the broader issue here of Wikipedians (the authors) interacting with a very large system with a long persistent history and surrounded by a community. It's ironic that when I started thinking about contributing to Wikipedia some time back, my reaction is that it needs local tools to it can be a distributed network to share server load and allow people to visualized relationships between articles and authors in 3D (i.e. perhaps something built on Squeak :-). So, I had a very different set of thinking about that forest heading in a very different direction. I'm not saying, say Wikipedia, could not benefit from LogoWiki technology, just that I don't see that as a really big win, compared to say, just using Flash or Java Applets for dynamic content. What's really happening here is just a battle over standards for end user content delivered over the internet. A nice win, maybe, to use more open solutions like JavaScript over Flash, and so a battle worth fighting, but not a big win in-and-of-itself for education. And many solutions can coexist. And it seems to me that Alan Kay's work was always about the big ideas. And if one is going to fight the battle directly, then perhaps it might be easier at this point to argue more for Java solutions (as problematical as they are) like Java Applets or Java web start. For the Python Community, Jython already runs on those, so it is a "good enough" solution. So, maybe targeting Jython/Java (or using a similar compatible approach) is another way to go, even for Smalltalk related systems. [I have a bit more to say on Squeak/Python/Jython issues I'll put in another post.] --Paul Fernhout Andreas Raab wrote: > Paul D. Fernhout wrote: > >>I don't mean to complain specifically about these pages, just to point out >>that while the supposed intent here is to make programming available to >>the masses by using a dumbed down environment like a web browser, in >>practice, this fails for me. Whereas, when I install Squeak or Python, it >>works. So, I think Alan Kay may be going in the wrong direction here in >>some ways, compared to Squeak. Not to say it might not be useful for >>certain audiences, just that it fails the "everyone" test, at least for me. > > > Not surprising, really, because you're missing the point of Logowiki. > Logowiki's main purpose is as an example for what "dynamic content" on a > web page can mean, in particular in an educational setting. Remember > that we lost the ability to author with the introduction of the world > wide web and we're only about to get it back. The choice of Logo is > simply because it's easily recognizable for the intended target audience. > > [A secondary motivation for Logowiki is as an experiment in "zero > install" deployment and to be able to see what can be done with Ajax and > friends and a bit of compiler translation technology which is not so > different from PyPy btw - parts of it would make perfect sense to > translate Python to Javascript code on the fly] > > >>And of course, the site was also inaccessible when I first learned about >>it (from Kirby's post to this list I think) from too much demand most >>likely, so it also failed the cost test. Presumably, they just could not >>afford to put enough resources into the project for "everyone". > > > Paul, you are confusing a demo with a product. Logowiki was done to > explain to OLPC what we mean when we use terms like dynamic content and > what may change if, for example, Wikipedia had the ability to included > such dynamic, end-user authored content. _______________________________________________ Edu-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/edu-sig
