From francois.schnell at gmail.com Thu Mar 1 07:59:39 2007 From: francois.schnell at gmail.com (francois schnell) Date: Thu, 1 Mar 2007 07:59:39 +0100 Subject: [Edu-sig] OLPC: first thoughts on the first keynote at Pycon In-Reply-To: <13a83ca10702231407m1f8afc3fve84b5518539696bc@mail.gmail.com> References: <7528bcdd0702230938k6458a5ceh9f2167de3741fb9f@mail.gmail.com> <13a83ca10702231407m1f8afc3fve84b5518539696bc@mail.gmail.com> Message-ID: <13a83ca10702282259s614782dew5447e348f4fcc536@mail.gmail.com> On 2/23/07, francois schnell wrote: > > > I hope someone recorded that if so it looks like it should appear in the > future on this page (items): > > http://us.pycon.org/zope/talks/2007/fri/track3/004/talkDetails Well, still nothing. I imagine it will be available in weeks or months to come. During the same time frame there was another OLPC presentation in Bruxelles at the FOSDEM 2007 ('Free and Open source Software Developers' European Meeting'). The speaker was Jime Gettys, http://en.wikipedia.org/wiki/Jim_Gettys and the video is available here: http://ftp.belnet.be/mirrors/FOSDEM/2007/FOSDEM2007-OLPC.ogg The video format is Ogg/Theora. It will play fine in VLC player for example. http://www.videolan.org/ -- francois schnell -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20070301/eea5693e/attachment.htm From kirby.urner at gmail.com Thu Mar 1 20:37:22 2007 From: kirby.urner at gmail.com (kirby urner) Date: Thu, 1 Mar 2007 11:37:22 -0800 Subject: [Edu-sig] Another Python thread @ Math Forum (URL) Message-ID: Links to some Pythonic screencasts, several already mentioned here, so please excuse the redundancy. http://mathforum.org/kb/message.jspa?messageID=5546620&tstart=0 Kirby From kirby.urner at gmail.com Sat Mar 3 00:57:22 2007 From: kirby.urner at gmail.com (kirby urner) Date: Fri, 2 Mar 2007 15:57:22 -0800 Subject: [Edu-sig] More pipeline developments Message-ID: My daughter's school, one of Portland Public's is looking at maybe doing Scratch -> Squeak -> Alice pre Python (they don't always get to Python except with exceptional students as this school maxes out after 8th grade). I just learned this in a meeting this afternoon (I'm not the one making these decision). I'm downloading Scratch right now to begin my evaluation. The more I understand about the Immersion Phase, the better will be my Pythonic bridges to high school algebra and geometry. If other subscribers to edu-sig have success stories using Scratch, I'd be interested in learning about 'em. Here's the web site for those new to this language (note Linux version in the works): http://scratch.mit.edu/ Note: according to the emerging sequence, languages like Scheme (LISP), J (R, APL), xBase (SQL), and system languages like the C family (Java, C#), M, would all tend to build on pre college Python skills acquired in mainstream math class (or from an elective track, if the state is antediluvian). Those Python skills would in turn build on an understanding of data and control structures acquired in more cartoony environments, with more emphasis on programming by dragging and dropping than on typing a lot of code. Kirby From m.slg at gmx.de Sat Mar 3 17:21:11 2007 From: m.slg at gmx.de (Markus Schlager) Date: Sat, 3 Mar 2007 17:21:11 +0100 (CET) Subject: [Edu-sig] More pipeline developments In-Reply-To: References: Message-ID: On Fri, 2 Mar 2007, kirby urner wrote: > If other subscribers to edu-sig have success stories using > Scratch, I'd be interested in learning about 'em. Here's > the web site for those new to this language (note Linux > version in the works): http://scratch.mit.edu/ > The .exe is just a self-extracting zip-archive. You can run the .image included with squeaks VM on Linux as well. If you use the archives directory-structure as is, the only thing not working is the fullscreen-presentation-mode. Three or four weeks from now I'm going to use Scratch with my 7th-graders at a German Gymnasium as starting point to teach them algorithmic thinking, which I consider it a _really_ good tool for. I don't have to care about syntax or typewriting and am able to focus on the core concepts from the very beginning. Markus From kirby.urner at gmail.com Sat Mar 3 19:13:26 2007 From: kirby.urner at gmail.com (kirby urner) Date: Sat, 3 Mar 2007 10:13:26 -0800 Subject: [Edu-sig] More pipeline developments In-Reply-To: References: Message-ID: > The .exe is just a self-extracting zip-archive. You can run the .image > included with squeaks VM on Linux as well. If you use the archives > directory-structure as is, the only thing not working is the > fullscreen-presentation-mode. > > Three or four weeks from now I'm going to use Scratch with my 7th-graders > at a German Gymnasium as starting point to teach them algorithmic > thinking, which I consider it a _really_ good tool for. I don't have to > care about syntax or typewriting and am able to focus on the core > concepts from the very beginning. > > Markus Thank you Markus. Yes, I think the ability to drag an instruction (like a puzzle piece) then click on it to see immediate sprite behavior (like a command line), then combine it with other instructions and feeding these chunks to yellow control structure puzzle pieces (e.g. "forever") including event triggers (when green flagged, when clicked) is both brilliantly conceived (yes, there's lineage behind it) and cleanly implemented. Thank you MIT. I think with toyz like this it's important to emphasize to kids what they're learning (e.g. "about control structures" like you said), or they might think they're being patronized, as the resulting sprite dances aren't really ready for prime time in a film making sense, nor is this an easily sharable medium, ala the omni- present Flash and/or Shockwave. But the point isn't film making. You'd use a multi- track editor for that. This is more for thinking in terms of objects and their source code internals, without having to type a lot. And speaking of objects, there is a sense of economy that's violated, seeing the exact same code duplicated to sprite after sprite. The little OO ego within me cries out for a more centralized respository of class definitions with each sprite getting a hook thereto, plus a scratch pad for local memories -- for an environment more like Python's in other words, with a greater sense of economy and efficiency. Kirby From kirby.urner at gmail.com Sun Mar 4 03:34:33 2007 From: kirby.urner at gmail.com (kirby urner) Date: Sat, 3 Mar 2007 18:34:33 -0800 Subject: [Edu-sig] Scratch: blog mention Message-ID: Archival... a mention of Scratch in my blog: http://mybizmo.blogspot.com/2007/03/add-multiply-or.html Note close proximity to Pythonic Algebra videos. Kirby From kirby.urner at gmail.com Mon Mar 5 22:32:40 2007 From: kirby.urner at gmail.com (kirby urner) Date: Mon, 5 Mar 2007 13:32:40 -0800 Subject: [Edu-sig] Fan mail for pythonic mathematics Message-ID: Excerpts from my fan mail pile. Kirby === From: Young, Randall Shane [mailto:rasyoung at indiana.edu] Sent: Saturday, January 27, 2007 9:18 AM To: urnerk at qwest.net Subject: You've got a lot of cool stuff! Hi Kirby, I'm a 3rd. year PhD student at Indiana University, majoring in Science Ed.. Desperately trying to keep my colleagues from throwing all the math out of our science curricula. I noticed from your way cool videos, that you use Camtasia Sutdio too? Have you seen this IDE? http://code.google.com/p/pyscripter/ Just keeps getting better and better! Anyway thanks for the all the interesting material, I'm going to learn a lot. Best, Randy Young AI Indiana University School of Ed === From: Rob Hudson [mailto:rob at cogit8.org] Sent: Sunday, February 04, 2007 4:08 PM To: urnerk at qwest.net Subject: Python and Math Hello, I just stumbled upon your pages here: http://www.4dsolutions.net/ocn/crypto0.html while searching for some information on the Enigma machine. I'm taking a Cryptography class at the UofO in Eugene and was (am) having some trouble on the topics of factorization and products of permutations, as it relates to the cycles of the Enigma machine. Your writings helped me solidify some of my thinking and I've bookmarked it for catching up with later. Just wanted to say thanks. It looks like there is a lot of great stuff there, and in Python -- my current favorite language. :) Cheers! Rob From kirby.urner at gmail.com Fri Mar 9 02:09:55 2007 From: kirby.urner at gmail.com (kirby urner) Date: Thu, 8 Mar 2007 17:09:55 -0800 Subject: [Edu-sig] Easter Egg Hunt Message-ID: Here's a kind of little puzzle you can use with your students to motivate their understanding of nested collections. Given 'hunt' what subscripts will get you the egg? >>> hunt = [({"easter":[1,2,{(3,4):"egg","chocolate":[(1,'bunny')]}]},())] Answer: >>> hunt[0][0]["easter"][2][(3,4)] 'egg' Variations on that theme. Not as hard as it looks, if you let them drill down using some trial and error: >>> hunt[0][0] {'easter': [1, 2, {(3, 4): 'egg', 'chocolate': [(1, 'bunny')]}]} >>> hunt[0][0]["easter"] [1, 2, {(3, 4): 'egg', 'chocolate': [(1, 'bunny')]}] >>> hunt[0][0]["easter"][2] {(3, 4): 'egg', 'chocolate': [(1, 'bunny')]} >>> hunt[0][0]["easter"][2][(3,4)] 'egg' Kirby From bblais at bryant.edu Sat Mar 10 16:33:24 2007 From: bblais at bryant.edu (Brian Blais) Date: Sat, 10 Mar 2007 10:33:24 -0500 Subject: [Edu-sig] minimum age to learn python (a.k.a graphical vs text languages) Message-ID: <45F2CFC4.5010801@bryant.edu> Hello, I was wondering what the approximate minimum age to learn python is. Has anyone had experience teaching middle school students, or elementary school students Python? What brought this up for me is thinking about starting a Lego robots group in a local middle school. I only teach college, and have little experience with middle school students, so I find it hard to guess what they could actually do. I started programming when I was about 5th grade, on a Commodore VIC 20 (3.5k RAM!) in basic, but I don't think I am typical. (Of course, now, you can probably infer my age to within 2 years! :) ). I've written something so that students can program in Python syntax to run the Lego Mindstorms robots. The most commonly used language for these robotos, in the middle school, is Robolab which is entirely graphical. Although a good program, I find there are some drawbacks: 1) Robolab is commercial, and not all schools can afford this above and beyond the price of the lego mindstorms 2) Robolab only runs on Mac/Windows, and not Linux, so those schools that have tried to save money on the operating system get whacked there too 3) Robolab can *only* do Lego robots. Although you learn the basic language structures (loops, branching, etc...), because it is graphical, Robolab doesn't translate directly. Perhaps this is enough for kids to start, but perhaps one can do better. On the other hand, my pynqc tool (which uses the freely available nqc language for the Lego Mindstorms) is: 1) free (in both senses) 2) runs on Mac/Linux/Windows 3) because you use python syntax, it is easier to go and do other python projects not involving robots In my mind, this opens up more doors, but it is not graphical. I wanted to hear responses from people who have experience teaching programming in elementary/middle (or even high) school. Do graphical languages make a big difference? Do text-based languages put up barriers to young learners? Is it no big deal either way? thanks, Brian Blais -- ----------------- bblais at bryant.edu http://web.bryant.edu/~bblais From kirby.urner at gmail.com Sat Mar 10 17:37:18 2007 From: kirby.urner at gmail.com (kirby urner) Date: Sat, 10 Mar 2007 08:37:18 -0800 Subject: [Edu-sig] minimum age to learn python (a.k.a graphical vs text languages) In-Reply-To: <45F2CFC4.5010801@bryant.edu> References: <45F2CFC4.5010801@bryant.edu> Message-ID: << questions about others' experience >> > Is it no big deal either way? > > > thanks, > > Brian Blais Hi Brian -- Lego Mindstorms is popular in my neck of the woods (Silicon Forest -- Oregon), starting in middle school. I helped coach a team a few years ago. There's a tournament aspect, with the teams coming together around challenges. I frankly don't know if nqc is a permitted option -- it might be. On the Python side, I volunteered one day a week for about 8 weeks (then for a 2nd 8 weeks, with another group), teaching Python in a Portland public school to 8th graders. I didn't feel they were floundering or having any real trouble keeping up. I wasn't focusing on robotics or controlling an avatar or anything i.e. this experience was not designed to feed the Mindstorms teams. Given the Mindstorms groups tend to be after school, staffed by volunteer parents, the students attracted to them tend to be self selected on the basis of prior experience, self confidance around programming or whatever. My daughter has a kit since Christmas (she's in 7th grade) but hasn't joined a team because she's protective of her time, wants to play and do homework. Plus it's really only the Sony Aibo she cares about and I've never been able to afford one (her dad is not a money god unfortunately). I haven't pushed hard to teach her Python either, though I'm hoping she'll guinea pig (or hedge hog) some of my curriculum materials down the road (we were discussing that yesterday -- she could start by watching a few of my screencasts about Python, high rez versions). I think a typical scenario might be to join a team or form one, using the usual equipment, including Robolab, and then finding, within that group, a couple interested students who might be wanting to try a Linux/Python option. If you have other parents, they'd be candidate learners. If you attract some high schoolers, them too. I think middle school is sort of on the edge of where you'd start, and it's important to have a dynamic where the kids step forward at that level, don't feel pressured. Some type quite well (given all the instant messaging), others not, and lack of typing skills *is* a barrier to entry. Depending on the size of your original pool, you may well catalyze a few promising careers. The public school I mentioned is currently moving to a Scratch -> Alice track, still with the Mindstorms robotics option on the side, as an after school activity. I just talked to the computer teacher yesterday and he was reporting some rumor that future versions of Alice will center around the same Sims as in Sims, which my daughter plays with *a lot* (we also bought Civ City Rome yesterday, coincidentally, and she built Rome in a day). Arthur, a long time member of this list, had many strong reservations about Alice, which tended to become moot after Alice stopped being written in Python. I think he would have preferred like my Saturday Academy class, where I also teach Python, but using a very bare bones mathematical approach, no thick layer of someone else's design (just IDLE + VPython mostly these days, plus I admit to pre writing some py files -- we don't reinvent all of mathematics, me neither). I get a few middle schoolers in these classes, but only a couple, and usually already about two standard deviations in the college level direction. Kirby From andreas.raab at gmx.de Sat Mar 10 21:43:53 2007 From: andreas.raab at gmx.de (Andreas Raab) Date: Sat, 10 Mar 2007 12:43:53 -0800 Subject: [Edu-sig] minimum age to learn python (a.k.a graphical vs text languages) In-Reply-To: References: <45F2CFC4.5010801@bryant.edu> Message-ID: <45F31889.6040201@gmx.de> kirby urner wrote: > I just talked to the computer teacher yesterday and he > was reporting some rumor that future versions of Alice will > center around the same Sims as in Sims, which my daughter > plays with *a lot* (we also bought Civ City Rome yesterday, > coincidentally, and she built Rome in a day). More than rumor apparently: http://www.cmu.edu/cmnews/extra/060310_alice.html Cheers, - Andreas From kirby.urner at gmail.com Sat Mar 10 21:51:41 2007 From: kirby.urner at gmail.com (kirby urner) Date: Sat, 10 Mar 2007 12:51:41 -0800 Subject: [Edu-sig] minimum age to learn python (a.k.a graphical vs text languages) In-Reply-To: <45F31889.6040201@gmx.de> References: <45F2CFC4.5010801@bryant.edu> <45F31889.6040201@gmx.de> Message-ID: On 3/10/07, Andreas Raab wrote: > kirby urner wrote: > > I just talked to the computer teacher yesterday and he > > was reporting some rumor that future versions of Alice will > > center around the same Sims as in Sims, which my daughter > > plays with *a lot* (we also bought Civ City Rome yesterday, > > coincidentally, and she built Rome in a day). > > More than rumor apparently: > > http://www.cmu.edu/cmnews/extra/060310_alice.html > > Cheers, > - Andreas Hey thanks! Fowarding to my daughter FYI. Kirby From mahs at telcopartners.com Mon Mar 12 00:22:02 2007 From: mahs at telcopartners.com (Michael Spencer) Date: Sun, 11 Mar 2007 23:22:02 +0000 (UTC) Subject: [Edu-sig] Reloading code (was Re: OLPC: first thoughts) References: <7528bcdd0702230938k6458a5ceh9f2167de3741fb9f@mail.gmail.com> <45DF84DC.2060003@kurtz-fernhout.com> <45E04E19.4000502@kurtz-fernhout.com> <45E0EE8E.7090709@kurtz-fernhout.com> <45E1C102.4050706@kurtz-fernhout.com> Message-ID: Paul D. Fernhout kurtz-fernhout.com> writes: > This xreload module Guido supplies is similar to the approach I used for > Jython in my earlier link. > http://www.arcknowledge.com/gmane.comp.lang.jython.user/2006-01/msg00023.html > If you look at that thread, I acknowledge Michael Spencer as having > supplied some of the more sophisticated reload logic which is similar to > what Guido has posted here (not sure where Michael got it from of course, > nor where Guido got xreload from). See Michael's first related post here: > http://www.arcknowledge.com/gmane.comp.lang.jython.user/2006-01/msg00016.html > FWIW, I still tinker with the reloading issue from time to time, in pursuit of a fully-interactive environment. My latest module is at: http://svn.brownspencer.com/pynote/trunk/Mupdaters.py. It's not documented for standalone use, but may contain some useful ideas, and I'd be happy to discuss it if anyone were interested. Incidentally, class bodies provide one of the hard problems for reloading. Ideally, for reloading, one would execute the class body in a proxy of the existing dict, as for modules, but this can't be achieved with the same exec in approach. In order to work-around this, I wrote a pure-python compiler. With this, it becomes possible to modify the class definition bytecode to execute the class definitions in the existing class dict rather than a new one. The compiler itself is at: http://svn.brownspencer.com/pycompiler/branches/new_ast/ . However, I have not yet connected it into the reloading module. Michael From pdfernhout at kurtz-fernhout.com Mon Mar 12 14:26:33 2007 From: pdfernhout at kurtz-fernhout.com (Paul D. Fernhout) Date: Mon, 12 Mar 2007 09:26:33 -0400 Subject: [Edu-sig] Reloading code (was Re: OLPC: first thoughts) In-Reply-To: References: <7528bcdd0702230938k6458a5ceh9f2167de3741fb9f@mail.gmail.com> <45DF84DC.2060003@kurtz-fernhout.com> <45E04E19.4000502@kurtz-fernhout.com> <45E0EE8E.7090709@kurtz-fernhout.com> <45E1C102.4050706@kurtz-fernhout.com> Message-ID: <45F55509.2090807@kurtz-fernhout.com> Michael- Thanks for the update. An entire Python compiler to make it work right? Wow. I don't use many class methods so I've never noticed this problem. Thanks for putting this up, and under the Python license (according to the readme). http://svn.brownspencer.com/pycompiler/branches/new_ast/readme.txt Is this in any ways related to PyPy? http://codespeak.net/pypy/dist/pypy/doc/news.html In the Jython reload case I have noticed a different problem, which is that a method with a call to super__ will fail. super__MethodName is Jython's convention for calling a superclass method, which is especially important to use if the Java method in a Java base class is "protected" as using the alternative BaseClassName.method(self, args) will not work then. It turns out that after a reload in Jython, the newly compiled methods have a slightly different signature than the old ones as I think there is a unique number added to the superclass name, causing the reference to the old super class wrapper to be invalid somehow on a second load Also, if you change the number of arguments to a function, or add a new function, the reload feature also fails. I think these problems may all be related to Jython's internal behind the scenes dispatching using some forms of name mangling which change from load to load. As I write this, I am wondering if those problems only occur when the base class is a Java class as opposed to a Jython base class, though many if not most of my base classes are Java classes (typically JPanel or JFrame), so it is a frequent problem. Nonetheless, I find the reload functionality very valuable, even with these problem of having to restart when adding a function, changing the arguments to a function. A typically way to use this is adding print statements to a function operating unexpectedly for use in debugging. Also I just avoid using super__ use in modules in various ways (which is sometimes difficult as it is the only way I know to call a Java protected method). I don't believe CPython reloading has any of those problems, since it is not doing the kind of reflection Jython does. On the JythonDev list, I submitted this issue as one that might interest an intern for the Google Summer of Code. http://www.nabble.com/Jython-and-Summer-of-Code-tf3350563.html#a9367861 When even Visual Basic or C# or Ruby can do this "edit and continue", I am worried about Python's future if it does not gain this feature. See for example: http://www.codinghorror.com/blog/archives/000507.html While I prefer Smalltalk keyword syntax for being self-documenting over function calls with position arguments, I can weight that against Python's clean syntax using indentation, and say Python syntax and Smalltalk syntax are close in usability. And even if Smalltalk will always also have an edge in edge in easily adding features like new iterators or control structures that require changes to the Python compiler, I can weigh that against Python's broad acceptability in looking a lot like C or Java, especially how easily Jython can interoperate with Java, given the similarity in syntax. BUT, when I weigh being much more productive in an environment like Smalltalk that lets you "edit and continue", Python is the clear loser there. It is only its other virtues (licensing, borad libraries, ease in doing small projects with it, and so on) which save the day there for it IMHO. But that's a little sad -- to see such a great dynamic language tied down somehow over an issue which you would think it would excel at. Now that Guido is at Google, and Google uses Python and does large projects (e.g. the recent AI announcement) http://www.oreillynet.com/onlamp/blog/2005/11/google_library_will_train_goog.html which presumably require modifying long running training processes while they run if they encounter, say, a typo in a variable reference, I would hope building in these features might someday become more of a priority, nudge, nudge. :-) But really, this is the kind of deep thing in Python I would expect Guido would have to be involved in changing; it's probably not like a minor change or add-on in the system -- it might have ramifications throughout the codebase. I doubt anyone would have enough comprehension of Python internals to do as good a job as he could. Note that I think that even if it was impossible in Python to resume from an exception (without major surgery in Python's innards), being able to break on the creation of any exception in the debugger, and then one by one tell the debugger to ignore some of them based on the type of exception or the module it is created in, would probably still be OK enough if you could then edit and continue before the exception was actually raised. This weaker form of "Edit and continue" would be harder to use, but probably still worthwhile given the right IDE tools. It would be more feasible for a Summer of Code student or other contributor to do as a first step. (Generally, you only care about the exceptions that bubble up to the top, since a lot of Python code routinely handles exceptions like for not opening a file or when using exceptions to check the duck typing of something, which is why this weaker form would entail extra work). A lot of IDEs for other languages (like C++) let you control what exceptions the debugger breaks on, so this is not that unfeasible. --Paul Fernhout Michael Spencer wrote: > Paul D. Fernhout kurtz-fernhout.com> writes: > > >> This xreload module Guido supplies is similar to the approach I used for >> Jython in my earlier link. >> http://www.arcknowledge.com/gmane.comp.lang.jython.user/2006-01/msg00023.html >> If you look at that thread, I acknowledge Michael Spencer as having >> supplied some of the more sophisticated reload logic which is similar to >> what Guido has posted here (not sure where Michael got it from of course, >> nor where Guido got xreload from). See Michael's first related post here: >> http://www.arcknowledge.com/gmane.comp.lang.jython.user/2006-01/msg00016.html >> > > > > FWIW, I still tinker with the reloading issue from time to time, in pursuit of a > fully-interactive environment. My latest module is at: > http://svn.brownspencer.com/pynote/trunk/Mupdaters.py. It's not documented for > standalone use, but may contain some useful ideas, and I'd be happy to discuss > it if anyone were interested. > > Incidentally, class bodies provide one of the hard problems for reloading. > Ideally, for reloading, one would execute the class body in a proxy of the > existing dict, as for modules, but this can't be achieved with the same exec > in approach. In order to work-around this, > I wrote a pure-python compiler. With this, it becomes possible to modify the > class definition bytecode to execute the class definitions in the existing class > dict rather than a new one. The compiler itself is at: > http://svn.brownspencer.com/pycompiler/branches/new_ast/ . However, I have not > yet connected it into the reloading module. > > Michael From pdfernhout at kurtz-fernhout.com Mon Mar 12 14:40:13 2007 From: pdfernhout at kurtz-fernhout.com (Paul D. Fernhout) Date: Mon, 12 Mar 2007 09:40:13 -0400 Subject: [Edu-sig] OpenGL 3D graphics in Jython easily deployable with jGL jar Message-ID: <45F5583D.6030904@kurtz-fernhout.com> I'm sad that Art is not around to discuss this, but I came across a 3D graphics system for Java that supports most of OpenGL and is deployable as a single jar file, meaning it is easy to include with a Jython-powered Python application. It can be found here: http://graphics.im.ntu.edu.tw/~robin/jGL/ It's slower than native calls as it is entirely written in Java, but it works on all Java platforms. See my post here on the Jython Users list for more details and some sample code for using it: "jGL: OpenGL 3D Graphics from Jython using pure Java jar" http://www.nabble.com/jGL%3A-OpenGL-3D-Graphics-from-Jython-using-pure-Java-jar-tf3367107.html In theory, you could make Jython systems which looked for JOGL (Java -> OpenGL interface) and if was not present could use jGL if you stuck to the restricted subset. This would make such pythonic 3D applications easily installable anywhere Java was installed, even if Java addons like Java3D or JOGL were not installed (which is not always the case). --Paul Fernhout From mahs at telcopartners.com Mon Mar 12 19:00:40 2007 From: mahs at telcopartners.com (Michael Spencer) Date: Mon, 12 Mar 2007 11:00:40 -0700 Subject: [Edu-sig] Reloading code (was Re: OLPC: first thoughts) In-Reply-To: <45F55509.2090807@kurtz-fernhout.com> References: <7528bcdd0702230938k6458a5ceh9f2167de3741fb9f@mail.gmail.com> <45DF84DC.2060003@kurtz-fernhout.com> <45E04E19.4000502@kurtz-fernhout.com> <45E0EE8E.7090709@kurtz-fernhout.com> <45E1C102.4050706@kurtz-fernhout.com> <45F55509.2090807@kurtz-fernhout.com> Message-ID: Paul D. Fernhout wrote: > Michael- > > Thanks for the update. An entire Python compiler to make it work right? No, the module I linked to is self-contained, although hardly user-friendly, I concede. I believe that custom-compilation *will* be required to tackle some corner cases, but I haven't implemented it. > Wow. I don't use many class methods so I've never noticed this problem. > Thanks for putting this up, and under the Python license (according to > the readme). > http://svn.brownspencer.com/pycompiler/branches/new_ast/readme.txt Yep, Python license. > Is this in any ways related to PyPy? > http://codespeak.net/pypy/dist/pypy/doc/news.html No. It's just an update/replacement for the stdlib compiler package which has several known problems, and which does not support the native Python 2.5 AST. > > In the Jython reload case I have noticed a different problem, which is > that a method with a call to super__ will fail. ... Unfortunately, I don't know any details about Jython's implementation, but this doesn't surprise me. > > I don't believe CPython reloading has any of those problems, since it is > not doing the kind of reflection Jython does. No, although it's pretty easy to come up with corner cases to confuse CPython reloading too. > > > When even Visual Basic or C# or Ruby can do this "edit and continue", I > am worried about Python's future if it does not gain this feature. See > for example: > http://www.codinghorror.com/blog/archives/000507.html I strongly agree. Edit and continue is intuitive for beginners, productive for experts, and anyway the standard set by competitors. ... > > Note that I think that even if it was impossible in Python to resume > from an exception (without major surgery in Python's innards), being > able to break on the creation of any exception in the debugger, and then > one by one tell the debugger to ignore some of them based on the type of > exception or the module it is created in, would probably still be OK > enough if you could then edit and continue before the exception was > actually raised. This weaker form of "Edit and continue" would be harder > to use, but probably still worthwhile given the right IDE tools. I suspect that this requires a customized interpreter, and that pypy might be the vehicle to make this happen. Michael From eric.frost at mp2kmag.com Wed Mar 14 07:36:59 2007 From: eric.frost at mp2kmag.com (Eric Frost) Date: Tue, 13 Mar 2007 23:36:59 -0700 Subject: [Edu-sig] Training or cert References: Message-ID: > Any other recommendation? I'll start that I'm travelling this week so weight was a consideration.. I bought two books so far: Python Phrasebook by Brad Dayley, it looks like it's from Sams Publishing. I love that it starts with only a very simple reference and then launches into examples, the whole book is short examples. Very smart, just like a phrasebook for brushing up on practical German or something. And Python Pocket Reference from O'Reilly -- http://www.oreilly.com/catalog/pythonpr3/ "Updated to cover Python 2.4, Python Pocket Reference, 3rd Edition is the perfect on-the-job reference. For experienced Python developers, this book is a compact toolbox that delivers need-to-know information at the flip of a page. This third edition also includes an easy-lookup index to help developers find answers fast! The Python Pocket Reference, 3rd Edition serves as the perfect companion to Learning Python and Programming Python." I'm not actually sure I have the latest version, it's so small I cannot find it right now in my hotel room :-(. Must be in jacket or something. But anyway I was tickled by the deliberate brevity and compactness, there is no author information for instance. It ends with "Always look in the bright side of life." in the Python tips sections which is perhaps the only digression, yet still practical as well. So this is the start of my "education", just thought I'd follow up and share. Eric http://www.mapvisitors.com From ehlersjp at msn.com Mon Mar 19 01:01:35 2007 From: ehlersjp at msn.com (Joseph Ehlers) Date: Sun, 18 Mar 2007 19:01:35 -0500 Subject: [Edu-sig] python and math skills Message-ID: I posted a question a few years back dealing with 'first languages'. This community was tremendously helpful and because of your help my school now teaches Python and students enjoy the language. Among the most notable outcomes I have noticed is that students are engaged in their learning, they think through their problems and they help each other solve problems (teamwork). My department, Business Education, has no state standards for learning in which students are tested on for No Child Left Behind (NCLB) testing, therefore, I am trying to show how my lessons support, or reinforce, other core academic standards, most notably mathematics. My school is on the NCLB academic watch list and needs to help better develop student's math skills. All departments outside of the core academic departments have been asked by administration to reinforce pre-algebra skills for all students as this is a common skill set among all departments and a tested skill set on NCLB testing. This Python course does reinforce pre-algebra skills, and algebra and some geometry as well as reinforces several Illinois state math standards. In the future I would like to work closely with our math department to try to mirror my Python curriculum with the pre-algebra and algebra 1 classes, this should further help students by reinforcing topics in a timely manner. Currently, the Python curriculum is very introductory, there is no math prerequisite for the course and even special education students take the course and seem to be showing progress in their problem solving and critical thinking skills. I would like to make a recommendation to our administration and counselors that the Python course be 'strongly recommended' for all students. Here is my situation however: my school district recently went to data driven decision-making and all decisions must answer the question, "How will this action impact student achievement?" and they must be backed up with data. Once again, I am asking this community for help. Can anyone point me to data that shows a positive relationship between Python, or programming in general, and increased math skills among students, or increased student achievement on standardized tests? I have found some research that shows a positive correlation between algebra knowledge and a higher success in programming, but does the opposite exist, does programming knowledge help math skills? I have been so pleased with student's eagerness and engagement in the class. The course is basically all math up and down the curriculum but I don't think the students realize that, they view it as electronic puzzle solving. I'm not doing anything out of the ordinary, I'm simply using two books (Computer Programming Is Fun by David Handy and Python Programming for the Absolute Beginner by Michael Dawson) and the students are engaged. If Python is making math fun and engaging then I have to think that students who have some knowledge of Python must be improving their math skills. I will track this data at my school but any other data to support this feeling would be greatly appreciated. Thank you for your help. Joe Ehlers -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20070318/ecab9130/attachment.htm From pchase at sulross.edu Mon Mar 19 01:51:29 2007 From: pchase at sulross.edu (Peter Chase) Date: Sun, 18 Mar 2007 19:51:29 -0500 Subject: [Edu-sig] minimum age to learn python (a.k.a graphical vs text languages) In-Reply-To: <45F2CFC4.5010801@bryant.edu> References: <45F2CFC4.5010801@bryant.edu> Message-ID: <45FDDE91.6010005@sulross.edu> I used to judge science fairs in the DC area. There were junior and senior divisions, and the junior division age range was from 6th to 9th grades. At the time I got the occasional project written in Basic, many of which were very interesting. I would think that Python would easily outclass Basic! It would depend entirely upon the individual student. HTH Brian Blais wrote: > Hello, > > I was wondering what the approximate minimum age to learn python is. Has anyone had > experience teaching middle school students, or elementary school students Python? > What brought this up for me is thinking about starting a Lego robots group in a local > middle school. I only teach college, and have little experience with middle school > students, so I find it hard to guess what they could actually do. I started > programming when I was about 5th grade, on a Commodore VIC 20 (3.5k RAM!) in basic, > but I don't think I am typical. (Of course, now, you can probably infer my age to > within 2 years! :) ). > > > I've written something so that students can program in Python syntax to run the Lego > Mindstorms robots. The most commonly used language for these robotos, in the middle > school, is Robolab which is entirely graphical. Although a good program, I find > there are some drawbacks: > 1) Robolab is commercial, and not all schools can afford this above and beyond the > price of the lego mindstorms > 2) Robolab only runs on Mac/Windows, and not Linux, so those schools that have tried > to save money on the operating system get whacked there too > 3) Robolab can *only* do Lego robots. > > Although you learn the basic language structures (loops, branching, etc...), because > it is graphical, Robolab doesn't translate directly. Perhaps this is enough for kids > to start, but perhaps one can do better. > > On the other hand, my pynqc tool (which uses the freely available nqc language for > the Lego Mindstorms) is: > 1) free (in both senses) > 2) runs on Mac/Linux/Windows > 3) because you use python syntax, it is easier to go and do other python projects not > involving robots > > In my mind, this opens up more doors, but it is not graphical. > > I wanted to hear responses from people who have experience teaching programming in > elementary/middle (or even high) school. Do graphical languages make a big > difference? Do text-based languages put up barriers to young learners? Is it no big > deal either way? > > > thanks, > > Brian Blais > > From pdfernhout at kurtz-fernhout.com Mon Mar 19 06:26:50 2007 From: pdfernhout at kurtz-fernhout.com (Paul D. Fernhout) Date: Mon, 19 Mar 2007 01:26:50 -0400 Subject: [Edu-sig] Comments on Kay's Reinvention of Programming proposal (was Re: More Pipeline News) In-Reply-To: References: Message-ID: <45FE1F1A.3070809@kurtz-fernhout.com> kirby urner wrote (way back on 2/16/2007): > In the meantime, the Kay Group is thinking to reinvent > the wheel and implement the whole show in like just > 20K lines of code, intended for pedagogical purposes > (not just pie in the sky). > > http://irbseminars.intel-research.net/AlanKayNSF.pdf > > More power to 'em, though of course OLPC isn't waiting > for that project to finish (I doubt Kay would want it to -- > kids need Net access today -- tomorrow is not soon > enough). And besides, we already have Python. Thanks for posting that link. Finally got around to reading this entire proposal (i.e. finally got around to having my Debian system talk via CUPS to the networked HP printer in another building so I could print it -- and I should start by thanking Alan Kay and his original Xerox PARC group for making that sort of thing possible. :-). These are some comments on: "Steps Toward The Reinvention of Programming: A Compact And Practical Model of Personal Computing As A Self-Exploratorium" Alan Kay, Dan Ingalls, Yoshiki Ohshima, Ian Piumarta, Andreas Raab http://irbseminars.intel-research.net/AlanKayNSF.pdf Related slides by Ian Piumarta: http://piumarta.com/papers/EE380-2007-slides.pdf Related webcast by Ian Piumarta: http://lang.stanford.edu/courses/ee380/070214/070214-ee380-300.wmv Obviously, there is only so much you can fit into a proposal, so these comments don't mean Kay's group has not thought about the following. And also, any proposal has to pick and choose what it emphasizes. So I will bring up issues from what I think important, but that does not mean the project as an entity would even necessarily better off if it addressed all these points given its limited resources and attention. To begin, there is no exploration of Gordon Moore's law and its implications enabling this entire project. That is a surprise as it is the continued advances in processing power that allow avoiding optimization and so follow the path outlined to use general techniques and write simpler code (and perhaps then add an optimization layer later). It's not like previous generations of implementors were all dopes; they just often were working under different constraints. There is one mention on page 14: "Moore's Law gives us different scales to deal with every few years," but no discussion of how that has changed what is worth doing in what contexts (or how it is likely to change). Computers are about 100X faster for the same price than ten or so years ago, they will be about 100X-1000X faster for the same price in another ten or so years (hard to believe, but consider the 1MHz 8-bit C64 circa 1983 compared to a current 3GHz multi-core 64-bit desktop, probably 10000X-100000X faster and 10000X more memory, for about the same amount of money twenty years later). Moore's law can be considered generally in terms of exponential growth in technological capacity (or reducing costs). See: http://www.kurzweilai.net/articles/art0134.html?printable=1 This trend is driving the re-examination of many "old" ideas in computer science which are now suddenly feasible, especially in AI techniques (which this proposal hints at). Hans Moravec talks about that a lot, such as here: "When will computer hardware match the human brain?" http://www.transhumanist.com/volume1/moravec.htm Essentially, Moravec argues in the 1950s important researchers got 1-MIPS supercomputers (of that day), then in the 1960s more of them got 1-MIPS mainframes, then in the 1970s they all got bumped down to 1-MIPS minicomputers, then in the 1980s bumped further down to 1-MIPS desktop microcomputers. Only since 1990 have the desktop micros moved up the scale of performance. Moravec talks about AI researches, but I think this trend may apply in other areas too. It also dovetails with the general crunch in science funding as exponential growth of PhDs met limited dollars and steady enrollments around 1970: http://www.its.caltech.edu/~dg/crunch_art.html So in that sense, this proposal fails to introspect on how it is part of a general trend -- suddenly lots of things are possible with computers that weren't before due to performance constraints -- and one of the big possibilities is to discard optimization for elegance in a lot of areas. And maybe, paradoxically, through elegance, eventually discover even greater performance. But I think this is a key failure -- to plan to develop future computing tools while not wrestling with this fundamental exponential trend in a serious way. There is also no mention of the other Moore -- Charles Moore and Forth. Which is surprising, as a lot of the proposal is sort-of about reinventing Forth and following Forth ideals (simplicity; unification; extendability; threading; chained words; nested dictionaries, etc.). Chuck Moore accomplished entire multi-tasking multi-user real-time OS including its own compiler, linker, loader, and editor in about 32K bytes, running on slow 1-MIPS minicomputer processors of the 1970s. (That 32K was for a bells and whistles system -- the core of Forth is only 1K or 2K bytes). The 20,000 lines of code proposed here for a newer Smalltalk at generating 50 bytes a line would be about about 1000K (or 1MB, though likely less compiled) and probably will need a CPU 1000X more powerful than what Chuck worked with in the 1970s to work acceptably. So - there is still a lot of bloat, even as Kay writes of how difficult this will to accomplish. Granted, those early Forths were limited in the graphics they could display -- but there is no clear discussions here on why graphics by itself would add so much bloat. By the way, most modern Forths don't bootstrap (a big focus of this proposal), they "meta compile". http://www.ultratechnology.com/meta.html >From there: "Forth Meta Compilation ... The simplicity of the Forth language makes it easy to not only extend the language into a tongue that is perfectly suited to a particular problem but rewrite the language from the ground up as you see fit. It is a language the encourages experimentation with problems, thought, and the language itself. ... " Sounds a lot like this proposal, does it not? No reference to Forth anywhere in the proposal. QNX was an early microkernel message passing distributed OS for x86 hardware -- and predates MS-DOS. Oh if only IBM had used it instead... It had a 44k kernel back then in the early 1980s, and you could effortlessly use resources on any other computer in the network. From: http://en.wikipedia.org/wiki/QNX "QNX interprocess communication consists of sending a message from one process to another and waiting for a reply. This is a single operation, called MsgSend." So at least some solutions have long existed to the OS-level message passing issue (including in device driver design). It's more an issue of just getting people to use a common convention, and has been for decades. Kay's group could even just add such message passing support and interfaces as a convention to, say, the Linux kernel or even just Gnome with GTK graphics -- and get a lot more users a lot more quickly. But hacking GNOME and arguing on those lists would probably not be as fun for Kay's group as making a new system? :-) I'll agree it may likely be more productive than arguing, too, of course. :-) See: "Linus versus GNOME" http://www.desktoplinux.com/news/NS8745257437.html Note: The widget toolkit TCL/TK also has a widely used "send" command: http://wiki.tcl.tk/1055 People use it all the time for gluing such GUI systems together. Also, ultimately, even if this general approach succeeds, using all of the key ideas outlined, then you will get a lot of abstractions built on top of the common message passing system. The same way, for example, we get a lot of different web applications built on top of http or even just plain sockets, perhaps exchanging XML documents with various semantics. But, ultimately, these different abstraction may not be compatible, or may require interface layers, or complex code to deal with various XML interchange formats which disagree about the basic meaning of various terms (e.g. what a "purchase order" is). Kay's proposal ignores that problem -- and it is a really hard one relating to shared meaning. And the failure to address it is one reason Squeak has remained mired in bit rot and incompatible packages (which people are now struggling heroically to fix). "About Squeak" -- Andres Valloud (and some comments by me) http://blogten.blogspot.com/2004/12/about-squeak.html "Belling the cat of complexity" -- Paul Fernhout http://lists.squeakfoundation.org/pipermail/squeak-dev/2000-June/001371.html The proposal talks about version control and rolling back state and running programs backwards -- but provides no substance to go with the ideal. (I've been plugging away at the Pointrel data repository system based on modeling incremental relationships using triads for twenty five years or so, so I know a little of that area. :-) Obviously it's doable -- for example OCaml does it with checkpoints and recomputing from the checkpoint. Anyway, I'd have liked to see more than handwaving on that. I'll be curious how they pursue that. There is once again the common criticism leveled at Smalltalk of being too self-contained. Compare this proposal with one that suggested making tools that could be used like telescope or a microscope for relating to code packages in other languages -- to use them as best possible on their own terms (or perhaps virtualized internally). Consider how the proposal suggests scripting all the way down -- yet how are the scripting tools built in Squeak? Certainly not with the scripting language. And consider there are always barriers to any system -- where you hit the OS, or CPU microcode, or proprietary hardware specifications, or even unknowns in quantum physics, and so on. :-) So every system has limits. But by pretending this one will not, this project may miss out on the whole issue of interfacing to systems beyond those limits in a coherent way. For example -- OpenGL works, and represents an API that has matured over a quarter century, and is linked with lots of hardware and software implementations; why not build on it instead of "bitblt"?. Or consider how Jython can use Java Swing libraries and other such Java libraries easily. Consider this example of proposed failure: the proposal's decision to punt on printing -- no focus there in difficulties of interfacing with a diversity of OS services as a guest -- of relating to prior art. This is where Python often shines as a system (language plus libraries plus community) -- and Python is based on a different design philosophy or perhaps different design ethic. Python has also prioritized "modularity" from the beginning, which has made a lot of these issues more manageable; Kay's proposal talks a lot about internal integration, but the word "modularity" is not even in the document. In this sense, I think Kay's group are repeating mistakes of the past and also dodging another very difficult issue -- one that Python somehow has more-or-less gotten right in its own way. It's their right to do their own thing; just pointing out a limitation here. There is also a sense of wanting a system supporting multiple levels of programming ("scripting all the way down"; the word "level" comes up again and again). Yet there does not seem to be anything deep in the theory of the system about multiple levels (see also the earlier point on abstractions). There is handwaving about commonality of implementation and perhaps syntax of message passing -- but there is nothing about the deeper issue of moving between different semantic levels (an example of this sort of problem is when you try to relate an error message in the bowels of a system back to the correct part of the specification which relates to it -- this is a huge stumbling block for most beginners, and is the sort of thing that compiler writers spend much more time on than they might expect). I think the avoidance of this problem is another variant on the issue of interoperability. When a system becomes a set of levels, or nested abstractions, then interoperability with parts of yourself becomes an issue as well. :-) I don't have an answer to this problem, but it's an example of the sort of deep problem that the future of computing may revolve around, and which, as far as I see, is unaddressed here. LearningWorks, a Smalltalk environment for learning, explored some of these issues by modifying the debugger to omit some parts of stack traces, to focus the novice on problems in their own code. "The LearningWorks development and delivery frameworks" http://portal.acm.org/citation.cfm?doid=262793.262808 I'm not saying that modifying the debugger is a general solution to this problem; it's just one example of trying to address part of a large problem of "context". Moving from the abstract to the concrete, in general, look at big successes in widespread adoption of a practical new system -- such projects often pick a good platform of robust-enough technologies and meet an important need, for example, Skype. Today, the JVM (Java) and OpenGL today are fairly solid to build systems on. Is portability or bootstrapping still a interesting question? It might perhaps be more interesting to see what you could build on, say, the JVM (prototyped via Jython?) and OpenGL using all of the same good ideas in the proposal. Would these goals really lose very much if first implemented on that platform compared to C++ and who knows what windowing toolkits? Perhaps something I might think about exploring myself. :-) Yes, I know such suggestion goes against the expressed intent of creating a system that makes sense all the way down to the metal -- but that is part of my point, is there really as much benefit to that these days as one might think, compared to a system which supplies software telescopes and code microscopes to look at the network of processes around you, whatever language they are in? Why get an entire new community to waste their time porting this new framework everywhere when a lot of engineering has gone into this problem, already? Why not stand on the shoulders of giants, and make something that goes far, far beyond the JVM/Java/Jython/Swing/etc. and OpenGL as plain toolkits? What sort of software do people really need these days anyway? There is a mention at the end about needing solutions for high schools, but they already have Python and lots of good libraries for it. So, there is talk about reinventing curricula, but all the focus is on making the technology. Art would echo this point, I would think, if he were still around. While personally, I am all for better computer technology, and think it will help kids learn in various indirect ways, but it's a little sad you just can't often float a R&D proposal on those merits alone -- just on making better software development environments for *everyone*. Nonetheless, Kay's proposal is exactly the kind of exploratory research the NSF should be funding. These comments aren't meant to be criticisms of the projects worth. If anything, it just shows how worthy it is already, to spark new ideas and to be good enough to be worth time to comment on at length. IMHO the NSF should fund a dozen projects like this, or even hundreds. And if anyone can accomplish these goals, it will likely be Kay and his group. There are lots of great ideas in this proposal (many of the the best ones seem to be about moving Smalltalk internals in a more functional programming direction) The "Albert" approach seems both sound and innovative for O.O. bootstrapping (while being a little Forth like?) I wish the best of success with all of it. This project will at the very least produce a lot of good ideas for others to build on -- and make them available under free or open source licenses (even for Python to use). That's a good thing. And I may play with some of them myself (especially the potentially infinite late binding of dispatchers, which is a really cool idea). I also liked Kay's use of the term "singularity" to describe a point in the bootstrapping process where a system becomes self-defining and self-inspectable. That's always one issue that has held me back from building a Smalltalk on top of Forth -- realizing that at some point you really don't care much about the level below as your Forth interpreter loops becomes dominated by a Smalltalk message passing loop, and so why not code the base level in C/C++ to get more speed? The argument for having Forth available a decade ago is that you could code fast extensions without needing a big C compiler lying around. Today, especially on GNU/Linux systems, that is getting to be not much of an issue as it was ten years ago, since the C compiler is probably always there (at least on free systems), disk space to store the compiler is cheap, memory to run the compiler is cheap, and the community support for GCC is so large its complexity becomes manageable through other means than understanding it all yourself (which was easy to do with Forth, but not GCC.) Forth has a simplicity and understandability along the same lines Kay's proposal moves towards. Yet, I think some of the same forces that lead people to use GCC instead of Forth for most projects will lead this new project to become marginalized -- unless it addresses at least the interoperability issue outlined above.(*) The other points I raise such as managing differing abstractions are important, but the solutions for them will likely come out of the masses of people working in this area, and in that sense, may show the strength of this proposal's intended approach to get a lot of people involved in it. Still, we can see the deep differences between Python and Smalltalk (or its possible successor) in terms of emphasis in the community on the importance of interoperating with lots of existing systems. And I find this sad, because there is no inherent reason a system like the one Alan Kay and his colleagues propose could not excel at interoperability (such as Jython achieves for Java) -- it is more an issue of emphasis and perspective. So in that sense, I think Kay's project could greatly benefit from at least a little of the Python spirit, just as Python could benefit from a lot of the ideas Kay and Smalltalk have long had going for them (like "edit and continue" or message passing). --Paul Fernhout (*) Unlike Smalltalk, Forth also has trouble being self-documenting by not naming most temporary variables as it uses the stack, that is IMHO it's greatest weakness as a language; you can document that using comments, but it requires extra effort both to write and understand. From kirby.urner at gmail.com Mon Mar 19 16:25:36 2007 From: kirby.urner at gmail.com (kirby urner) Date: Mon, 19 Mar 2007 08:25:36 -0700 Subject: [Edu-sig] Comments on Kay's Reinvention of Programming proposal (was Re: More Pipeline News) In-Reply-To: <45FE1F1A.3070809@kurtz-fernhout.com> References: <45FE1F1A.3070809@kurtz-fernhout.com> Message-ID: On 3/18/07, Paul D. Fernhout wrote: > > Thanks for posting that link. Having given your lengthy analysis a single scan so far, I find we're sharing some similar concerns about architecture: so often in nature the rules are different enough from level to level that you wouldn't *want* the same coding language and/or development environment, let alone concepts, to permeate all levels. That's partly why we have such a diverse ecosystem to begin with. This effort to build from scratch to create a more uniform system from top to bottom may be an inherently inefficient design, from the point of view of division of labor and letting each layer follow it's own heart as it were. But that's not to quibble with wanting to go ahead with *the experiment* i.e. there's no point just arguing in a vacuum. So, more power to 'em is my attitude. On the other hand, we're *not* waiting for results to move ahead quickly on other fronts, with our already proven technologies. There's no sense that this new project needs to be a bottleneck from a CP4E standpoint. Kirby From pdfernhout at kurtz-fernhout.com Tue Mar 20 00:57:38 2007 From: pdfernhout at kurtz-fernhout.com (Paul D. Fernhout) Date: Mon, 19 Mar 2007 19:57:38 -0400 Subject: [Edu-sig] Comments on Kay's Reinvention of Programming proposal In-Reply-To: <7.0.1.0.2.20070319051917.07705c10@squeakland.org> References: <45FE1F1A.3070809@kurtz-fernhout.com> <7.0.1.0.2.20070319051917.07705c10@squeakland.org> Message-ID: <45FF2372.5070508@kurtz-fernhout.com> Alan- Thanks for the thoughtful reply, including the interesting historical information on earlier Smalltalk VM sizes and also on performances losses with newer hardware and OpenGL's origins. Thanks then too for OpenGL! :-) I wrote the following long essay, but feel free to ignore it as I'm sure you have lots of coding still to do, and I am eager to see the results. :-) Essentially though, I explore whether one can really claim to be reinventing programming while ignoring tackling head on the issues of managing complexity and supporting legacy code. ==== On managing complexity and supporting legacy code: I especially liked your point of: "we want to use "Math Wins!" as the motto of this project". Certainly Moore's law is making it more possible for plain general math to win big, without the clutter of a lot of hand-coded implicit and explicit optimizations (which can be added later as you propose). And certainly Moore's law is only working to benefit existing dynamic systems like Smalltalk and Python as any late-binding performance overhead is becoming less and less important for more and more tasks. Also on math, and on rereading your proposal, it is common, if not essential, for a mathematician to redefine the terms of a problem until it matches something they know how to solve. Sometimes the result is useful -- sometimes it is not. In the realm of science, it is generally always interesting and entertaining though. From: http://www.inf.uos.de/elmar/Fun/light2.html "Q: How many mathematicians does it take to screw in a light bulb? A: One. He gives it to six Californians, thereby reducing the problem to an earlier joke..." I'll agree that "... the proposal is clear as to its aims, and it is sketchy as to how the aims will be realized ...". That of course is the nature of much research. If it was claiming to be *very* basic research (which the USA has fallen down on), I'm sure it would be sketchy as to its aims too, :-) but then it would be unlikely to get funded these days. And that is why one famous academic I know said he built his basic research career on always submitting grant proposals for the work he was already doing and was near completing, and then using the grant money to do something new and unexpected, which after success became the basis of the next retrospective grant proposal. :-) But he also built his career back in the 1950s-1970s, when funding was more plentiful relative to PhDs. http://www.its.caltech.edu/~dg/crunch_art.html I'll also agree with your sentiment that: "The rest of your discussion is orthogonal to the aims of the proposal." But, as you also say: "Basically, we think we know how to do the bottom and the top, but the most interesting stuff in the center (how "programs" are expressed, etc.) is currently described in terms of analogies to good ideas rather than good ideas themselves." It's the "stuff in the middle" that several of my points are about. From my experience with other projects, including Squeak, I can agree wholeheartedly with with this fragment of the larger Dijkstra quote Ian Piumarta has in his talk slides of: "... we all know that unmastered complexity is at the root of the misery..." Of the techniques you outline, which are really directed at managing complexity? Perhaps some will help sometimes (like programming using particles and fields for page layout) but they may introduce their own complexities. And while ignoring the outside world of legacy code leads to a simple set of issues for the design, they also lead the community to have complexity issues of its own maintaining and writing code in all sorts of areas. Where is, say, the broad emphasis on wrestling code complexity to the ground? Or where is, say, a broad emphasis on being able to easily interface with, reverse engineer, and maintain any legacy system in any language on any hardware? Fanciful perhaps to think so big, but is that not what "reinventing programming" would be about? Especially one that added in the word "practical" in the subtitle? Or is the proposal more really about "reinventing all computers?". :-) which is a great goal, agreeing with your comment on performance loss by poor design by vendors of hardware or software, but still is quite a bit different. I know in practice one needs to draw lines somewhere, and one may have limited resources, so I am not faulting you on having to draw lines. In fact, it's remarkable you drew them as far out as you have! Nonetheless, I'm just playing with the boundaries here -- knowing they are unlikely to change, but doing so both to understand the nature of the problem space better and to understand more precisely what this projects contribution will be, given the provocative title. See: http://www.worldtrans.org/pos/infinitegames.html "There are at least two kinds of games: finite and infinite. A finite game is a game that has fixed rules and boundaries, that is played for the purpose of winning and thereby ending the game. An infinite game has no fixed rules or boundaries. In an infinite game you play with the boundaries and the purpose is to continue the game." So, for a proposal focusing on "Reinventing programming", I feel it perhaps just aims too low (at least in these two areas). Which of course is ironic since I am sure the biggest problem getting work like this funded is reviewers thinking you are aiming too high. :-) Granted, you do have "Steps toward" in the title, so perhaps I just hope for too much from you all at once. :-) What you really need then is more time and more money. :-) Also, these two issues of managing complexity in the middle and interfacing with a legacy code environment may be "orthogonal" to what your propose, but they are surely not orthogonal to "reinventing programming". And I would suggest to you that it is in those very two areas where Python and Jython with their modularity and libraries and specific community culture are succeeding, whereas the early Squeak effort pretty much failed in those areas. (Though since Squeak is a work in progress, it hasn't really failed -- it's just getting there slowly, and through a lot of new and painful hard work by the community.) Squeak has other successes in areas Python has failed (like having "edit and continue" to code in the debugger and by supporting true message passing) so this isn't meant to promote one over the other, but I would hope some new project could build on the strength of *both* systems and their communities. One might say that using an idea like message passing everywhere will simplify things and make management of complexity easier, but as Manuel de Landa suggests, if this new project does succeed at creating a homogeneous message passing layer among all software (like if the Linux Kernel adopts your approach some day :-), complexity at another level may grow even faster and become even more unmanageable, or in his words: http://www.t0.or.at/delanda/meshwork.htm "To make things worse, the solution to this is not simply to begin adding meshwork components to the mix. Indeed, one must resist the temptation to make hierarchies into villains and meshworks into heroes, not only because, as I said, they are constantly turning into one another, but because in real life we find only mixtures and hybrids, and the properties of these cannot be established through theory alone but demand concrete experimentation. Certain standardizations, say, of electric outlet designs or of data-structures traveling through the Internet, may actually turn out to promote heterogenization at another level, in terms of the appliances that may be designed around the standard outlet, or of the services that a common data-structure may make possible. On the other hand, the mere presence of increased heterogeneity is no guarantee that a better state for society has been achieved. After all, the territory occupied by former Yugoslavia is more heterogeneous now than it was ten years ago, but the lack of uniformity at one level simply hides an increase of homogeneity at the level of the warring ethnic communities. But even if we managed to promote not only heterogeneity, but diversity articulated into a meshwork, that still would not be a perfect solution. After all, meshworks grow by drift and they may drift to places where we do not want to go. The goal-directedness of hierarchies is the kind of property that we may desire to keep at least for certain institutions. Hence, demonizing centralization and glorifying decentralization as the solution to all our problems would be wrong. An open and experimental attitude towards the question of different hybrids and mixtures is what the complexity of reality itself seems to call for. To paraphrase Deleuze and Guattari, never believe that a meshwork will suffice to save us. " And I think for whatever its obvious weaknesses relative to Smalltalk (like no widespread "edit and continue" :-) the Python community has excelled at following the path Manuel de Landa references of maintaining an "... open and experimental attitude towards the question of different hybrids and mixtures...". And I think that some good progress can be made by trying to understand why Python is (relatively) much more successful in those areas in practice -- as opposed to Squeak which should be better in theory since the design principals in Squeak/Smalltalk should define IMHO the better overall architecture (sorry Guido). On a regular basis, I find myself having to choose between Squeak and Python, and I invariably choose Python for practical reasons while still preferring Squeak for conceptual ones (even knowing the code I write myself would be written much more quickly in Squeak by a factor of 2X-3X, if for no other reason than keyword syntax and coding in the debugger). And I am sad about that, since with the exception of significant indentation, I much prefer Smalltalk syntax and concepts. So on a practical basis, I am left trying to make Python better, even as I know, as your proposal says, that message passing is going to be (in theory) superior for scaling and interoperability than tight gear meshing from function calls. Granted, the design you lay out makes such different mixtures of types of objects and related paradigms quite possible by having a very flexible implementation system for message passing. As you say, it is not "Smalltalk" -- but nonetheless I can hope it will build on Smalltalk's successes -- like continuing to use message passing. I believe the deep issues will come in trying to manage all that flexibility. But I just do not see that as an emphasis in the project. In that sense, I see this project more likely to create new (though desirable) problems than to solve the difficult ones "professional programmers" already have when they work on a project of any significant scope. One of the beauties of Smalltalk-80 was that it only gave you the flexibility you really needed (e.g. no arbitrary C-style macros, no arbitrary processing of messages like earlier Smalltalk-72 was it?). There was not too much clutter at the language level (ignoring pool dictionaries and the like) -- and the clutter at the library level was in theory removable or changeable. In that way, this new proposal may trend toward violating that elegant principle which has allowed modern Smalltalkers to keep on top of huge projects. For example, I once spent a week (while all the in-house developers went away for training :-) changing tens of thousands of methods written according to dopey C++ get/set naming conventions in a huge project (e.g. instead of x and x: the guidelines promoted by a previous consulting group had people put getX and setX: everywhere -- what a mess for Smalltalk!). That conversion was done mostly using mostly using automated tools I wrote of course, and it was a conversion which was only made feasible by Smalltalk-80s elegance and introspection capabilities. I'm leary of approaches toward reinventing programming which might lose that elegance of Smalltalk-80. Colin Putney discusses a related issue here: http://www.wiresong.ca/air/articles/2006/08/24/scripting-languages-and-ides He says: "So, it would appear that we can have either a powerful language, or powerful tools, but not both at the same time. And looking around, it?s notable that there are no good IDEs for scripting languages, but none of the languages that have good IDEs lend themselve to metaprogramming. There is, of course, one exception. Smalltalk. With Smalltalk, we have the best of both worlds." Python is actually an example of a language with various flexible dispatching methods built-in in some ways, but it becomes a hard thing to maintain and a system that is becoming ever harder to full understand as an end user programmer. Too much flexibility at one level goes even farther down the C++ path -- where C++ is designed to let you do anything efficiently,y in theory -- but in practice ends up making it hard to really understand what any piece of code might be doing that it is rare the programmer can focus enough on a task to do it well. After I originally read the proposal a month or so ago, I thought on this issue of arbitrary message dispatchers, but ultimately came up with the thought that for 99% of the time programming as I do now, I would not need it and would just have everyones use the same standard dispatcher. Granted, it may lead to great innovations, which is the point, and I do hope it does, and may someday lead to people saying, like they did for structured programming over spaghetti GOTOs, "how did I get along without it?" But until then, it adds even more complexity, moving the system actually in a negative direction as far as the core problem from the Dijkstra quote of managing complexity, and which I see as perhaps *the* most important real yet difficult problem of programming day-in and day-out in the trenches. (Theres lots of other problems in programming, but they are generally all more tractable.. :-) (I write that last paragraph as someone who spent months trying to make Python more like Self, but ultimately designed prototypes were in practice, not all they promised to be, and that plain Python with classes had many advantages. See my writing on this here: "PataPata critique: the good, the bad, the ugly" http://patapata.sourceforge.net/critique.html Anyway, that's just to show you I too am looking for solutions. ) If this new project to reinvent programming hits limits, I think it likely these issues (complexity management and legacy interfacing) will be the sorts of issues it finds itself wrestling with once the easy stuff is done (like when you want to really make it easy for a user to print a physical page from all platforms the software could run on). And I don't have any easy answers for these issues; perhaps no one does -- yet (or if ever). But I think it is in the direction of exploring that complexity management issue head on that we will see a complete reinvention of programming. And yes, obviously, functional programming and aspect-oriented programming and so on may all be parts of that puzzle, and to the extent the proposals architecture can easily encompass all those, it helps with the big picture of managing complexity. I guess ultimately the goals of making an easy to use GUI (all the way down) for novices can conflict with the goals of making a system that allows an experienced user to deal with a vast and complex set of problems. By "conflict" I don't mean technically; I mean more like in terms of choosing where to spend limited attention. Which highlights the difficulty sometimes of following your principle of "Easy things should be easy; difficult things should be possible." And while not exactly the same issues, it gets back to the link I previously had on a "Linus versus Gnome" conflict/exchange: http://www.desktoplinux.com/news/NS8745257437.html >From there: "As the thread continued, it became clear that the underlying problem is that Torvalds and the GNOME project have contradictory design goals. Torvalds wants to increase users' access to the system to give them the maximum possible power, while GNOME aims to increase the system's usability by making it as easy to use as possible. For GNOME, this means limiting access to the system from the GUI." So, part of this issues comes down to audience. Revinventing programming for whom? For the novice or the high schooler? For the savvy researcher? Or for the professional programmer? Or for everyone? What does "personal" mean? These are more rhetorical questions, of course. Even if you have a specific user in mind, you have every right to make the system to meet whatever user group you are interested in supporting as well as to keep that vague; I'm just lobbying for supporting the personal users who have large complex systems to deal with. :-) As Kirby Urner said so insightfully in his own reply: "So often in nature the rules are different enough from level to level that you wouldn't *want* the same coding language and/or development environment, let alone concepts, to permeate all levels." I think that is a very important point this project will no doubt need to deal with over time -- how "levels" are approached. And perhaps the same thing is also true for different users, or perhaps different roles for different users, or different levels of experience, each dealing with different needs resulting from qualitative differences emerging from qualitative differences (like the number of objects they must manipulate, the number of things they already know, their motivation to overcome frustrations, and so on.). Still, I also agree wholeheartedly with Kirby when he adds: "... But that's not to quibble with wanting to go ahead with *the experiment* ..." When someone does an experiment with pure reagents, you learn a lot about general principles. And often, the purer the reagents, the more certain you are of the general principles learned. In any case, I think it will be a very interesting experiment indeed, and well worth doing, even if it perhaps leaves out some things on my own personal wish list. I signed up for the Fundamentals of New Computing (fonc) list http://vpri.org/mailman/listinfo/fonc and I'll be curious to see how it progresses. There are a lot of neat ideas you are working with. I appreciate the invitation in Ian's slides of: "go home and innovate! * built your own and share it with the world * or use ours: releases every month or two". :-) The project is surely succeeding already in getting people (myself included) to think in new ways about reinventing computing. Thanks also for that. So it is a success already! :-) All the best. --Paul Fernhout Alan Kay wrote: > Hi Paul -- > > Just to clarify a little. The proposal is quite terse via the 15 page > limit of NSF plus some of their side conditions. It was drawn from a > much longer "90% finished" internal white paper that I had written to > try to think things through with the help of some friends. This made its > way to NSF and last summer they requested that I write a proposal (and > to my great surprise funded the project late last year). > > Reading it again might help clarity (perhaps after the remarks below). > > This project is a deep exploration to try to learn enough ("Steps toward > ...") about a number of systems building techniques that have been > around for a while but have not been put at the center of an entire > system, so that successful results will furnish much stronger hints > about how programming could be actually reinvented. > > This project is neither an operating systems project nor a new > programming language per se, but is primarily architectural. (It has to > do what OSs do and what programming languages do, but it doesn't have to > do them like existing systems -- for example, there will not be an > actual "operating system" in any standard sense). > > The proposal says quite clearly that it is to create the "personal > computing experience" (PCE) from the end-user down to the metal, and it > spends the first few pages trying to gist what this means. If you read > it again, e.g. it doesn't eliminate printing, nor is it primarily about > OS machinery (but it does require many things to be done including > TCP/IP, printing, etc.). The PCE as defined in the proposal is a lot of > stuff that includes UI, many kinds of media, etc. ways to use the > Internet, and this will be a good and tough target for 20,000 lines of > code from the end-user down to the metal. > > Naturally we have thought about Moore's Law: it was thinking about this > that gave rise to the HW and SW personal computing systems we did at > PARC in the 70s. However, looking at Moore's Law today, we see that it > has not helped code bloat (and, in fact, has provided "life support" for > a lot of systems that probably should have been allowed to die). The > main place we plan to use Moore's Law is an analogy to what we did at > PARC, namely, to make special machinery that allowed us to (a) do many > experiments without needing optimization, and (b) to anticipate 10 or > more years into the future with optimizations. Then we used special > microcoded computers, today FPGAs are somewhat an equivalent secret weapon. > > An important thing to realize about Moore's Law is that the law as > stated doesn't really obtain at the systems level. For example, Butler > Lampson has estimated that today's hardware is about a factor of 1000 > less efficient than the home-brew systems we made at PARC (I've done > some benchmarks for Smalltalk-80) that indicate at least a factor of 600 > has been lost over the Dorado. This is either 9 or 10 doublings, and > this is 13-15 years lost because of poor design by vendors (this is > significant). > > In any case, to say it again, we don't want to use Moore's Law to > escape, we want to use "Math Wins!" as the motto of this project. We > want a better approach to architecture at all levels of the system. (I > helped do some of the original math at Utah that wound its way into > OpenGL, and the "math of OpenGL" is a good contrast to "the code of > OpenGL".) > > I've always like FORTH as far as it went (but it never went far enough) > and so its architecture doesn't overlap with this project. Also, this > project has nothing to do with Smalltalk or its various architectural > choices (similar comment as per FORTH). There is no commitment to > standard notions of objects, classes, messages, etc. in this project. > (The scaffolding needed to build an arch does not remain after the > keystone is placed.) > > It's not primarily an engineering project so just how some of the > criteria are fulfilled are left open to the results of research over the > next few years, but I wouldn't be completely surprised if the primary > semantics of this system were not message-oriented. Basically, we think > we know how to do the bottom and the top, but the most interesting stuff > in the center (how "programs" are expressed, etc.) is currently > described in terms of analogies to good ideas rather than good ideas > themselves. > > All I will say about your discussion of tiny kernels, etc., is that the > entire original Smalltalk ran in 32K on the Alto, and the kernel for > ST-78 (for the Notetaker) was only 6KB). But these references, including > mine, have little to do with the aims of this project (again a > suggestion for rereading the proposal). This project has nothing much to > do with past systems, but seeks to try alternative architectural ideas > (some of which have been around for a while, and most of them not > thought up by us). > > The rest of your discussion is orthogonal to the aims of the proposal. I > think we might have the case here, as the Talmud says, "We see things > not as they are, but as we are". I think the proposal is clear as to its > aims, and it is sketchy as to how the aims will be realized (this is > partly the result of unclear writing by me, partly the demands of space, > and partly that it is a real old-time research project that requires > quite a bit of invention to succeed). One of the reviewers of the > proposal took us to task for saying that we didn't know how to do > everything! From kirby.urner at gmail.com Wed Mar 21 16:56:01 2007 From: kirby.urner at gmail.com (kirby urner) Date: Wed, 21 Mar 2007 08:56:01 -0700 Subject: [Edu-sig] Calculators = Bottleneck Message-ID: I just posted another essay to the Math Forum on why I consider calculators and the faux controversies around them, to be a serious bottleneck: http://mathforum.org/kb/message.jspa?messageID=5589504&tstart=0 I've taken this line at OSCONs, encouraging collaboration across language communities to help address deficiencies in the current numeracy curricula, including in K-12 (pre-college). Uniting against calculators, in favor of computer languages, helps keep us from religious wars about "which language". An older overview essay, a longer one, is linked from Jim Roepcke's site here: http://jim.roepcke.com/6828 (note that I didn't manage to deliver the presentation that went with that paper at Pycon 2004 in DC, as my late wife had just been diagnosed with cancer, so I flew back to Portland, missing Pycon (she and I came to DC together for Pycon 2005, where I talked more informally about hypertoons)). Kirby From wescpy at gmail.com Thu Mar 22 19:37:30 2007 From: wescpy at gmail.com (wesley chun) Date: Thu, 22 Mar 2007 11:37:30 -0700 Subject: [Edu-sig] [ANN] Python courses this Spring In-Reply-To: <78b3a9580703221136s5d52a382kb257473647c307e2@mail.gmail.com> References: <78b3a9580703221134s14d026ebgd59d1af30fb4f5c5@mail.gmail.com> <78b3a9580703221136v15c9b4a9q892a228a32486053@mail.gmail.com> <78b3a9580703221136s5d52a382kb257473647c307e2@mail.gmail.com> Message-ID: <78b3a9580703221137g72be4f9gfefc15611439f3ca@mail.gmail.com> I'll be giving a variety of Python courses this Spring. Daytime courses are for visitors and locals who need Python training in the shortest amount of time possible via consecutive workdays. Python is certainly gaining momentum as our February course filled up completely! Although I had planned on scheduling the same set to be taught in November, it is likely that these May daytime sessions are the last ones of 2007. In contrast, I'm experimenting with a *weekly evening* course in Silicon Valley designed mainly for locals. It represents a viable alternative to those who cannot take time off during the week as well as being more budget-friendly, as I am partnering with a local community college (Foothill) to offer this course. Class takes place on the main campus and you must register through the college to attend. For more information, such as cost and other course details, see the corresponding websites below. Contact me privately if you have any more questions. cheers, -wesley - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - "Core Python Programming", Prentice Hall, (c)2007,2001 http://corepython.com wesley.j.chun :: wescpy-at-gmail.com python training and technical consulting cyberweb.consulting : silicon valley, ca http://cyberwebconsulting.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - DAYTIME ======= - (Intensive) Introduction to Python (Mon-Wed, May 14-16) - Advanced Python Programming (Wed-Fri, May 16-18) - Advanced Python (short course; Thu-Fri, May 17-18) - Core Python (Intro+Advanced combo; Mon-Fri, May 14-18) These courses run daily 9a-5p and will take place in San Bruno right near the San Francisco International Airport at the: Staybridge Suites - San Francisco Airport 1350 Huntington Ave San Bruno, CA 94066 USA http://www.ichotelsgroup.com/h/d/sb/1/en/hd/sfobr Discounts are available for students and teachers, as well as multiple registrations from those working at the same company. For more info and registration, go to http://cyberwebconsulting.com (click on "Python Training") LOCALS: free parking and 101/280/380 access, BART across the street and CalTrain down the road (San Bruno stations) VISITORS: free hotel shuttle to/from the San Francisco airport, lots of free food and wireless, 2-bedroom suites w/private baths and a common work/living area available for traveling coworkers, and of course, The City by the Bay - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - EVENING ======= - Intermediate Python Programming (Tues, Apr 10-Jun 26) This course will cover the same topics as the advanced course above as well as critical portions of the intensive introductory course. It will be held once a week on Tuesday evenings from 6-9:40p. Foothill College 12345 El Monte Road Los Altos Hills, CA 94022 USA (right off 280, just south of Stanford) http://www.foothill.edu/schedule/schedule.php search for CIS 68L for Spring Quarter 2007 From mtobis at gmail.com Thu Mar 22 22:58:13 2007 From: mtobis at gmail.com (Michael Tobis) Date: Thu, 22 Mar 2007 16:58:13 -0500 Subject: [Edu-sig] Researching Article: Survey of Python for Kids Message-ID: I will be writing an article in the next Python Papers ( http://pythonpapers.cgpublisher.com/ ) ; a survey of Python in pre-college education, and an introduction to the issues raised by the still highly unresolved interface between software and education. The article will be broad rather than deep, but hopefully will provide enough extra push to preserve the momentum of discussion in the Python community about deeper issues that got such an enormous boost at the last PyCon. I'm a fairly quick writer so I will put off the writing until the last week. I have about two weeks to collect information. In addition to the stuff mentioned on http://www.python.org/community/sigs/current/edu-sig/ I intend to also touch on Crunchy Frog Alice Patapata Jython and web-based environments the PyCon 2007 keynotes by Goldberg, Lefkowitz and Krstic Please contact me directly or reply to this message if you know of any other projects or ideas that are deserving of mention in this article. I'd like to complete my research for this survey article by April 2. I am also interested in hearing from you if - you have taught classes in Python as a first programming language, especially for pre-college age audiences - you have released software that is targeted at beginning programmers which either exposes Python or uses Python under the hood - you are developing such software - you have or can point me to any historical background, especially about CP4E This may also serve as an occasion to update the edu-sig page! Michael Tobis -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20070322/83b07684/attachment.html From kirby.urner at gmail.com Fri Mar 23 04:39:44 2007 From: kirby.urner at gmail.com (kirby urner) Date: Thu, 22 Mar 2007 20:39:44 -0700 Subject: [Edu-sig] Researching Article: Survey of Python for Kids In-Reply-To: References: Message-ID: > Please contact me directly or reply to this message if you know of any other > projects or ideas that are deserving of mention in this article. I'd like to > complete my research for this survey article by April 2. > Hi Michael -- I teach Python pre-college via Saturday Academy in Portland, Oregon per page 31 of the current catalog. Also taught 8th graders Python in one of our flagship public schools (Winterhaven PPS). My CP4E resources are at http://www.4dsolutions.net/ocn/cp4e.html I was the original designer and maintainer of the current edu-sig home page (pre "new look" with the cool new Python Nation logo 'n all). Kirby From mtobis at gmail.com Mon Mar 26 23:54:27 2007 From: mtobis at gmail.com (Michael Tobis) Date: Mon, 26 Mar 2007 16:54:27 -0500 Subject: [Edu-sig] Python in Education Advocacy Article Message-ID: Dear Python-in-Education types For Python to gain the ground it ought to in educational settings will not happen automatically. To do my part, I have decided that my first article in the Python Papers should be about comparing Python to other common first languages for learning and teaching. I'd appreciate your help. Does language even matter pedagogically? If so what are Python's advantages and disadvantages? Should there be a universal first language of computing? Should it look more or less or exactly like Python? To further discussion on this question I have set up a blog. (I hate that blogs are in reverse chronological order; I posted the articles in the opposite order than the reading order so you can read from top to bottom!) In an effort to focus the conversation, I've asked a few language comparison questions that are relevant to Python's suitability as an educational language, each in its own blog entry. Please have a look, and make a stab at short answers to the questions. (If you have a long answer, please just link to it.) My idea is not to restrict people's ideas but to make an effort to provide some structure for the conversation. It will be very interesting to see if this helps move the conversation forward. The best outcome would be if we discover "low-hanging fruit" to advance the cause. Please lend a hand. see http://pencilscience.blogspot.com/ with pythonical regards, Michael Tobis -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20070326/8519d5c2/attachment.html From tjd at sfu.ca Tue Mar 27 00:51:13 2007 From: tjd at sfu.ca (Toby Donaldson) Date: Mon, 26 Mar 2007 15:51:13 -0700 Subject: [Edu-sig] [edupython] Python in Education Advocacy Article In-Reply-To: References: Message-ID: Michael, On the sigcse list there was recently a coding challenge (http://www.cs.duke.edu/csed/code) that asked for solutions to a word frequency problem in various languages. I believe the author is planning to eventually list all the solutions received (entries came in many different languages); that could make for some interesting comparisons. I wrote one solution in Python, and one in Java, which I give below; needless to say, I found the Python version far easier to write. Toby ------------------------------------------------------------------------------------------------------------------------------- import sys if __name__ == '__main__': # get the path from the command-line fname = sys.argv[1] # read in the file as a list of tokens tokens = [tok.strip().lower() for tok in open(fname, 'r').read().split()] # calculate the frequency of each token freq = {} for tok in tokens: if tok in freq: freq[tok] += 1 else: freq[tok] = 1 # Sort the list in highest frequency to lowest frequency, # with ties sorted by lexicographics order of the words. # Uses the Python sort-decorate-unsort idiom. We sort by # the negation of the frequency values to get the proper # ordering. lst = [(-freq[tok], tok) for tok in freq] # decorate lst.sort() # sort lst = [(-freq, tok) for freq, tok in lst] # undecorate # print the results for freq, tok in lst: print '%s\t%s' % (freq, tok) ------------------------------------------------------------------------------------------------------------------------------- import java.io.File; import java.io.IOException; import java.util.ArrayList; import java.util.Collections; import java.util.Scanner; import java.util.TreeMap; import java.util.TreeSet; public class Puzzle { public static void main(String[] args) throws IOException { // get the file to process String fname = args[0]; Scanner sc = new Scanner(new File(fname)); // initialize the map for the words and counts; // a TreeMap is always ordered by keys TreeMap map = new TreeMap(); // process the file a line at a time while (sc.hasNextLine()) { // chop each line into its constituent tokens // "\\s+" is a regular expression that matches one or more // whitespace characters String[] tokens = sc.nextLine().split("\\s+"); // make all the strings lower case, and remove any excess whitespace for (int i = 0; i < tokens.length; ++i) { tokens[i] = tokens[i].toLowerCase().trim(); } // add each token to the map for (String tok : tokens) { if (map.containsKey(tok)) { map.put(tok, map.get(tok) + 1); } else { map.put(tok, 1); } } } // remove the empty string if it is present map.remove(""); // sort the data by storing each word that occurs the same number of // times in a TreeMap of sets keyed by count; TreeSet stores its // values in sorted order TreeMap> sortMap = new TreeMap>(); for (String tok : map.keySet()) { int count = map.get(tok); if (sortMap.containsKey(count)) { TreeSet arr = sortMap.get(count); arr.add(tok); sortMap.put(count, arr); } else { TreeSet arr = new TreeSet(); arr.add(tok); sortMap.put(count, arr); } } // print the data // first reverse the keys to print data in the proper order ArrayList idx = new ArrayList(); idx.addAll(sortMap.keySet()); Collections.reverse(idx); // print it to stdout for (Integer key : idx) { TreeSet toks = sortMap.get(key); for (String t : toks) { System.out.printf("%s\t%s\n", key, t); } } } } From mtobis at gmail.com Tue Mar 27 04:52:31 2007 From: mtobis at gmail.com (Michael Tobis) Date: Mon, 26 Mar 2007 21:52:31 -0500 Subject: [Edu-sig] [edupython] Python in Education Advocacy Article In-Reply-To: References: Message-ID: Seven lines seems reasonable to me: ########## import sys concord = {} for word in [token.lower() for token in open(sys.argv [1],"r").read().split()]: concord[word] = concord.get(word,0) + 1 result = sorted([(item[1],item[0]) for item in concord.items ()],reverse=True) for pair in result: print "%s\t%s" % pair ########### While I wonder if the problem wasn't set up to be in Python's favor, this sort of thing is a big plus for Python in daily use. Terseness, though, is not enough in general and certainly not in education. Perl makes a virtue of terseness, and I have a strong sense it is not very useful as a first language. mt On 3/26/07, Toby Donaldson wrote: > > Michael, > > On the sigcse list there was recently a coding challenge > (http://www.cs.duke.edu/csed/code) that asked for solutions to a word > frequency problem in various languages. I believe the author is > planning to eventually list all the solutions received (entries came > in many different languages); that could make for some interesting > comparisons. > > I wrote one solution in Python, and one in Java, which I give below; > needless to say, I found the Python version far easier to write. > > Toby > > > ------------------------------------------------------------------------------------------------------------------------------- > import sys > > if __name__ == '__main__': > # get the path from the command-line > fname = sys.argv[1] > > # read in the file as a list of tokens > tokens = [tok.strip().lower() for tok in open(fname, > 'r').read().split()] > > # calculate the frequency of each token > freq = {} > for tok in tokens: > if tok in freq: > freq[tok] += 1 > else: > freq[tok] = 1 > > # Sort the list in highest frequency to lowest frequency, > # with ties sorted by lexicographics order of the words. > # Uses the Python sort-decorate-unsort idiom. We sort by > # the negation of the frequency values to get the proper > # ordering. > > lst = [(-freq[tok], tok) for tok in freq] # decorate > lst.sort() # sort > lst = [(-freq, tok) for freq, tok in lst] # undecorate > > # print the results > for freq, tok in lst: > print '%s\t%s' % (freq, tok) > > > ------------------------------------------------------------------------------------------------------------------------------- > > import java.io.File; > import java.io.IOException; > import java.util.ArrayList; > import java.util.Collections; > import java.util.Scanner; > import java.util.TreeMap; > import java.util.TreeSet; > > public class Puzzle { > > public static void main(String[] args) throws IOException { > // get the file to process > String fname = args[0]; > > Scanner sc = new Scanner(new File(fname)); > > // initialize the map for the words and counts; > // a TreeMap is always ordered by keys > TreeMap map = new TreeMap Integer>(); > > // process the file a line at a time > while (sc.hasNextLine()) { > // chop each line into its constituent tokens > // "\\s+" is a regular expression that matches > one or more > // whitespace characters > String[] tokens = sc.nextLine().split("\\s+"); > > // make all the strings lower case, and remove > any excess whitespace > for (int i = 0; i < tokens.length; ++i) { > tokens[i] = tokens[i].toLowerCase().trim(); > } > > // add each token to the map > for (String tok : tokens) { > if (map.containsKey(tok)) { > map.put(tok, map.get(tok) + 1); > } else { > map.put(tok, 1); > } > } > } > > // remove the empty string if it is present > map.remove(""); > > // sort the data by storing each word that occurs the > same number of > // times in a TreeMap of sets keyed by count; TreeSet > stores its > // values in sorted order > TreeMap> sortMap = new > TreeMap TreeSet>(); > for (String tok : map.keySet()) { > int count = map.get(tok); > if (sortMap.containsKey(count)) { > TreeSet arr = sortMap.get(count); > arr.add(tok); > sortMap.put(count, arr); > } else { > TreeSet arr = new > TreeSet(); > arr.add(tok); > sortMap.put(count, arr); > } > } > > // print the data > > // first reverse the keys to print data in the proper order > ArrayList idx = new ArrayList(); > idx.addAll(sortMap.keySet()); > Collections.reverse(idx); > > // print it to stdout > for (Integer key : idx) { > TreeSet toks = sortMap.get(key); > for (String t : toks) { > System.out.printf("%s\t%s\n", key, t); > } > } > } > } > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20070326/88aa5dd2/attachment.htm From tjd at sfu.ca Tue Mar 27 06:39:34 2007 From: tjd at sfu.ca (Toby Donaldson) Date: Mon, 26 Mar 2007 21:39:34 -0700 Subject: [Edu-sig] [edupython] Python in Education Advocacy Article In-Reply-To: References: Message-ID: Actually, it appears your code makes a common error: according to the problem specification, when frequencies are tied, they should be ordered alphabetically. But your code orders tied frequencies in reverse, e.g. 7 which # oops: wrong order 7 this 7 there 7 one 7 me 7 by 7 about 7 ``the Toby On 3/26/07, Michael Tobis wrote: > > > Seven lines seems reasonable to me: > > ########## > import sys > > concord = {} > for word in [token.lower() for token in > open(sys.argv[1],"r").read().split()]: > concord[word] = concord.get(word,0) + 1 > result = sorted([(item[1],item[0]) for item in > concord.items()],reverse=True) > for pair in result: > print "%s\t%s" % pair > ########### > > While I wonder if the problem wasn't set up to be in Python's favor, this > sort of thing is a big plus for Python in daily use. > > Terseness, though, is not enough in general and certainly not in education. > Perl makes a virtue of terseness, and I have a strong sense it is not very > useful as a first language. > > mt > > > On 3/26/07, Toby Donaldson wrote: > > > > Michael, > > > > On the sigcse list there was recently a coding challenge > > (http://www.cs.duke.edu/csed/code) that asked for > solutions to a word > > frequency problem in various languages. I believe the author is > > planning to eventually list all the solutions received (entries came > > in many different languages); that could make for some interesting > > comparisons. > > > > I wrote one solution in Python, and one in Java, which I give below; > > needless to say, I found the Python version far easier to write. > > > > Toby > > > > > ------------------------------------------------------------------------------------------------------------------------------- > > import sys > > > > if __name__ == '__main__': > > # get the path from the command-line > > fname = sys.argv[1] > > > > # read in the file as a list of tokens > > tokens = [tok.strip().lower() for tok in open(fname, > 'r').read().split()] > > > > # calculate the frequency of each token > > freq = {} > > for tok in tokens: > > if tok in freq: > > freq[tok] += 1 > > else: > > freq[tok] = 1 > > > > # Sort the list in highest frequency to lowest frequency, > > # with ties sorted by lexicographics order of the words. > > # Uses the Python sort-decorate-unsort idiom. We sort by > > # the negation of the frequency values to get the proper > > # ordering. > > > > lst = [(-freq[tok], tok) for tok in freq] # decorate > > lst.sort() # sort > > lst = [(-freq, tok) for freq, tok in lst] # undecorate > > > > # print the results > > for freq, tok in lst: > > print '%s\t%s' % (freq, tok) > > > > > ------------------------------------------------------------------------------------------------------------------------------- > > > > import java.io.File; > > import java.io.IOException; > > import java.util.ArrayList ; > > import java.util.Collections; > > import java.util.Scanner; > > import java.util.TreeMap; > > import java.util.TreeSet; > > > > public class Puzzle { > > > > public static void main(String[] args) throws IOException { > > // get the file to process > > String fname = args[0]; > > > > Scanner sc = new Scanner(new File(fname)); > > > > // initialize the map for the words and counts; > > // a TreeMap is always ordered by keys > > TreeMap map = new TreeMap Integer>(); > > > > // process the file a line at a time > > while ( sc.hasNextLine()) { > > // chop each line into its constituent tokens > > // "\\s+" is a regular expression that matches > > one or more > > // whitespace characters > > String[] tokens = sc.nextLine().split("\\s+"); > > > > // make all the strings lower case, and remove > > any excess whitespace > > for (int i = 0; i < tokens.length; ++i) { > > tokens[i] = tokens[i].toLowerCase().trim(); > > } > > > > // add each token to the map > > for (String tok : tokens) { > > if (map.containsKey(tok)) { > > map.put(tok, > map.get(tok) + 1); > > } else { > > map.put(tok, 1); > > } > > } > > } > > > > // remove the empty string if it is present > > map.remove(""); > > > > // sort the data by storing each word that occurs the > > same number of > > // times in a TreeMap of sets keyed by count; TreeSet > stores its > > // values in sorted order > > TreeMap> sortMap = new > TreeMap > TreeSet>(); > > for (String tok : map.keySet()) { > > int count = map.get(tok); > > if (sortMap.containsKey(count)) { > > TreeSet arr = sortMap.get(count); > > arr.add(tok); > > sortMap.put(count, arr); > > } else { > > TreeSet arr = new > TreeSet(); > > arr.add(tok); > > sortMap.put(count, arr); > > } > > } > > > > // print the data > > > > // first reverse the keys to print data in the proper order > > ArrayList idx = new ArrayList(); > > idx.addAll(sortMap.keySet()); > > Collections.reverse(idx); > > > > // print it to stdout > > for (Integer key : idx) { > > TreeSet toks = sortMap.get(key); > > for (String t : toks) { > > System.out.printf("%s\t%s\n", key, t); > > } > > } > > } > > } > > _______________________________________________ > > Edu-sig mailing list > > Edu-sig at python.org > > http://mail.python.org/mailman/listinfo/edu-sig > > > > -- Dr. Toby Donaldson School of Computing Science Simon Fraser University (Surrey) From kirby.urner at gmail.com Tue Mar 27 21:42:59 2007 From: kirby.urner at gmail.com (kirby urner) Date: Tue, 27 Mar 2007 12:42:59 -0700 Subject: [Edu-sig] Python in Education Advocacy Article In-Reply-To: References: Message-ID: > To further discussion on this question I have set up a blog. (I hate that > blogs are in reverse chronological order; I posted the articles in the > opposite order than the reading order so you can read from top to bottom!) > I'd rather post thoughts to edu-sig if you don't mind, as your questions are germane and in line with questions we've been asking ourselves on this list. Feel free to add a link from your blog (the edu-sig archive is public and open) as I might from mine (I link to edu-sig fairly routinely). >From my point of view, as someone who teaches Python both pre- and post- college, thinking in terms of objects is somewhat intuitive (why OO is appealing in the first place) and is anchoring paradigm I strive to impart, with Python the modeling language. Within OO, students have many choices of other language *and* have a handle on what a "programming language paradigm" means, so when encountering a non-OO language, students will we hope recognize how that's not just a superficial/semantic thing, but a whole "way of looking" thing (Wittgenstein) involving "gestalts". That being said, we encourage forays into non-OO languages (I'm not a religious fanatic, believe in wandering and exploring). OK, so that's to put things at a meta "teacher training" level. In practical reality, this approach entails putting a lot of stress on "dot notation" because that's what they'll find in C#, C++, JavaScript, Java and others, or some other symbol playing pretty much the exact same role. Interact with the primitive of native objects Python gives you, learn dot notation interactively in the shell as a "user". Then, after an interlude with functions (including functions that eat and return functions), move to rolling your own class definitions, using __rib__ syntax to savor what it means to be "on the inside" in the object creation business. [1] Now we've talked before on this list how some CS0 types don't want to dive into OO until maybe CS1, and why Python is better than other languages is it *doesn't* force an OO way of looking, can be used by those more into other paradigms or no paradigm at all. Be that as it may, and resisting the urge to defend my approach, I'll just say that in *my* curriculum (not necessarily CS), which I'm in the process of propagating more widely, via screencasts especially, it's OO that's really a starting point (because of the "math objects" we use -- vectors, polynomials, fractals and so forth). Python takes precedence *because* it provides such a clear, uncluttered view of that paradigm. Anyway, that's just *my* little success story (my work is bearing lots of fruit), YMMV.[2] Kirby http://www.4dsolutions.net/ocn/cp4e.html [1] http://controlroom.blogspot.com/search?q=python [2] YMMV = your mileage may vary From mtobis at gmail.com Tue Mar 27 22:52:21 2007 From: mtobis at gmail.com (Michael Tobis) Date: Tue, 27 Mar 2007 15:52:21 -0500 Subject: [Edu-sig] [edupython] Python in Education Advocacy Article In-Reply-To: References: Message-ID: Oof. (Thanks.) :-} Proving once again that eyeballing the test is not running the test! As penance I have reduced it from seven lines to six. This one is actually tested. ######## import sys concord = {} for word in [token.lower() for token in open(sys.argv [1],"r").read().split()]: concord[word] = concord.get(word,0) + 1 result = sorted(concord.items(), lambda x,y: cmp(-x[1],-y[1]) or cmp(x[0],y[0]) ) print "\n".join( ["%s\t%s" % pair[-1::-1] for pair in result] ) # mt ######## On 3/26/07, Toby Donaldson wrote: > > Actually, it appears your code makes a common error: according to the > problem specification, when frequencies are tied, they should be > ordered alphabetically. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20070327/5d52692f/attachment.htm From delza at livingcode.org Tue Mar 27 22:59:29 2007 From: delza at livingcode.org (Dethe Elza) Date: Tue, 27 Mar 2007 13:59:29 -0700 Subject: [Edu-sig] More pipeline developments In-Reply-To: References: Message-ID: <26D6132C-5D5B-4B27-A0C9-F8777C814F4B@livingcode.org> I wanted to thank Markus and Kirby for pointing out Scratch to the list. After a little exposure to Lego Mindstorms, both my kids were able to pick up scratch and start building with it. My ten-year-old helps my 6-year-old with programming now %-) I've had some fun with it as well, although, like Kirby, I miss my OO, and wish I could extend it. Rather than wishing, I'm working on creating a scratch-like view in my Python and Cocoa-based animation tool, Drawing Board. Still very early stages, but I think it could give a nice curve for moving from direct manipulation to drag-and- snap interfaces to reading/writing the resulting code. Thanks! --Dethe On 3-Mar-07, at 8:21 AM, Markus Schlager wrote: > On Fri, 2 Mar 2007, kirby urner wrote: > >> If other subscribers to edu-sig have success stories using >> Scratch, I'd be interested in learning about 'em. Here's >> the web site for those new to this language (note Linux >> version in the works): http://scratch.mit.edu/ >> > > The .exe is just a self-extracting zip-archive. You can run the .image > included with squeaks VM on Linux as well. If you use the archives > directory-structure as is, the only thing not working is the > fullscreen-presentation-mode. > > Three or four weeks from now I'm going to use Scratch with my 7th- > graders > at a German Gymnasium as starting point to teach them algorithmic > thinking, which I consider it a _really_ good tool for. I don't > have to > care about syntax or typewriting and am able to focus on the core > concepts from the very beginning. > > Markus > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig "It is not necessary to change; survival is not mandatory." the late W. Edwards Deming From krstic at solarsail.hcs.harvard.edu Tue Mar 27 23:19:14 2007 From: krstic at solarsail.hcs.harvard.edu (=?UTF-8?B?SXZhbiBLcnN0acSH?=) Date: Tue, 27 Mar 2007 17:19:14 -0400 Subject: [Edu-sig] [edupython] Python in Education Advocacy Article In-Reply-To: References: Message-ID: <46098A52.4040108@solarsail.hcs.harvard.edu> Michael Tobis wrote: > As penance I have reduced it from seven lines to six. This one is > actually tested. You know, when confronted with this type of little, one-off problems before, I used to write Perl code like this: for (1..5){@d = sort split //,($_+(chomp($_=))*0); $t=(@d%2)?($d[int(@d/2)]):($d[@d/2-1]); s/$t/($t<3)?$d[-1]:(($t<6)?$d[0]:(($t<9)?(sub{$s+=$_for(@d);$s%10}->()):0))/e; print $_+0;} So when I see code that reads about as easily on a Python list, I think it might be time to tell people to step back, take a deep breath, and remember there's a reason they're using Python -- and it's not reducing the LOC count ;) -- Ivan Krsti? | GPG: 0x147C722D From mtobis at gmail.com Tue Mar 27 23:28:53 2007 From: mtobis at gmail.com (Michael Tobis) Date: Tue, 27 Mar 2007 16:28:53 -0500 Subject: [Edu-sig] Python in Education Advocacy Article In-Reply-To: References: Message-ID: Thanks. Kirby's is an interesting response with which I basically agree. Those of us who learned programming when the model was close to the machine model (Fortran, C) have had a hard time wrapping our heads around objects. A good friend whom I very much admire has argued (this was per-Python so I am not sure whether he stands by this) that OOP is for experts and shouldn't be foisted on beginners at all. I have seen the consequences of premature stress on OOP; supposedly professional programmers writing gobs of Fortran-like code in Java; great hulking monstrosities of procedural code wrapped in "public static void main" for bureaucratic reasons, to convince javac to allow the fortranlike code through. The blame goes to the instructor who did not manage to understand what advantages the object model brings to the table at all. The resulting Java code provides the worst of both worlds: all the overhead of OOP and Java with none of the advantages. Python's gentle introduction to objects makes the distinction between procedural and OO approaches visible gradually. You don't have to **explain** the concept, which is very difficult lacking the experience. The usual examples of a car is-a vehicle and a car has-a motor seem utterly pointless, and yet abstractions which actually add substantial value are not easily seen by people who haven't felt the need for them. With Python you aren't left in a position of trying to explain the benefits of OOP after people have developed non-objecty habits and ways of thinking, nor before they have a need for the abstractions that you enforce. The veil is lifted gradually, at the right time and in the right measure. This is a remarkable feature. It strikes me that this ties in with something Ian Bicking once blogged: "This is often how I feel about object-oriented programming, and somewhere where I think Python's imperative approach is a real feature. Starting on an application by building objects (or doing "whole design") is a bad idea, unless you know the domain well. It's better to get it doing what you need to do, and think about objects along the way. Somewhere you'll notice you keep passing around the same value(s) to a set of functions -- those set of values are "self", and those functions are methods. You'll find ways to split things into modules, etc. Designing objects and modules too early and you'll have lots of circular dependencies and poor metaphors. Of course, you can fix all those, but it's easier to add structure to a naive project than to reshape and restructure a misdeveloped project." The similarity between these arguments is striking, even though they are aimed at very different groups of code developers. Which leads to another argument in Python's favor; the continuity of approach between very small and very large projects, and between very simple and very complex goals. The fact that we can offer a language to beginners which has some traction as vocational training is something of a mixed blessing if we think computer programming is "for everybody", but the fact that Python is not a "training wheel" language. Without compromise, itt supports the entire range of activity from casual dabbling all the way to the most sophisticated abstractions. This, I think, is unique. mt From mtobis at gmail.com Tue Mar 27 23:47:31 2007 From: mtobis at gmail.com (Michael Tobis) Date: Tue, 27 Mar 2007 16:47:31 -0500 Subject: [Edu-sig] [edupython] Python in Education Advocacy Article In-Reply-To: <46098A52.4040108@solarsail.hcs.harvard.edu> References: <46098A52.4040108@solarsail.hcs.harvard.edu> Message-ID: On 3/27/07, Ivan Krsti? wrote: > Michael Tobis wrote: > So when I see code that reads about as easily on a Python list, I think > it might be time to tell people to step back, take a deep breath, and > remember there's a reason they're using Python -- and it's not reducing > the LOC count ;) While I think that is a bit harsh on my little hack, your point is well taken. (And let me say that it is an honor and a pleasure to hear from you!) However it's a little frustrating; you say "there's a reason" but you leave me to guess what you think that reason might be. I am looking for is people actually *articulating* what they like (and dislike!) about Python, especially in an educational context. (Am I asking people to do my homework for me? Well, yeah, sure. I am not claiming to be the smartest person who has an interest in this topic, and I am certainly not the most experienced, but I still want to produce an article that moves the field forward a bit. The more help I can get, the better.) I see that: "Ivan is a strong advocate of open source software and software libre. He thinks Python may well be the greatest thing since sliced bread." (http://blogs.law.harvard.edu/ivan/) I agree about the sliced bread thing. I'd love to know why that is, though, if you can spare a few minutes to try to articulate it. mt From lac at openend.se Wed Mar 28 00:23:55 2007 From: lac at openend.se (Laura Creighton) Date: Wed, 28 Mar 2007 00:23:55 +0200 Subject: [Edu-sig] [edupython] Python in Education Advocacy Article In-Reply-To: Message from "Michael Tobis" of "Tue, 27 Mar 2007 16:47:31 CDT." References: <46098A52.4040108@solarsail.hcs.harvard.edu> Message-ID: <200703272223.l2RMNtZG018240@theraft.openend.se> In a message of Tue, 27 Mar 2007 16:47:31 CDT, "Michael Tobis" writes: >I see that: > >"Ivan is a strong advocate of open source software and software libre. >He thinks Python may well be the greatest thing since sliced bread." >(http://blogs.law.harvard.edu/ivan/) > >I agree about the sliced bread thing. I'd love to know why that is, >though, if you can spare a few minutes to try to articulate it. > >mt I find it really interesting the way language evolves. Sliced bread (as opposed to the sort of bread you have to slice yourself, i.e. bought already sliced at the store) is nearly always wretched stuff. It was, however, heavily marketed in the USA post WW2. Thus 'the greatest thing since sliced bread' began -- at least where my father was living in Toronto just post WW2 --entirely ironically, and was used to desribe things that were both terrible and hyped. These days, however, most people who say 'the greatest thing since sliced bread' are desribing something that they truly do find great. I wonder why/when the ironic context left. Perhaps it is a generational thing. I know that my father continues to use 'the greatest thing since sliced bread' as a favoured way to express scorn, and my language habits come from him. Did it not have this context in other parts of the world? Or was this widespread, and is now dying? I guess we need a dicitonary-of-idioms and-expressions to go with the Slang dictionary ... Laura From lac at openend.se Wed Mar 28 00:25:40 2007 From: lac at openend.se (Laura Creighton) Date: Wed, 28 Mar 2007 00:25:40 +0200 Subject: [Edu-sig] [edupython] Python in Education Advocacy Article In-Reply-To: Message from "Michael Tobis" of "Tue, 27 Mar 2007 16:47:31 CDT." References: <46098A52.4040108@solarsail.hcs.harvard.edu> Message-ID: <200703272225.l2RMPeYr018976@theraft.openend.se> A first programming language should be interpreted not compiled. It should also not have type declarations. Laura From lac at openend.se Wed Mar 28 00:36:35 2007 From: lac at openend.se (Laura Creighton) Date: Wed, 28 Mar 2007 00:36:35 +0200 Subject: [Edu-sig] [edupython] Python in Education Advocacy Article In-Reply-To: Message from Laura Creighton of "Wed, 28 Mar 2007 00:25:40 +0200." <200703272225.l2RMPeYr018976@theraft.openend.se> References: <46098A52.4040108@solarsail.hcs.harvard.edu> <200703272225.l2RMPeYr018976@theraft.openend.se> Message-ID: <200703272236.l2RMaZaZ020686@theraft.openend.se> 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 From mtobis at gmail.com Wed Mar 28 00:54:03 2007 From: mtobis at gmail.com (Michael Tobis) Date: Tue, 27 Mar 2007 17:54:03 -0500 Subject: [Edu-sig] [edupython] Python in Education Advocacy Article In-Reply-To: <200703272236.l2RMaZaZ020686@theraft.openend.se> References: <46098A52.4040108@solarsail.hcs.harvard.edu> <200703272225.l2RMPeYr018976@theraft.openend.se> <200703272236.l2RMaZaZ020686@theraft.openend.se> Message-ID: This is all great stuff! Thanks to all who responded here or in email! However so far this all goes to only half of the questions I am trying to address. I'd also like to consider the bad news. At least three important projects that I know of have abandoned Python in favor of Java or Squeak: 1) Alice 2) Patapata 3) Mark Guzdial's CS for artists course/textbook It is also plain to see that self-directed web-centric beginners are more likely to gravitate to Javascript, Actionscript/Flash or PHP. What are the roots of these choices? Should we be concerned about them? If so, is there anything we can and should realistically do about them? mt From francois.schnell at gmail.com Fri Mar 30 19:38:31 2007 From: francois.schnell at gmail.com (francois schnell) Date: Fri, 30 Mar 2007 19:38:31 +0200 Subject: [Edu-sig] More pipeline developments In-Reply-To: <26D6132C-5D5B-4B27-A0C9-F8777C814F4B@livingcode.org> References: <26D6132C-5D5B-4B27-A0C9-F8777C814F4B@livingcode.org> Message-ID: <13a83ca10703301038k19199ff6o819a1df40fd3a831@mail.gmail.com> A Blog post concerning Scratch from Bill Kerr, a teacher and Python programmer in Australia : http://billkerr2.blogspot.com/2007/03/scratch.html He also had a post on Pata Pata: http://billkerr2.blogspot.com/search?q=patapata francois On 3/27/07, Dethe Elza wrote: > > I wanted to thank Markus and Kirby for pointing out Scratch to the > list. After a little exposure to Lego Mindstorms, both my kids were > able to pick up scratch and start building with it. My ten-year-old > helps my 6-year-old with programming now %-) > > I've had some fun with it as well, although, like Kirby, I miss my > OO, and wish I could extend it. Rather than wishing, I'm working on > creating a scratch-like view in my Python and Cocoa-based animation > tool, Drawing Board. Still very early stages, but I think it could > give a nice curve for moving from direct manipulation to drag-and- > snap interfaces to reading/writing the resulting code. > > Thanks! > > --Dethe > > On 3-Mar-07, at 8:21 AM, Markus Schlager wrote: > > > On Fri, 2 Mar 2007, kirby urner wrote: > > > >> If other subscribers to edu-sig have success stories using > >> Scratch, I'd be interested in learning about 'em. Here's > >> the web site for those new to this language (note Linux > >> version in the works): http://scratch.mit.edu/ > >> > > > > The .exe is just a self-extracting zip-archive. You can run the .image > > included with squeaks VM on Linux as well. If you use the archives > > directory-structure as is, the only thing not working is the > > fullscreen-presentation-mode. > > > > Three or four weeks from now I'm going to use Scratch with my 7th- > > graders > > at a German Gymnasium as starting point to teach them algorithmic > > thinking, which I consider it a _really_ good tool for. I don't > > have to > > care about syntax or typewriting and am able to focus on the core > > concepts from the very beginning. > > > > Markus > > _______________________________________________ > > Edu-sig mailing list > > Edu-sig at python.org > > http://mail.python.org/mailman/listinfo/edu-sig > > > > "It is not necessary to change; survival is not mandatory." the late > W. Edwards Deming > > > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20070330/236c3048/attachment.htm From pdfernhout at kurtz-fernhout.com Sat Mar 31 06:13:59 2007 From: pdfernhout at kurtz-fernhout.com (Paul D. Fernhout) Date: Sat, 31 Mar 2007 00:13:59 -0400 Subject: [Edu-sig] [edupython] Python in Education Advocacy Article In-Reply-To: References: <46098A52.4040108@solarsail.hcs.harvard.edu> <200703272225.l2RMPeYr018976@theraft.openend.se> <200703272236.l2RMaZaZ020686@theraft.openend.se> Message-ID: <460DE007.5030505@kurtz-fernhout.com> To clarify, on PataPata, at the moment I am using Jython to prototype a version of a Smalltalk-like system and syntax for the Java (JVM) platform. I am doing this in part to have a system which supports "edit and continue", and also in part just because it is fun. I think Java is a terrible language for a human to use because it is too verbose (among other reasons). Still, after ten years, the JVM is a not-that-terrible platform which has the advantage of hype and installed base and can supply about 1/2 C speeds in a portable way. So Java (or JVM byte codes) isn't that awful as a portable machine language -- and it involves less work for a single programmer to maintain a complex application across multiple platforms than for C. Personally, I like Swing, but then, I come from the world (VisualWorks) where most core Swing designers come from. :-) There is no question in my mind that Jython is a much saner way to write code for the JVM than Java in most situations. And Jython is probably a better choice for most JVM things than most of these JVM languages: http://www.robert-tolksdorf.de/vmlanguages.html (unless you already know one of the other languages or have a problem which has a neatly packaged solution in one of those systems). Still, for anything other than writing arbitrary portable fast code (1/2 C) or code that interfaces easily with Java libraries, Python by itself is probably a more reliable cross platform solution than JVM approaches in many situations. In any case, there is still a lot of Python in my own noodling around, at least for now. :-) And also, while I learned a lot about prototypes and their strengths and weaknesses when writing Python code for PataPata to emulate prototypes in Python, if anything, I developed a better respect for how much you could do quirky things in plain old Python when you wanted to or needed to, thus minimizing some of the need to use prototypes for everything. Still, there are always tempting new projects like "Factor" http://factorcode.org/ which uses FORTH ideals to do amazing things (like with OpenGL) in fairly small footprints and with minimal external dependencies and with fairly few core developer-years of work (though the developers are unusually bright. :-) From the web page: "Factor has an optimizing native compiler, automatic memory management with a generational garbage collector, a powerful collections library, and various advanced language features such as higher-order programming, continuations, and extensible syntax. Factor development is done in an interactive environment with a graphical user interface. There is a single-stepping debugger which can travel backwards in time, and extensive documentation. An easy to use C library interface allows one to call C libraries without writing any glue code in C. Bindings for OpenGL, FreeType, X11, Cocoa, and Windows APIs are provided." (I can hope AK's FONC http://vpri.org/mailman/listinfo/fonc http://www.viewpointsresearch.org/html/writings.htm in a few years will produce something even beyond that, if it succeeds). In any case, I see the JVM, Python, C, FONC, Squeak, and Factor as all possible substrates for running a higher level system on top of. A well designed self-reflective system really should be able to run on all of them with appropriate back ends and interface layers. It just requires a higher level of abstraction than, for example, how PataPata already runs on both top of Python/TK and Jython/Swing. And also a willingness to sacrifice some performance in some situations. :-) Right now, on a 3Ghz AMD64, this new VM in Jython is doing about 25000 message sends a second (and about 30K in Python). This is about 1/1000 the speed of C, but I think when the system reflects on itself and can generate pure Java, I am hoping to have it at Python-ish and Squeak-ish speeds of about 1/20 to 1/100 C overall for loops and calls and sends. But given how fast computers continue to get, I'm not too concerned about performance. Even if it remained at 1/1000 C speed, in ten years, that would mean it would run about the speed of C on today's computers -- and there are plenty of interesting applications one can run on today's computers. I also have Jython GUI that lets me single step through hand-compiled code. (None of this has been checked in so SourceForge yet though.) From an educational point of view, looking at such a system and changing it, even if the system was never used for any other activity) could help Python-literate people understand more about message passing and VM construction and (abstractly) how a CPU works. I'm certainly learning something from it. :-) I certainly remain completely pro-Python for commercial development. And I remain pro-Python as the language of choice to teach most kids with at the appropriate age. It's a great language. And a great community. Python generally plays nice with other systems (including C and Java) and looks a lot like what most programmers already know, making it an easy "upsell" as a dynamic language compared to, say, Smalltalk or Lisp. http://dictionary.reference.com/browse/upsell And Python has really hit its stride now seeing all the great job postings for people knowledgeable in it to do very interesting work. If I was teaching a kid programming right now, I would recommend Python as the best all-around choice without hesitation, especially as a first language. (Although, for kids who wanted to be computer or electronic engineers, I might still suggest Forth as a best first language, so they learn good factoring habits early on, plus a basic familiarity with low level issues in an interactive environment. But even then, Python should come next, for its practicality. :-) Still, as much as I like Python, I think lack of "edit and continue" in Python is a big issue -- both for advanced users and beginners, especially given how Smalltalk, Ruby, C#, Visual Basic, and other languages have it. Having to rerun Python applications due to typos or to insert print statements is the biggest thorn in my paw when I use Python. As I have said, I think lack of "Edit and continue" probably reduces Python developer productivity to about 1/3 of what it could be (although you can get part of that back by hacking your application to use a reloader window like the one I posted on the Jython user list). Still, even with this glaring handicap relative to other dynamic and static languages like Ruby or VB or C#, Python still usually comes out on top IMHO over many other languages for most common programming tasks for various reasons based on its strengths. Which just shows what an awesome language Python is, still winning the race while putt-putting on two cylinders instead of vrooming by on the six cylinders everyone else has out of the box. Some kinda magic going on there. :-) I started to look into seeing how "edit and continue" could be addressed with Python, but, especially given Guido saying it was "impossible", and looking in the email archives of various lists to see it has been brought up multiple times on comp.lang.python and such and shot down, http://www.google.com/search?hl=en&q=python+%22edit+and+continue%22 it seems it might be easier to build something from scratch which supports it (on top of Java using those libraries) than to try (and fail) to improve Python. I also have always preferred Smalltalk keyword syntax over Python, as it is easily extensible (and easily readable (to me), so there are always forces tugging me towards creating alternatives, which people here will rightfully say stand a snowball's chance of seeing widespread adoption. The bottom line on "Edit and continue" is that making it work properly likely requires deep thinking and understanding about the entire Python runtime system (as well as getting pickup of your changes by various IDE developers), and Python as a system has moved so far along the development curve that coming from a standing start up to an understanding of Python's current internals necessarily beyond that of Guido (who says it is impossible :-) is likely a long hard effort. During which time Python will keep moving. It's not exactly a best first choice of Python internals hacking. Guido is obviously the best person to tackle it, I think; just need to figure out how to motivate him to care about it instead of other cool and important things. Now if I could just get hold of some "first herring" perhaps? :-) http://travel.independent.co.uk/europe/article548699.ece http://en.wikipedia.org/wiki/Herring Still, if a student in the "Summer of Code" (or others) got interested in the project, then I would revisit my personal support for it. I'm sure it's doable -- just a matter of how much of Python's (or Jython's) internals would need to be strewn about the floor before it worked (and an IDE's too, I guess) -- and then how many of those scattered pieces could be fit back together under the hood. The shortest path is modifying an existing IDE (PyDev? IDLE?) and an existing Python or Jython VM so it breaks on any exception before it is thrown (avoiding the likely most "impossible" part of restarting a thrown Python exception), and then providing ways in the IDE where you can specify which modules and exceptions are debugged and which are thrown, and then having an ability to selectively modify a function and reenter it with the same preserved entry state (sort of like a continuation). And of course, you need to then save the change back to the source file. We already have the reloading code; we would just copy over the one modified function. I have poked around some in Jython internals, so for me, adding "edit and continue" to Jython would be the easier possibility than for CPython (but of a more limited audience). If I recall correctly, Jython uses Java exceptions, which are not restartable, so that approach would likely always be be limited to breaking on where they are raised (unless the JVM itself changes). Still, if/when I get the Smalltalk-syntax support on this new base (not much time for it these days for various reasons), I don't see any reason a Python-syntax could not also be added to it (especially using one of the Python-in-Python compilers as the base). So, I fully expect the outcome of what I am doing could support a Python-ish syntax to get edit and continue. But that really is not what we all want, as opposed to the real thing -- Python 2.6 with "edit and continue support". :-) Perhaps someone with experience writing a PEP might want to work with me on at least defining the problem in a way it could be formally submitted? Of course now that I look even harder at people's comments on "edit and continue" I just came across this: http://haacked.com/archive/2006/02/08/OnReligiousWarsinSoftware.aspx listing "Edit and continue" as #5 on "Well Known Religious" wars. :-) Which completely surprises me how people could be against it (and yes, I have read some counter arguments, http://www.codinghorror.com/blog/archives/000507.html but never seen one from someone who had ever actually used the feature extensively, at least when well implemented in a system like Smalltalk, including ones that allow "coding in the debugger" as a development style: http://www.google.com/search?hl=en&q=%22coding+in+the+debugger%22 ) Still, for fixing typos alone, this "edit and continue" feature could save many people (especially beginners) a lot of time with Python IMHO. If Python had it, I'd probably stop thinking about Smalltalk so much. :-) --Paul Fernhout Michael Tobis wrote: > This is all great stuff! Thanks to all who responded here or in email! > > However so far this all goes to only half of the questions I am trying > to address. > > I'd also like to consider the bad news. At least three important > projects that I know of have abandoned Python in favor of Java or > Squeak: > > 1) Alice > 2) Patapata > 3) Mark Guzdial's CS for artists course/textbook > > It is also plain to see that self-directed web-centric beginners are > more likely to gravitate to Javascript, Actionscript/Flash or PHP. > > What are the roots of these choices? Should we be concerned about > them? If so, is there anything we can and should realistically do > about them? From delza at livingcode.org Sat Mar 31 06:31:02 2007 From: delza at livingcode.org (Dethe Elza) Date: Fri, 30 Mar 2007 21:31:02 -0700 Subject: [Edu-sig] [edupython] Python in Education Advocacy Article In-Reply-To: <460DE007.5030505@kurtz-fernhout.com> References: <46098A52.4040108@solarsail.hcs.harvard.edu> <200703272225.l2RMPeYr018976@theraft.openend.se> <200703272236.l2RMaZaZ020686@theraft.openend.se> <460DE007.5030505@kurtz-fernhout.com> Message-ID: On 30-Mar-07, at 9:13 PM, Paul D. Fernhout wrote: > Still, there are always tempting new projects like "Factor" > http://factorcode.org/ > which uses FORTH ideals to do amazing things (like with OpenGL) in > fairly small footprints and with minimal external dependencies and > with > fairly few core developer-years of work (though the developers are > unusually bright. :-) From the web page: "Factor has an optimizing > native compiler, automatic memory management with a generational > garbage > collector, a powerful collections library, and various advanced > language > features such as higher-order programming, continuations, and > extensible > syntax. Factor development is done in an interactive environment > with a > graphical user interface. There is a single-stepping debugger which > can > travel backwards in time, and extensive documentation. An easy to > use C > library interface allows one to call C libraries without writing any > glue code in C. Bindings for OpenGL, FreeType, X11, Cocoa, and Windows > APIs are provided." (I can hope AK's FONC > http://vpri.org/mailman/listinfo/fonc > http://www.viewpointsresearch.org/html/writings.htm > in a few years will produce something even beyond that, if it > succeeds). Factor looks interesting. You also might be interested in Io: http://iolanguage.com/about/ Io is a small, prototype-based programming language. The ideas in Io are mostly inspired by Smalltalk (all values are objects), Self (prototype-based), NewtonScript (differential inheritance), Act1 (actors and futures for concurrency), LISP (code is a runtime inspectable/modifiable tree) and Lua (small, embeddable). Despite the fact that Python isn't listed as an influence on Io, I find it has a bit of a pythonic feel, with the difference that prototyping brings. It has bindings to a rich set of external (mostly C) libraries (async sockets and dns, SQLite and SkipDB (embedded transactional databases), regular expressions (Perl 5 compatible), xml/html/sgml parsing, md5, sha1, zlib, lzo, blowfish, curses (text interfaces), OpenGL/GLUT, PortAudio, FreeType (TrueType antialised font support),Objective-C bridge. And, one of my favorite things, it has Erlang-like messaging and scalable (non-thread) concurrency. Not quite ready for prime time yet, but very interesting to keep an eye on. > The bottom line on "Edit and continue" is that making it work properly > likely requires deep thinking and understanding about the entire > Python > runtime system (as well as getting pickup of your changes by > various IDE > developers), and Python as a system has moved so far along the > development curve that coming from a standing start up to an > understanding of Python's current internals necessarily beyond that of > Guido (who says it is impossible :-) is likely a long hard effort. > During which time Python will keep moving. It's not exactly a best > first > choice of Python internals hacking. Guido is obviously the best person > to tackle it, I think; just need to figure out how to motivate him to > care about it instead of other cool and important things. Now if I > could > just get hold of some "first herring" perhaps? :-) > http://travel.independent.co.uk/europe/article548699.ece > http://en.wikipedia.org/wiki/Herring Well, the herring is probably the OLPC, which Guido is working to support by implementing edit and continue, according to his blog: http://www.artima.com/weblogs/viewpost.jsp?thread=197203 The software is far from finished. An early version of the GUI and window manager are available, and a few small demo applications: chat, video, two games, and a web browser, and that's about it! The plan is to write all applications in Python (except for the web browser), and a "view source" button should show the Python source for the currently running application. In the tradition of Smalltalk (Alan Kay is on the OLPC board, and has endorsed the project's use of Python) the user should be able to edit any part of a "live" aplication and see the effects of the change immediately in the application's behavior. (A versioned document store will make it possible to roll back disastrous changes.) This is where Krstic wants my help: he hopes I can work magic and implement this feature for Python. I got started right away during the conference, with a reimplementation of python's reload() function that can patch classes and functions in place. Even this small component still has a long way to go; a checkpoint of the work in progress is checked into subversion as part of the Py3k standard library. That's not where the rest of my OLPC work will show up; they use GIT for source control, so I will get to learn that. At least, that's what it looks to me like he's saying, and he said much of the same thing on this list when he posted an improved reload module that he said was a simpler version of the one he was working on. Maybe it won't be as powerful as Smalltalk's edit-and-continue, but it might end up being the 80/20 solution to the same problem. Now if I could just get him to take concurrency seriously (and the only serious approach to concurrency that seems to be workable is what Erlang does). --Dethe "...our universities, I suggest, are not half-way out of the fifteenth century. [...] The three or four years' course of lectures, the bachelor who knows some, the master who knows most, the doctor who knows all, are ideas that have come down unimpaired from the Middle Ages. Nowadays no one should end his learning while he lives and these university degrees are preposterous. [...] Educationally we are still for all practical purposes in the coach and horse and galley stage." H. G. Wells From lac at openend.se Sat Mar 31 12:00:22 2007 From: lac at openend.se (Laura Creighton) Date: Sat, 31 Mar 2007 12:00:22 +0200 Subject: [Edu-sig] Europython -- education theme Message-ID: <200703311000.l2VA0MJQ006846@theraft.openend.se> Europython's CFP is out. See: http://wiki.python.org/moin/EuroPython/2007/CallForProposals Rather than having tracks, we are having _themes_ this year, in the hopes that people who have interesting things to present (so demos are ok, as well as talks) will not conclude that they are not wanted because they don't fit the description of a talk. Despite all of that I have been asked to write a description of the Education theme. Post here or mail me words, expressions and the like that you think should be mentioned so I won't forget something important. Thank you. Laura From pdfernhout at kurtz-fernhout.com Sat Mar 31 14:15:18 2007 From: pdfernhout at kurtz-fernhout.com (Paul D. Fernhout) Date: Sat, 31 Mar 2007 08:15:18 -0400 Subject: [Edu-sig] [edupython] Python in Education Advocacy Article In-Reply-To: References: <46098A52.4040108@solarsail.hcs.harvard.edu> <200703272225.l2RMPeYr018976@theraft.openend.se> <200703272236.l2RMaZaZ020686@theraft.openend.se> <460DE007.5030505@kurtz-fernhout.com> Message-ID: <460E50D6.6060305@kurtz-fernhout.com> Dethe- Thanks for the links and ideas. I've never tried to work in io, though I had downloaded it and tried to run some applications in it. I can't get past the syntax. :-) I think Smalltalk syntax was one of the things best about it, yet most of the alternatives (like IO) try to put C-ish syntax on Smalltalk ideas. And I do love Python's significant indentation. Anyway, the XO OLPC project and it's "view source key" is a great angle for getting "edit and continue" into the Python mainstream eventually. However, perhaps what the XO OLPC project really needs as well is a "break" key and a "trace" key. :-) Maybe it has them too? Now this is interesting and surprising on Guido's blog post as well: http://www.artima.com/weblogs/viewpost.jsp?thread=197203 "The keynotes had a strong educational theme: on Saturday morning Adele Goldberg gave a passionate plea for improvements to the USA's educational system. 40 years ago, US education was #1 in the world; today it is #19. The public school system is stuck in a complete political gridlock; changes are nearly impossible to make due to the many constraints imposed on schools by federal regulations, fearful and litigious parents, bullying, lack of funds, and many other depressing factors. It also seems that most uses of computers in the classroom have turned into disasters: the well-meaning geeks behind many school computer experiments don't understand the situation in the average classroom. For example, computers show up without sufficient power, are likely to be stolen, or locked up in a safe rather than being used! Schools are in total fear of the internet, which is seen as a source of pornography and influences of the devil. I hope Adele will put her slides on line, there was much interesting data." What a far cry from "computer programming for everyone". :-( I guess I really haven't given Python3000 much thought because it seemed always such a long time away; looks like it is finally coming to fruition. Another good time for any incompatible changes (if needed) to allow "edit and continue". --Paul Fernhout Dethe Elza wrote: > On 30-Mar-07, at 9:13 PM, Paul D. Fernhout wrote: > >> Still, there are always tempting new projects like "Factor" >> http://factorcode.org/ >> which uses FORTH ideals to do amazing things (like with OpenGL) in >> fairly small footprints and with minimal external dependencies and >> with >> fairly few core developer-years of work (though the developers are >> unusually bright. :-) From the web page: "Factor has an optimizing >> native compiler, automatic memory management with a generational >> garbage >> collector, a powerful collections library, and various advanced >> language >> features such as higher-order programming, continuations, and >> extensible >> syntax. Factor development is done in an interactive environment >> with a >> graphical user interface. There is a single-stepping debugger which >> can >> travel backwards in time, and extensive documentation. An easy to >> use C >> library interface allows one to call C libraries without writing any >> glue code in C. Bindings for OpenGL, FreeType, X11, Cocoa, and Windows >> APIs are provided." (I can hope AK's FONC >> http://vpri.org/mailman/listinfo/fonc >> http://www.viewpointsresearch.org/html/writings.htm >> in a few years will produce something even beyond that, if it >> succeeds). > > Factor looks interesting. You also might be interested in Io: > > http://iolanguage.com/about/ > > Io is a small, prototype-based programming language. The ideas > in Io are mostly inspired by Smalltalk (all values are objects), Self > (prototype-based), NewtonScript (differential inheritance), Act1 > (actors and futures for concurrency), LISP (code is a runtime > inspectable/modifiable tree) and Lua (small, embeddable). > > Despite the fact that Python isn't listed as an influence on Io, I > find it has a bit of a pythonic feel, with the difference that > prototyping brings. It has bindings to a rich set of external > (mostly C) libraries (async sockets and dns, SQLite and SkipDB > (embedded transactional databases), regular expressions (Perl 5 > compatible), xml/html/sgml parsing, md5, sha1, zlib, lzo, blowfish, > curses (text interfaces), OpenGL/GLUT, PortAudio, FreeType (TrueType > antialised font support),Objective-C bridge. And, one of my favorite > things, it has Erlang-like messaging and scalable (non-thread) > concurrency. Not quite ready for prime time yet, but very > interesting to keep an eye on. > >> The bottom line on "Edit and continue" is that making it work properly >> likely requires deep thinking and understanding about the entire >> Python >> runtime system (as well as getting pickup of your changes by >> various IDE >> developers), and Python as a system has moved so far along the >> development curve that coming from a standing start up to an >> understanding of Python's current internals necessarily beyond that of >> Guido (who says it is impossible :-) is likely a long hard effort. >> During which time Python will keep moving. It's not exactly a best >> first >> choice of Python internals hacking. Guido is obviously the best person >> to tackle it, I think; just need to figure out how to motivate him to >> care about it instead of other cool and important things. Now if I >> could >> just get hold of some "first herring" perhaps? :-) >> http://travel.independent.co.uk/europe/article548699.ece >> http://en.wikipedia.org/wiki/Herring > > Well, the herring is probably the OLPC, which Guido is working to > support by implementing edit and continue, according to his blog: > > http://www.artima.com/weblogs/viewpost.jsp?thread=197203 > > The software is far from finished. An early version of the GUI and > window manager are available, and a few small demo applications: > chat, video, two games, and a web browser, and that's about it! The > plan is to write all applications in Python (except for the web > browser), and a "view source" button should show the Python source > for the currently running application. In the tradition of Smalltalk > (Alan Kay is on the OLPC board, and has endorsed the project's use of > Python) the user should be able to edit any part of a "live" > aplication and see the effects of the change immediately in the > application's behavior. (A versioned document store will make it > possible to roll back disastrous changes.) This is where Krstic wants > my help: he hopes I can work magic and implement this feature for > Python. I got started right away during the conference, with a > reimplementation of python's reload() function that can patch classes > and functions in place. Even this small component still has a long > way to go; a checkpoint of the work in progress is checked into > subversion as part of the Py3k standard library. That's not where the > rest of my OLPC work will show up; they use GIT for source control, > so I will get to learn that. > > > At least, that's what it looks to me like he's saying, and he said > much of the same thing on this list when he posted an improved reload > module that he said was a simpler version of the one he was working > on. Maybe it won't be as powerful as Smalltalk's edit-and-continue, > but it might end up being the 80/20 solution to the same problem. > > Now if I could just get him to take concurrency seriously (and the > only serious approach to concurrency that seems to be workable is > what Erlang does). > > --Dethe > > "...our universities, I suggest, are not half-way out of the fifteenth > century. [...] The three or four years' course of lectures, the bachelor > who knows some, the master who knows most, the doctor who knows all, > are ideas that have come down unimpaired from the Middle Ages. > Nowadays no one should end his learning while he lives and these > university degrees are preposterous. [...] Educationally we are still > for all practical purposes in the coach and horse and galley stage." > H. G. Wells From james at dis-dot-dat.net Sat Mar 31 14:15:39 2007 From: james at dis-dot-dat.net (james at dis-dot-dat.net) Date: Sat, 31 Mar 2007 13:15:39 +0100 Subject: [Edu-sig] Metaphor-oriented programming Message-ID: <20070331121539.GA13739@fitz.Belkin> Hi, I thought you might be interested in this article (http://www.dis-dot-dat.net/?item=metaphor) on metaphor-oriented programming and how it might help HE-level teaching of programming. James