From andre.roberge at gmail.com Wed Jun 1 03:08:55 2005 From: andre.roberge at gmail.com (=?ISO-8859-1?Q?Andr=E9_Roberge?=) Date: Tue, 31 May 2005 22:08:55 -0300 Subject: [Edu-sig] ANN: Version 0.9 of RUR-PLE Message-ID: Version 0.9 of RUR: a Python Learning Environment has been released. Information about RUR-PLE can be obtained at http://rur-ple.sourceforge.net Note that the project website is slightly out of date. Among the changes in this new version: ***Spanish translation added.* Changed image for language selection to reflect addition. Changed directory structure of lessons. Fixed "non-existent file" problem when changing language with unstranslated lesson file open in browser; the browser will open the default file in the chosen language instead. Changed dialogs (beepers to robot and resize world) to use GridBagSizer for layout as opposed to specific coordinates. Added parameter wx.BUFFER_VIRTUAL_AREA in dc = wx.BufferedPaintDC(self, self.buffer, wx.BUFFER_VIRTUAL_AREA) in world_display.py; this is required to get proper scrolling since wxPython 2.5.4.1. Added SetFocus() when positioning sizer on "Robot: code and learn" page. This gets rid of the unwanted grey background. Changed list of beepers that can be placed at an intersection from 0 ... 15, 16, 17, 18, 19, 20 to 0 ... 15, 20, 40, 60, 80, 99. Removed the "from __future__ import division" command to the interpreter. Since this is not likely to be the default version for a *long* time, it seems a better idea to revert to the default behaviour for the interpreter. TODO: The lesson needs to be updated to reflect this change. World redrawn immediately after selecting a new language, so that the words "streets" and "avenues" are updated right away. Corrected tooltip language setting on speed selection slider. Added possibility to change background colour of robot world through user program. This is to be used in the random maze escape lesson. Changed the 20 robot images so that their background is transparent. Removed obsolete self-testing code in various files as well as redundant import statements. Fixed problem with seemingly random "invalid world file" error. This occured when a robot was removed from the world, and an attempt was made at resetting the world. Added SetFocus() to WorldGui.OnLeftDown(). Somehow, the WorldGUI (i.e. robot world) would no longer get focus as a matter of course when left-clicked. This meant that it was no longer possible to position the robot using the cursor keys. This problem has appeared since I made the switch to wxPython 2.6. From urnerk at qwest.net Wed Jun 1 05:34:52 2005 From: urnerk at qwest.net (Kirby Urner) Date: Tue, 31 May 2005 20:34:52 -0700 Subject: [Edu-sig] A tale of two hand puppets Message-ID: <20050601033453.EC6F21E4003@bag.python.org> So I have this vision of a puppet show, which I tested out on a high school computer teacher today. He said it made sense. Arm 1 (left or right, I don't care) is the traditional math arm, and its puppet tends to talk one into a precalculus course of study, culminating in calculus, then pointing off into other subjects in college, its job largely done by this point. Arm 2 is a younger CS track, likewise reaching into the K-12 classroom, but so far weaker than arm 2. The problem of what language to use has been bothersome. But as the kinks get worked out, more muscles get added and the arm grows in strength. Part of its food source is again mathematics, but in a different mix than we find in precalc/calc; more group and number theory for example. So what's happening is arm 2 is gaining in strength by leaps and bounds, and shortly what we'll see are two trajectories through the K-12 namespace that have equal legitimacy in terms of offering a strong set of mathematical concepts. The CS arm will grow from a discrete math basis, whereas arm 1 is more wired into real analysis and like that. At the end of each arm is a puppet, talking up a storm, doing a lot of interacting with the K-12 audience (teachers included). Bag puppets if you like -- I prefer something more elaborate (spoiled by Muppets I guess). The two puppets are starting to get more equal, more comparable in terms of character development and recruiting appeal. Pretty soon, kids will be seeing new career tracks, still mostly through colleges and universities, along this alternative arm 2 trajectory. That's for the better I think, as the competition and positive synergies involved will make both arms stronger in the long run ('stronger arms = a better puppet show' is how I'm structuring this analogy). The contrasts become sharper, concepts get thrown into deeper relief, clarity is added, the range of options is broadened, we accommodate more individual profiles and preferences. I feel the momentum towards something like this is pretty strong, with or without my specific input. However, I think my appreciation for Python, shared with others here on edu-sig, gives me a front row seat and at least some steering capabilities. In particular, I'm seeing how the stronger math muscles might develop with Python's support. I won't reiterate the details here however, as my ideas along these lines are already defined and circulating via the Internet, as part of the ongoing conversation. Kirby From urnerk at qwest.net Wed Jun 1 06:30:47 2005 From: urnerk at qwest.net (Kirby Urner) Date: Tue, 31 May 2005 21:30:47 -0700 Subject: [Edu-sig] A tale of two hand puppets Message-ID: <20050601043049.033561E400A@bag.python.org> So I have this vision of a puppet show, which I tested out on a high school computer teacher today. He said it made sense. Arm 1 (left or right, I don't care) is the traditional math arm, and its puppet tends to talk one into a precalculus course of study, culminating in calculus, then pointing off into other subjects in college, its job largely done by this point. Arm 2 is a younger CS track, likewise reaching into the K-12 classroom, but so far weaker than arm 1. The problem of what language to use has been bothersome. But as the kinks get worked out, more muscles get added and the arm grows in strength. Part of its food source is again mathematics, but in a different mix than we find in precalc/calc; more group and number theory for example. So what's happening is arm 2 is gaining in strength by leaps and bounds, and shortly what we'll see are two trajectories through the K-12 namespace that have equal legitimacy in terms of offering a strong set of mathematical concepts. The CS arm will grow from a discrete math basis, whereas arm 1 is more wired into real analysis and like that. At the end of each arm is a puppet, talking up a storm, doing a lot of interacting with the K-12 audience (teachers included). Bag puppets if you like -- I prefer something more elaborate (spoiled by Muppets I guess). The two puppets are starting to get more equal, more comparable in terms of character development and recruiting appeal. Pretty soon, kids will be seeing new career tracks, still mostly through colleges and universities, along this alternative arm 2 trajectory. That's for the better I think, as the competition and positive synergies involved will make both arms stronger in the long run ('stronger arms = a better puppet show' is how I'm structuring this analogy). The contrasts become sharper, concepts get thrown into deeper relief, clarity is added, the range of options is broadened, we accommodate more individual profiles and preferences. I feel the momentum towards something like this is pretty strong, with or without my specific input. However, I think my appreciation for Python, shared with others here on edu-sig, gives me a front row seat and at least some steering capabilities. In particular, I'm seeing how the stronger math muscles might develop with Python's support. I won't reiterate the details here however, as my ideas along these lines are already defined and circulating via the Internet, as part of the ongoing conversation. Kirby From urnerk at qwest.net Wed Jun 1 08:16:06 2005 From: urnerk at qwest.net (Kirby Urner) Date: Tue, 31 May 2005 23:16:06 -0700 Subject: [Edu-sig] Python programming challenge Message-ID: <20050601061607.9F1A01E4003@bag.python.org> Here's a good assignment for those wanting to test their Python skills: Consider the paper and pencil algorithm for finding the square root of a number as described in detail here, by means of a worked example: http://www.homeschoolmath.net/other_topics/square-root-algorithm-example.php Write a Python generator that yields one more digit of the square root of n, given n as its argument. Optionally ignore placement of any decimal points. Feel free to use more than one function, but have root2 be the top-level generator. In other words, your code might output something like this during testing: >>> r = root2(297504) >>> r.next() '5' >>> r.next() '54' >>> r.next() '545' >>> r.next() '5454' >>> r.next() '54543' >>> r.next() '545439' >>> r.next() '5454392' >>> r.next() '54543927' >>> r.next() '545439272' >>> r.next() '5454392725' And so on, indefinitely (memory a constraint). Kirby From glingl at aon.at Wed Jun 1 16:23:58 2005 From: glingl at aon.at (glingl@aon.at) Date: Wed, 01 Jun 2005 16:23:58 +0200 (MEST) Subject: [Edu-sig] Python programming challenge In-Reply-To: <20050601061607.9F1A01E4003@bag.python.org> References: <20050601061607.9F1A01E4003@bag.python.org> Message-ID: <1117635838.429dc4fe4917a@webmail.aon.at> ----- Original von: Kirby Urner : > Here's a good assignment for those wanting to test their Python skills: Consider the paper and pencil algorithm for finding the square root of a number as described in detail here, by means of a worked example: http://www.homeschoolmath.net/other_topics/square-root-algorithm-example.php Write a Python generator that yields one more digit of the square root of n, given n as its argument. Optionally ignore placement of any decimal points. ... Hi, Kirby, you expect code? Here's a first try - very conventional: def places(inp): while True: if inp: i = 2 - len(inp)%2 yield int(inp[:i]) inp = inp[i:] else: yield 0 def root2(inp): p=places(inp) num = p.next() result = 0 while True: digit = 9 helper = (20*result+digit)*digit while helper > num: digit -= 1 helper = (20*result+digit)*digit num -= helper num = num*100 + p.next() result = 10*result + digit yield result Example: >>> w = root2("3") >>> for i in range(20): print w.next() 1 17 173 1732 17320 173205 1732050 17320508 173205080 1732050807 17320508075 173205080756 1732050807568 17320508075688 173205080756887 1732050807568877 17320508075688772 173205080756887729 1732050807568877293 17320508075688772935 >>> Of course I'm interested in alternate solutions. Regards, Gregor P.S.: Hope indenting will not be destroyed by this web-mail-client I' not using normally ------------------------------------------- Versendet durch aonWebmail (webmail.aon.at) From urnerk at qwest.net Thu Jun 2 03:42:32 2005 From: urnerk at qwest.net (Kirby Urner) Date: Wed, 1 Jun 2005 18:42:32 -0700 Subject: [Edu-sig] Python programming challenge In-Reply-To: <1117635838.429dc4fe4917a@webmail.aon.at> Message-ID: <20050602014234.A70D51E4007@bag.python.org> > Of course I'm interested in alternate solutions. > > Regards, > Gregor > Mine is not especially different. I'm sure this could be streamlined. def getmaxroot(n): for i in range(9,0,-1): if i*i <= n: return i def getpairs(n): sn = str(n) if len(sn)%2: yield sn[0:1] sn = sn[1:] + '00' while True: yield sn[0:2] sn = sn[2:] + '00' def root2(n): g = getpairs(n) pair = g.next() root = getmaxroot(int(pair)) newval = int(str(int(pair)-root*root) + g.next()) ans = str(root) while True: yield ans prefix = str(2*int(ans)) for i in range(9,-1,-1): value = int(prefix + str(i)) * i if value <= newval: break ans += str(i) newval = int(str(int(newval)-value) + g.next()) Kirby From ajsiegel at optonline.net Thu Jun 2 13:50:18 2005 From: ajsiegel at optonline.net (Arthur) Date: Thu, 02 Jun 2005 07:50:18 -0400 Subject: [Edu-sig] Another loop around Message-ID: <0IHG00AS6GVYCA@mta4.srv.hcvlny.cv.net> > but I'm looping - again. Still looping. But that's probably because it's hard for me to understand how I've come to live on my own planet. For the largest majority of students - it seems clear to me - asking them to learn to program, in Python or any other language for that matter, would be the single *hardest* thing they have been asked to do in their academic careers. Many students will have graduated from the finest of universities, with impressive degrees, and have never undertaken anything as challenging. I have no problem with asking them, nonetheless, to do so. But I just can't, for the life of me, understand how we can do so without due emphasis on the effort expected, and the challenges involved. If we are concerned more about the preparation of students for the task, than our zeal for the advocacy of Python, we would take the word "Easy" absolutely off the table. Art From urnerk at qwest.net Thu Jun 2 17:21:40 2005 From: urnerk at qwest.net (Kirby Urner) Date: Thu, 2 Jun 2005 08:21:40 -0700 Subject: [Edu-sig] Another loop around In-Reply-To: <0IHG00AS6GVYCA@mta4.srv.hcvlny.cv.net> Message-ID: <20050602152140.7A3901E400A@bag.python.org> Arthur: > For the largest majority of students - it seems clear to me - asking them > to learn to program, in Python or any other language for that matter, > would be the single *hardest* thing they have been asked to do in their > academic careers. Remember our little distinction between learning to program and programming to learn. You could think of Python mastery along the lines of a martial art, with white, yellow, brown and black belts (is that how it goes?). If our goal is to offer a math track that includes use of a computer language (that's my goal anyway), then there's already a lot we might do with yellow belts. > Many students will have graduated from the finest of universities, with > impressive degrees, and have never undertaken anything as challenging. > Think of the start of Guido's tutorial: using Python as a calculator. None of this should seem difficult, even if we start using complex numbers and big precision integers and decimals. Our functions may be no more than 5-8 lines long. A lot of it is *translation* e.g. Gregor and I were just coding an age-old algorithm for finding square roots to any precision that was very well described on a web page, without any invocation of a programming language. All that remained was to get it into code. I'd say that was a yellow belt activity, one we wouldn't start out with (too hard). We were getting up to 20-30 lines. > I have no problem with asking them, nonetheless, to do so. > > But I just can't, for the life of me, understand how we can do so without > due emphasis on the effort expected, and the challenges involved. > In CS and IT and maybe some MBA tracks, plus along various private industry tracks, it'll be important to know SQL, and we might use mxODBC to send queries to backend MySQL on a Windows box or something. A thick book on Python programming is going to mention these capabilities, maybe give some examples. But if we're in Urner's math class, studying the group and number theory behind RSA, this isn't something we need to touch on. And we might spend no time whatsoever on GUI programming (not counting invocation of a VPython scene and wiring up some mouse click interactivity). > If we are concerned more about the preparation of students for the task, > than our zeal for the advocacy of Python, we would take the word "Easy" > absolutely off the table. > > Art def f(x): return x*x points = [(x, f(x)) for x in range(-10,11)] print points plot(points) Is that much harder than ordinary math? Using Python as an interactive workspace. Programming to learn. Kirby From Scott.Daniels at Acm.Org Thu Jun 2 20:44:09 2005 From: Scott.Daniels at Acm.Org (Scott David Daniels) Date: Thu, 02 Jun 2005 11:44:09 -0700 Subject: [Edu-sig] Another loop around In-Reply-To: <20050602152140.7A3901E400A@bag.python.org> References: <0IHG00AS6GVYCA@mta4.srv.hcvlny.cv.net> <20050602152140.7A3901E400A@bag.python.org> Message-ID: Kirby Urner wrote: > Arthur: >> For the largest majority of students - it seems clear to me - asking them >> to learn to program, in Python or any other language for that matter, >> would be the single *hardest* thing they have been asked to do in their >> academic careers. You (Arthur) should read Djistra's "On the Crulety of Teaching Computer Programming" (or is that Computer Science?) -- Communications of the ACM, I'm not quite sure when (I'd guess within the last five years). He essentially agrees with you as to a computer science curriculum for undergraduate majors. > ... > def f(x): > return x*x > points = [(x, f(x)) for x in range(-10,11)] > print points > plot(points) > > Is that much harder than ordinary math? Using Python as an interactive > workspace. > Programming to learn. A friend that I've helped learn to program has said that learning to program improved his ability to think about complicated things. Now this effect is an old math effect; I expect that it is much about how to think rigorously. The nicest thing about programming is that the rigor is enforced for a comprehensible reason: the machine follows your orders. Enough people get frustrated at math simply because it is far from obvious when you have enough rigor and when you don't. Math, to them, seems like a game with a few rules missing. --Scott David Daniels Scott.Daniels at Acm.Org From dr.addn at gmail.com Fri Jun 3 01:59:28 2005 From: dr.addn at gmail.com (adDoc's networker Phil) Date: Thu, 2 Jun 2005 16:59:28 -0700 Subject: [Edu-sig] Another loop around In-Reply-To: <0IHG00AS6GVYCA@mta4.srv.hcvlny.cv.net> References: <0IHG00AS6GVYCA@mta4.srv.hcvlny.cv.net> Message-ID: <8fd4a2fe05060216591a6839a4@mail.gmail.com> . seems everyone.s overlooking your message's context On 6/2/05, Arthur wrote: > > > but I'm looping - again. > > Still looping. > > But that's probably because it's hard for me to understand how I've come > to > live on my own planet. > > For the largest majority of students - it seems clear to me - asking them > to > learn to program, in Python or any other language for that matter, would > be > the single *hardest* thing they have been asked to do in their academic > careers. > . it sounds like you know that loopers own the planet! life here is about looping busy work for an excuse to keep the population bomb from making everyone equally poor . if we coud really implement cp4e, the whole planet could be totally automated before the century ends -- and the single hardest thing happens: how do you program people to program reproduction ? -- American Dream Documents "(real opportunity starts with real documentation) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20050602/7c1310d1/attachment.html From radenski at chapman.edu Fri Jun 3 03:42:34 2005 From: radenski at chapman.edu (Radenski, Atanas) Date: Thu, 2 Jun 2005 18:42:34 -0700 Subject: [Edu-sig] A case against GUIs in intro CS :-) Message-ID: > -----Original Message----- > Behalf Of Bob Noonan > The one place where Python is clearly deficient IMHO is in GUI programming. While this might be true, I do not feel it is a problem. The problem is that GUI programming is given significant coverage in most mainstream introductory CS textbooks. Open an arbitrary Java-based textbook and you are likely to face GUIs from almost the beginning. Sample programs and exercises often come with GUI shells that obscure their essential non-GUI parts. I find the dominance of GUIs in java-based introductory books troublesome. GUI programming is relatively complex. To understand it, one needs to understand event handling. I have hard time explaining event handling to beginners and see that beginners have hard time understanding it. While GUI programming is complex from beginner's perspective, it does not offer many interesting algorithmic problems. I believe that we humans are really good at linear communication. Most animals see and understand pictures. We humans have the exclusive capability of speaking and hearing *linear sequences* of sounds, while animals are not particularly good at that. We are also good in reading and writing sequences of characters while no known animals can do that. Some folks say that a picture can easily show what a thousand words cannot. Well, there is nothing you cannot express with words, but there are many things that you cannot express, at least not easily, with pictures. You do not need to try translating Shakespeare into pictures to see how hard that would be, just try writing technical emails in this list using pictures. My point is that GUI should not be overweighed in intro CS courses. GUIs have some place, but certainly not central place in such courses. Python's interactive mode, without GUIs, is great way to teach introductory level programming. Therefore, a possible Python deficiency in the GUI area should not be considered a problem at all. I apologize for this non-technical message. I was tempted to write it because I have struggled way too much teaching too much GUI programming in intro level CS courses. Atanas Atanas Radenski mailto:radenski at chapman.edu http://www.chapman.edu/~radenski/ From john.zelle at wartburg.edu Fri Jun 3 04:21:43 2005 From: john.zelle at wartburg.edu (John Zelle) Date: Thu, 02 Jun 2005 21:21:43 -0500 Subject: [Edu-sig] Edu-sig Digest, Vol 22, Issue 26 In-Reply-To: <200505310906.46647.noonan@cs.wm.edu> References: <200505310906.46647.noonan@cs.wm.edu> Message-ID: <429FBEB7.4070903@wartburg.edu> I know there've already been a couple responses on this. I've been meaning to reply, but been preoccupied. But I found this post very interesting, and am wondering if more discussion might be in order. Bob Noonan wrote: > Toby Donaldsoon writes: > > >>I've been involved with teaching CS1/CS2 style courses for the last couple >>of years where Python is used in the first course, and Java in the second. >>It's a good combination. > > >>Simple Python programs are usually much easier to read and simpler to write >>than simple Java programs, and so students new to programming really like >>it. > > > I would love to switch our CS1 course to Python. It seems like I am always > about 5-8 years ahead of my department. After starting in 1997, it took me > until 2003 to get our CS1 course switched from C++ to Java. > > At the time we did it, I knew Python was a better choice, precisely because: > > 1. It is a good scripting language. > > 2. 50% of our CS1 students never take another CS course; clearly, these > students are better off with Python than with Java. > > The one place where Python is clearly deficient IMHO is in GUI programming. > Tkinter (and the TK toolkit) are nowhere near the quality and simplicity of > Swing. Pack as a layout manager is difficult, at best. And yes, I am aware > of other GUI interfaces such as wxPython, but the infrastructure is not there > to support them. All of the Python textbooks that I am familiar with cover > only Tkinter. > I realize that GUI toolkits are probably more a matter of taste and experience more than any other component of development. But, I wonder if you could explain to me in what ways you see Swing as simpler than TKinter? Tkinter is by far the simplest GUI toolkit I've ever worked with (including: Xlib, Tkinter, Swing, Java AWT, GTK, wxPython, and Qt). You can get everything you need to know to start working with Tk in about a 25 page summary. Swing requires a couple hundred pages minimum in my experience. I've given software engineering classes a quick rundown on Tk in one or two lectures and then let them go their own way. In Swing, I taught a 1.5 credit hour class over an entire semester, and they still didn't really get to the point of being able to write interesting programs. In terms of quality, TK does have some deficiencies (limited widget set, somewhat old-fashioned look and quirky behavior across patforms). As such, I consider Tkinter a great tool for easy prototyping, but not necessarily so good for finished products. On the other hand, it has been used for some very impressive apps. I would not consider the packer to be a deficiency. In TK, you can learn this one (relatively) simple geometry manager and do pretty much anything you want. In Swing, you have to learn a bunch of layout managers to do anything remotely sophisticated, and if you're talking difficult, the Swing gridbag is far more unwieldly than the Tk packer. Plus, Tk also offers the gridder and placer geometry managers, if you really want something other than packer. I know I am not alone in feeling that Swing is one place where Java has really failed miserably. It is a complex, bloated framework that (often) produces slow, cumbersome, memory intensive, and ugly interfaces (can you get anti-aliased fonts in swing?). IBM ditched Swing and built it's own toolkit for developing Eclipse. I suspect more and more developers will look that direction. The absolute beauty of Python is the "embarrassment of riches" when it comes to high-quality GUI toolkits. Whatever style framework you like, you can use it in Python. As someone already mentioned, if you like Swing, then use it in Python through Jython (that's about the only way I can tolerate Swing, myself). Tkinter is a great choice for simple GUIs and learning basic GUI principles. Wx offers a nice cross platform solution that is extremely well supported for Python. Lots of folks swear by GTK and Glade. I am personally very impressed with PyQt, and think it is well worth a look if you want to do industrial-strength GUIs with a modern, well-deisgned, cross-platform framework. There's at least one book covering Python with QT, and it's very easy to translate the excellent C++ documentation directly into working Python code. In summary, Python seems a much more GUI-friendly language than Java, so I don't think that should stand in the way of its use in intro programming classes. If I had to teach GUIs early on, I would definitely choose Tkinter over Swing. Of course, whether GUI programming is an important topic for intro classes is a whole different matter... -- John M. Zelle, Ph.D. Wartburg College Professor of Computer Science Waverly, IA john.zelle at wartburg.edu (319) 352-8360 From ajsiegel at optonline.net Fri Jun 3 05:28:58 2005 From: ajsiegel at optonline.net (Arthur) Date: Thu, 02 Jun 2005 23:28:58 -0400 Subject: [Edu-sig] A case against GUIs in intro CS :-) In-Reply-To: Message-ID: <0IHH00B20OCJNH@mta5.srv.hcvlny.cv.net> > -----Original Message----- > From: edu-sig-bounces at python.org [mailto:edu-sig-bounces at python.org] On > Behalf Of Radenski, Atanas > Sent: Thursday, June 02, 2005 9:43 PM > To: Bob Noonan; edu-sig at python.org > Subject: [Edu-sig] A case against GUIs in intro CS :-) > > > > -----Original Message----- > > Behalf Of Bob Noonan > > > The one place where Python is clearly deficient IMHO is in GUI > programming. > > While this might be true, I do not feel it is a problem. The problem is > that GUI programming is given significant coverage in most mainstream > introductory CS textbooks. FWIW, the text I am currently working with/from - "Practical Common Lisp" - does not as yet (Chapter 8) touch GUI programming, and I am not expecting that it will at all. I think, BTW, it is an excellent effort, with an excellent pedagogical approach. Chapter 1 is purely introductory salesmanship "Why Lisp", within the expectations of what might find in a book devoted to that subject. Chapter 2 is the "Hello World" stuff from the interactive prompt. And I am afraid I am embarking on the typical linear "building-block" approach, which will force me (being who I am) to be skipping ahead chapters to see where we are going, in order to make an assessment as to whether we are going to an interesting enough place for me to hang with the building of the blocks. But Chapter 3 is unexpected - it takes us through creating a simple but functional database, with persistency, "select" and "update" and "delete" calls with fairly standard database syntax, and through it we get a taste of function passing, and macro writing, until it's all refactored down to maybe 35 lines of code that I actually feel I understand. And I would certainly not see a non-Lisp way of writing it as efficiently. So by Chapter 3 the author has made good on some of the claims of Chapter 1. And I no longer feel I need to skip ahead to anything. I'm sold on the effort, and willing to bear some of the drudgery that necessarily follows when we do back up a bit and start filling in some of the details of syntax and semantics. (some of it quite ugly when one is used to Python) The author communicates respect for his audience. He says things once. Even hard things. It doesn't mean he expects me to get it on reading it once, but we understand each other I think - there is nothing stopping me from reading it five or six times if I need to. Him repeating himself is not going to help - because he has already said it the best way he could find to say it. Saying it a second time, he could only be saying it a second best way. Nice job Mr. Seibel. Back to the point - I would find GUI issues mostly a distraction, and don't regret at all that it is not being covered. GUI building seems to be dominated by tools. Couldn't the argument might be made that GUI building can only really be taught in the context of a specific development environment, rather than in the abstract. Python has many such environments. Lisp has Allegro Lisp which is an almost VB like environment. If GUI building in Lisp ever became a practical issue for me (I don't expect it will), I would probably cop out by becoming comfortable with the Allegro environment. Art From ajsiegel at optonline.net Fri Jun 3 05:42:36 2005 From: ajsiegel at optonline.net (Arthur) Date: Thu, 02 Jun 2005 23:42:36 -0400 Subject: [Edu-sig] A case against GUIs in intro CS :-) In-Reply-To: <0IHH00B20OCJNH@mta5.srv.hcvlny.cv.net> Message-ID: <0IHH00G9TOZ6Y0@mta5.srv.hcvlny.cv.net> > -----Original Message----- > From: edu-sig-bounces at python.org [mailto:edu-sig-bounces at python.org] On > Behalf Of Arthur > > > -----Original Message----- > > From: edu-sig-bounces at python.org [mailto:edu-sig-bounces at python.org] On > > Behalf Of Radenski, Atanas > > > -----Original Message----- > > > Behalf Of Bob Noonan > > > > > The one place where Python is clearly deficient IMHO is in GUI > > programming. > > > > While this might be true, I do not feel it is a problem. The problem is > > that GUI programming is given significant coverage in most mainstream > > introductory CS textbooks. > > FWIW, the text I am currently working with/from - "Practical Common Lisp" > does not as yet (Chapter 8) touch GUI programming, and I am not expecting > that it will at all. There is also, BTW, embedded respect for Python within the text. It does not mean to be a text introductory to programming. And sometimes points are made by comparing Lisp features to similar or analogous one's of other programming languages, often in footnotes. And in all cases when doing so, Python is included among the languages (usually with Java and Perl) that are being discussed. I think that's a pretty impressive testimony in itself to Python's current place in the universe. Art > > I think, BTW, it is an excellent effort, with an excellent pedagogical > approach. > > Chapter 1 is purely introductory salesmanship "Why Lisp", within the > expectations of what might find in a book devoted to that subject. > > Chapter 2 is the "Hello World" stuff from the interactive prompt. > > And I am afraid I am embarking on the typical linear "building-block" > approach, which will force me (being who I am) to be skipping ahead > chapters > to see where we are going, in order to make an assessment as to whether we > are going to an interesting enough place for me to hang with the building > of > the blocks. > > But Chapter 3 is unexpected - it takes us through creating a simple but > functional database, with persistency, "select" and "update" and "delete" > calls with fairly standard database syntax, and through it we get a taste > of > function passing, and macro writing, until it's all refactored down to > maybe > 35 lines of code that I actually feel I understand. And I would certainly > not see a non-Lisp way of writing it as efficiently. So by Chapter 3 the > author has made good on some of the claims of Chapter 1. > > And I no longer feel I need to skip ahead to anything. I'm sold on the > effort, and willing to bear some of the drudgery that necessarily follows > when we do back up a bit and start filling in some of the details of > syntax > and semantics. (some of it quite ugly when one is used to Python) > > The author communicates respect for his audience. He says things once. > Even hard things. It doesn't mean he expects me to get it on reading it > once, but we understand each other I think - there is nothing stopping me > from reading it five or six times if I need to. Him repeating himself is > not going to help - because he has already said it the best way he could > find to say it. Saying it a second time, he could only be saying it a > second best way. > > Nice job Mr. Seibel. > > Back to the point - I would find GUI issues mostly a distraction, and > don't > regret at all that it is not being covered. > > GUI building seems to be dominated by tools. Couldn't the argument might > be > made that GUI building can only really be taught in the context of a > specific development environment, rather than in the abstract. > > Python has many such environments. > > Lisp has Allegro Lisp which is an almost VB like environment. If GUI > building in Lisp ever became a practical issue for me (I don't expect it > will), I would probably cop out by becoming comfortable with the Allegro > environment. > > Art > > > > > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig From chuck at freshsources.com Fri Jun 3 08:36:08 2005 From: chuck at freshsources.com (Chuck Allison) Date: Fri, 3 Jun 2005 00:36:08 -0600 Subject: [Edu-sig] A case against GUIs in intro CS :-) In-Reply-To: References: Message-ID: <1496555689.20050603003608@freshsources.com> Hello Atanas, I agree with this post 100%. GUIs require a fairly good understanding of event loops and OOP. They confuse beginners who have to look at the code as well as the pictures. They are, however, a good example of quality OO design, once the students have a little experience. Thursday, June 2, 2005, 7:42:34 PM, you wrote: >> -----Original Message----- >> Behalf Of Bob Noonan >> The one place where Python is clearly deficient IMHO is in GUI RA> programming. RA> While this might be true, I do not feel it is a problem. The problem is RA> that GUI programming is given significant coverage in most mainstream RA> introductory CS textbooks. Open an arbitrary Java-based textbook and you RA> are likely to face GUIs from almost the beginning. Sample programs and RA> exercises often come with GUI shells that obscure their essential RA> non-GUI parts. I find the dominance of GUIs in java-based introductory RA> books troublesome. RA> GUI programming is relatively complex. To understand it, one needs to RA> understand event handling. I have hard time explaining event handling to RA> beginners and see that beginners have hard time understanding it. While RA> GUI programming is complex from beginner's perspective, it does not RA> offer many interesting algorithmic problems. RA> I believe that we humans are really good at linear communication. Most RA> animals see and understand pictures. We humans have the exclusive RA> capability of speaking and hearing *linear sequences* of sounds, while RA> animals are not particularly good at that. We are also good in reading RA> and writing sequences of characters while no known animals can do that. RA> Some folks say that a picture can easily show what a thousand words RA> cannot. Well, there is nothing you cannot express with words, but there RA> are many things that you cannot express, at least not easily, with RA> pictures. You do not need to try translating Shakespeare into pictures RA> to see how hard that would be, just try writing technical emails in this RA> list using pictures. RA> My point is that GUI should not be overweighed in intro CS courses. GUIs RA> have some place, but certainly not central place in such courses. RA> Python's interactive mode, without GUIs, is great way to teach RA> introductory level programming. Therefore, a possible Python deficiency RA> in the GUI area should not be considered a problem at all. RA> I apologize for this non-technical message. I was tempted to write it RA> because I have struggled way too much teaching too much GUI programming RA> in intro level CS courses. RA> Atanas RA> Atanas Radenski RA> mailto:radenski at chapman.edu http://www.chapman.edu/~radenski/ RA> _______________________________________________ RA> Edu-sig mailing list RA> Edu-sig at python.org RA> http://mail.python.org/mailman/listinfo/edu-sig -- Best regards, Chuck From tjd at sfu.ca Fri Jun 3 10:59:01 2005 From: tjd at sfu.ca (Toby Donaldson) Date: Fri, 03 Jun 2005 01:59:01 -0700 Subject: [Edu-sig] A case against GUIs in intro CS :-) In-Reply-To: References: Message-ID: <42A01BD5.2020109@sfu.ca> > The problem is that GUI programming is given significant coverage in > most mainstream introductory CS textbooks. Open an arbitrary Java-based > textbook and you are likely to face GUIs from almost the beginning. > Sample programs and exercises often come with GUI shells that obscure > their essential non-GUI parts. I find the dominance of GUIs in java-based > introductory books troublesome. I agree that the overhead of writing hand-made Swing GUIs can be overwhelming, and that beginners should instead focus on clear and simple expression of algorithms and ideas. I too have struggled with Java and Swing, and have pretty much just given up on it and told students the bare minimum of what they need to know to get things going, with the promise that the underyling details of how it all works will be revealed in later CS courses. I have not yet decided if this encourages or discourages students from taking more CS courses. :-) When I taught VB (Visual BASIC), however, the GUIs were great, and students almost universally said the course was more interesting and enjoyable because of them. In part, they liked the fact that their programs looked like real programs, and that there was some room for creativity in how they organized their interfaces. Student were often driven to do extra programming by a desire to add or fix features they had seen in programs. I liked the fact that there was a very clear design phase where you had to sketch out the interface. Talking about the interfaces was a good way to talk about the program without talking about the source code. This helped students organize their source code, and to see first-hand the benefits of modularity, i.e. they were always writing the code for widgets in specially-named functions. Also, GUI widgets roughly correspond to programming concepts, when deciding if you want to use a text book or a list (say), you are indirectly deciding which data structure you want to use. Some students said they thought that learning VB first made it easier to understand Java-like OO GUI models. So far, in our Python courses, we haven't gotten around to any GUI programming, although its on the books to be included. Of course, VB is an integrated tool for GUI development, so you can't fairly compare it to the process of making hand-made Swing GUIs. As much as I like Python and dislike the BASIC part of VB, I do have to admit that my experiences with VB were probably the best I ever had teaching introductory programming (although it wasn't quite a CS1 course, just a humble introduction to "event-driven" programming). Toby From shannon at centre.edu Fri Jun 3 14:54:37 2005 From: shannon at centre.edu (Christine A. Shannon) Date: Fri, 3 Jun 2005 08:54:37 -0400 Subject: [Edu-sig] python for CS I Message-ID: <0D6F3677FF3C0045BBEE54DB65C4EE4D016AD222@exchange.centre.edu> I thought I might add a few comments since we at Centre College have been teaching Python in CS I for a long time. We use Java in CS II but I often let students use Python in subsequent courses for assignments in everything from algorithms to operating systems to AI. I have a research project going on this summer using the pyro robotics project materials which uses Python. I teach CS II and only once has a student complained about not learning Java from the beginning. I taught the course for the first time this spring using John Zelle's book. No one in the course was a major or minor -- everyone was taking it for a general ed or because it was required on their major (generally math or physics). I'm willing to admit that this class was not typical (many were upper classmen) but it was successful beyond my usual hopes. This is a typical comment from the student evaluations: "I thoroughly enjoyed this course, even though I was only taking it for gen ed requirement. I was able to gain many skills that will help me in the future and will add to my ability to think critically and decipher problems quickly and logically." Another wrote: "I was very surprised how much I enjoyed this class, especially the graphics labs and projects. I only took this class because it was a requirement for my major, but I would say that it was by far my favorite class this semester. It is nice having a class where the subject matter is applicable in the real world and you can see tangible results." We did do quite a bit of graphics programming using the graphics package in Zelle's book. It was easy to use and the students took on projects that were really very challenging. One wrote a very nice minesweeper program. This past week, long after grades were submitted, I got a revision of an Othello game that a student attempted. It still needs work but the fact that this course captured the imagination of a student and encouraged him to keep working on a project well into the summer speaks volumes both about our students and about the value of Python for the intro course. There are definitely things about Python that I don't like, but I find it very conducive for getting students to start programming meaningful projects in a hurry. Please contact me directly if you have additional questions about our course. Christine Shannon Margaret V. Haggin Professor of Mathematics and Computer Science Centre College 600 W. Walnut Danville, KY 40422 859 238 5406 From jeff at elkner.net Fri Jun 3 15:08:29 2005 From: jeff at elkner.net (Jeffrey Elkner) Date: Fri, 03 Jun 2005 09:08:29 -0400 Subject: [Edu-sig] A case against GUIs in intro CS :-) In-Reply-To: <42A01BD5.2020109@sfu.ca> References: <42A01BD5.2020109@sfu.ca> Message-ID: <1117804109.13367.32.camel@mdeicaza> On Fri, 2005-06-03 at 01:59 -0700, Toby Donaldson wrote: > When I taught VB (Visual BASIC), however, the GUIs were great, and > students almost universally said the course was more interesting and > enjoyable because of them. In part, they liked the fact that their > programs looked like real programs, and that there was some room for > creativity in how they organized their interfaces. Student were often > driven to do extra programming by a desire to add or fix features they > had seen in programs. I liked the fact that there was a very clear > design phase where you had to sketch out the interface. Talking about > the interfaces was a good way to talk about the program without > talking about the source code. This helped students organize their > source code, and to see first-hand the benefits of modularity, i.e. > they were always writing the code for widgets in specially-named > functions. Also, GUI widgets roughly correspond to programming > concepts, when deciding if you want to use a text book or a list > (say), you are indirectly deciding which data s! > tructure you want to use. Some students said they thought that > learning VB first made it easier to understand Java-like OO GUI > models. Toby, check out pythoncard (http://pythoncard.sourceforge.net/). I have a student this year, Daniel Caughran, who used it for his science fair project, and he compares the experience favorably to using VB (with which he is familiar). He was able to put together a very useful GUI program with a minimum of effort. Version 1.0 will be out soon. It looks like teachers using Python can now offer their students the advantages of VB without the disadvantages. > As much as I like Python and dislike the BASIC part of VB, I do have > to admit that my experiences with VB were probably the best I ever had > teaching introductory programming (although it wasn't quite a CS1 > course, just a humble introduction to "event-driven" programming). I "taught" VB for a year, and was amazed to find out that I made it through the entire year without either myself or my students (naturally) learning much of anything about programming. To be fair, that is not the fault of the tool itself (though the tool did contribute to the problem), but rather the fault of the approach used to teaching it (it was my fault, in other words, but let me explain ;-). We used a Shelly Cashman book as the textbook for the course (I had nothing to do with choosing it). These books seem to be popular with some folks inside the school system because they keep students busy (and thus, the reasoning goes, out of trouble). They also teach students almost nothing. Long, complex procedures are illustrated step-by-step, with screen shots showing exactly what the screen should look like at each stage. Students are able to follow the instructions step-by-step to achieve the desired result (thus they are kept busy), but the focus is almost exclusively on the environment and the procedures are way to complex for students to be able to extrapolate much of use from the experience. It is my hope that the grass roots nature of the Python community will prevent this same kind of thing from happening with our teaching materials, particularly as more and more people are using Python. The eclectic, cross platform, multi-environment nature of Python programming will make it difficult for a Shelly Cashman type book to be written. Or at least we can hope... -- Jeffrey Elkner Open Book Project From ajsiegel at optonline.net Fri Jun 3 15:00:17 2005 From: ajsiegel at optonline.net (Arthur) Date: Fri, 03 Jun 2005 09:00:17 -0400 Subject: [Edu-sig] A case against GUIs in intro CS :-) In-Reply-To: Message-ID: <0IHI008B2ERGIF@mta3.srv.hcvlny.cv.net> > Behalf Of Radenski, Atanas > > Behalf Of Bob Noonan > > GUI programming is relatively complex. To understand it, one needs to > understand event handling. I have hard time explaining event handling to > beginners and see that beginners have hard time understanding it. While > GUI programming is complex from beginner's perspective, it does not > offer many interesting algorithmic problems. Right. After hearing people discussing closures and not closures for some time, and not needing to understand the concept, and therefore not understanding the concept, I ran into a concrete GUI problem (in tkinter as it happens) and a little googling helped me find some information posted up by Scott David Daniels that addressed my concrete problem and did so via an implementation and explanation of the closure concept. > I believe that we humans are really good at linear communication. Most > animals see and understand pictures. We humans have the exclusive > capability of speaking and hearing *linear sequences* of sounds, while > animals are not particularly good at that. We are also good in reading > and writing sequences of characters while no known animals can do that. A bit OT perhaps but I do wish pedagogical approaches had more respect and insight into our non-linear nature, especially when it comes to the learning process. I just don't remember any coursework where we said, "now having gotten through Chapter 8, we are going to circle back around to Chapter 3 and 4 again and redo it, and we will get things from it - with Chapters 5-8 under our belt - that we undoubtedly missed the first time around. Left to my own resources, this is exactly how I approach and successfully learn subjects like math and programming - absolutely consistently. Kirby mentions the Guido tutorial in a recent post. Its not like I worked it once and left it behind. I did a once over lightly, and then probably iterated over at least portions of it 7 or 8 different times, at different points of my early process, each time getting different things from it. I'm sure if I did it today, I would still learn something new from it. The Internet, with Google and the like, is a great non-linear resource. The beauty of it being that nobody really designed it as such. It sort of happened. Left untouched it is a great learning environment. When we intercede to create a more ordered learning environment, it seems to me that we are always tending to linearize it somehow, and therefore reducing it from what it already is. What we need to do to turn the Internet into a learning environment is pretty much nothing. Activists (and business folk) seemed to have a problem with that approach. I am only a modified Luddite. Art From chuck at freshsources.com Fri Jun 3 20:00:23 2005 From: chuck at freshsources.com (Chuck Allison) Date: Fri, 3 Jun 2005 12:00:23 -0600 Subject: [Edu-sig] A case against GUIs in intro CS :-) In-Reply-To: <1117804109.13367.32.camel@mdeicaza> References: <42A01BD5.2020109@sfu.ca> <1117804109.13367.32.camel@mdeicaza> Message-ID: <1772050583.20050603120023@freshsources.com> Hello Jeffrey, Friday, June 3, 2005, 7:08:29 AM, you wrote: JE> I "taught" VB for a year, and was amazed to find out that I made it JE> through the entire year without either myself or my students (naturally) JE> learning much of anything about programming. To be fair, that is not JE> the fault of the tool itself (though the tool did contribute to the JE> problem), but rather the fault of the approach used to teaching it (it JE> was my fault, in other words, but let me explain ;-). This is a major issue in software development. Much has been said about "90-day wonders" during the dot-com boom, who learned a little VB, enough to drag-and-drop their way into a "job". The ranks of these people have a lot to do with the sad state of software quality (there is a lot of research on this actually - it's called "The Battle of the Exponents" - the number of VB coders exceeds our ability to train them properly, and we're losing this battle). I think VB is the absolute worst way to introduce programming, and emphasizing GUI in a first exposure to computing is a mistake. Event-driven programming is a narrow, over-emphasized slice of the software experience, and is particular damaging to start a CS major off that way. I think there is more than just a little deception in luring people into CS with a visual approach, just to have them fail later on because they didn't know what CS was really about. If you want to do that with IS majors, go ahead, but not CS majors. It's just plain evil. I think Python can fix a lot of this. I've actually been "concerned" that if we switch to Python, they'll learn CS concepts too quickly, and we'll run out of things to do in four years :-). -- Best regards, Chuck From Scott.Daniels at Acm.Org Fri Jun 3 21:21:39 2005 From: Scott.Daniels at Acm.Org (Scott David Daniels) Date: Fri, 03 Jun 2005 12:21:39 -0700 Subject: [Edu-sig] A case against GUIs in intro CS :-) In-Reply-To: <0IHH00B20OCJNH@mta5.srv.hcvlny.cv.net> References: <0IHH00B20OCJNH@mta5.srv.hcvlny.cv.net> Message-ID: Arthur wrote: > The author communicates respect for his audience. He says things once. > Even hard things. It doesn't mean he expects me to get it on reading it > once, but we understand each other I think - there is nothing stopping me > from reading it five or six times if I need to. Him repeating himself is > not going to help - because he has already said it the best way he could > find to say it. Saying it a second time, he could only be saying it a > second best way. Some day when you are feeling ambitious, take a gander at Knuth's "The Art of Computer Programming." Reading Knuth is hard; he writes well but succinctly. A twenty-page assignment is a huge chunk of text. But none of is wrong, or hand-holding, or repetitious. The one thing you might not expect is that the answers to exercises sections includes ideas only mentioned in that section. I think of reading TAOCP as reading poetry; you read a bit, reflect a lot, and then read a bit more. --Scott David Daniels Scott.Daniels at Acm.Org From tjd at sfu.ca Fri Jun 3 21:43:33 2005 From: tjd at sfu.ca (Toby Donaldson) Date: Fri, 03 Jun 2005 12:43:33 -0700 Subject: [Edu-sig] A case against GUIs in intro CS :-) In-Reply-To: <1117804109.13367.32.camel@mdeicaza> References: <42A01BD5.2020109@sfu.ca> <1117804109.13367.32.camel@mdeicaza> Message-ID: <42A0B2E5.9000609@sfu.ca> Jeffrey Elkner wrote: >On Fri, 2005-06-03 at 01:59 -0700, Toby Donaldson wrote: > > >>When I taught VB (Visual BASIC), however, the GUIs were great, and >>students almost universally said the course was more interesting and >>enjoyable because of them. In part, they liked the fact that their >>programs looked like real programs, and that there was some room for >>creativity in how they organized their interfaces. Student were often >>driven to do extra programming by a desire to add or fix features they >>had seen in programs. I liked the fact that there was a very clear >>design phase where you had to sketch out the interface. Talking about >>the interfaces was a good way to talk about the program without >>talking about the source code. This helped students organize their >>source code, and to see first-hand the benefits of modularity, i.e. >>they were always writing the code for widgets in specially-named >>functions. Also, GUI widgets roughly correspond to programming >>concepts, when deciding if you want to use a text book or a list >>(say), you are indirectly deciding which data s! >> tructure you want to use. Some students said they thought that >>learning VB first made it easier to understand Java-like OO GUI >>models. >> >> > >Toby, check out pythoncard (http://pythoncard.sourceforge.net/). I have >a student this year, Daniel Caughran, who used it for his science fair >project, and he compares the experience favorably to using VB (with >which he is familiar). He was able to put together a very useful GUI >program with a minimum of effort. Version 1.0 will be out soon. It >looks like teachers using Python can now offer their students the >advantages of VB without the disadvantages. > > Thanks, will do. > > >>As much as I like Python and dislike the BASIC part of VB, I do have >>to admit that my experiences with VB were probably the best I ever had >>teaching introductory programming (although it wasn't quite a CS1 >>course, just a humble introduction to "event-driven" programming). >> >> > >I "taught" VB for a year, and was amazed to find out that I made it >through the entire year without either myself or my students (naturally) >learning much of anything about programming. To be fair, that is not >the fault of the tool itself (though the tool did contribute to the >problem), but rather the fault of the approach used to teaching it (it >was my fault, in other words, but let me explain ;-). > >We used a Shelly Cashman book as the textbook for the course (I had >nothing to do with choosing it). These books seem to be popular with >some folks inside the school system because they keep students busy (and >thus, the reasoning goes, out of trouble). They also teach students >almost nothing. Long, complex procedures are illustrated step-by-step, >with screen shots showing exactly what the screen should look like at >each stage. Students are able to follow the instructions step-by-step >to achieve the desired result (thus they are kept busy), but the focus >is almost exclusively on the environment and the procedures are way to >complex for students to be able to extrapolate much of use from the >experience. > > This is a good point ... I recall that many of the VB textbooks I looked at step-by-step procedures (with screenshots for every step) that guided the students through the creation of a program. It seems like a reasonable way to teach programming to beginners, although, as you say, if it is just about the mechanics of coding then it's nothing more than a VB package training course. Which is fine if you never use anything but VB, and never need to do anything too advanced. I recall that the VB text I was using had a very elegant and sophisticated implementation of mergesort --- more elegant than the implementation given in the data structures and algorithms textbook I was using at the same time for a CS2 course. I suppose that's because CS courses are not really about programming, but about the underlying ideas and concepts. Implementation is sometimes treated as a necessary evil. I am surprised how frequently I hear CS people talk about their dislike of programming. >It is my hope that the grass roots nature of the Python community will >prevent this same kind of thing from happening with our teaching >materials, particularly as more and more people are using Python. The >eclectic, cross platform, multi-environment nature of Python programming >will make it difficult for a Shelly Cashman type book to be written. Or >at least we can hope... > Toby From nico at tekNico.net Fri Jun 3 23:50:18 2005 From: nico at tekNico.net (Nicola Larosa) Date: Fri, 03 Jun 2005 23:50:18 +0200 Subject: [Edu-sig] A case against GUIs in intro CS :-) In-Reply-To: <1772050583.20050603120023@freshsources.com> References: <42A01BD5.2020109@sfu.ca> <1117804109.13367.32.camel@mdeicaza> <1772050583.20050603120023@freshsources.com> Message-ID: <42A0D09A.8030005@tekNico.net> > Event-driven programming is a narrow, over-emphasized slice of the > software experience, No, this is going too far. Event-driven, asynchronous programming is not limited to GUIs: it is instead a powerful, if a little invasive ;-) , concurrency model. Anyone who "got" Twisted ( http://twistedmatrix.com/ ) will never program the same way again. Drop those threads for good! > and is particular damaging to start a CS major off that way. Concurrency is hard. What is damaging is the current preponderance of the broken threading model, so frequent in the Windows and Java worlds. A balanced presentation of the pro and cons of the different concurrency models - process-based, thread based and event-based - should be included in every intermediate level programming course. Not introductory stuff, for sure, but education nonetheless. :-) -- Nicola Larosa - nico at tekNico.net The computer, especially connected to the Internet, is the paradigm power tool of our age. The sin would be to bring up a generation of passive consumers who complain and whine because "it won't do what I want." The mark of a successful civilization is it gives its people power over its most powerful tools, and not vice versa. -- Kirby Urner, April 2005 From nico at tekNico.net Fri Jun 3 23:50:18 2005 From: nico at tekNico.net (Nicola Larosa) Date: Fri, 03 Jun 2005 23:50:18 +0200 Subject: [Edu-sig] A case against GUIs in intro CS :-) In-Reply-To: <1772050583.20050603120023@freshsources.com> References: <42A01BD5.2020109@sfu.ca> <1117804109.13367.32.camel@mdeicaza> <1772050583.20050603120023@freshsources.com> Message-ID: <42A0D09A.8030005@tekNico.net> > Event-driven programming is a narrow, over-emphasized slice of the > software experience, No, this is going too far. Event-driven, asynchronous programming is not limited to GUIs: it is instead a powerful, if a little invasive ;-) , concurrency model. Anyone who "got" Twisted ( http://twistedmatrix.com/ ) will never program the same way again. Drop those threads for good! > and is particular damaging to start a CS major off that way. Concurrency is hard. What is damaging is the current preponderance of the broken threading model, so frequent in the Windows and Java worlds. A balanced presentation of the pro and cons of the different concurrency models - process-based, thread based and event-based - should be included in every intermediate level programming course. Not introductory stuff, for sure, but education nonetheless. :-) -- Nicola Larosa - nico at tekNico.net The computer, especially connected to the Internet, is the paradigm power tool of our age. The sin would be to bring up a generation of passive consumers who complain and whine because "it won't do what I want." The mark of a successful civilization is it gives its people power over its most powerful tools, and not vice versa. -- Kirby Urner, April 2005 From tjd at sfu.ca Sat Jun 4 09:50:30 2005 From: tjd at sfu.ca (Toby Donaldson) Date: Sat, 04 Jun 2005 00:50:30 -0700 Subject: [Edu-sig] A case against GUIs in intro CS :-) In-Reply-To: <1772050583.20050603120023@freshsources.com> Message-ID: On 6/3/05 11:00 AM, "Chuck Allison" wrote: > I think VB is the absolute > worst way to introduce programming, Worse than COBOL? Or the C pre-processor? :-) > and emphasizing GUI in a first exposure to computing is a mistake. My feeling is that it was not so much GUI-first as design-first that made the VB course I taught so interesting. By drawing a GUI first, you are doing some design, and even making decisions about certain variables and data structures. Your goal is clear: you want to write a program that implements the GUI. And it's not just the visuals that students would work out before writing code, but they also thought about the interaction, and how the interface should behave. It makes programming very goal-oriented. > Event-driven programming is a > narrow, over-emphasized slice of the software experience, and is > particular damaging to start a CS major off that way. I think there is > more than just a little deception in luring people into CS with a > visual approach, just to have them fail later on because they didn't > know what CS was really about. I more commonly hear students complain that CS doesn't do a good job of preparing them for a career in software engineering. That it is too focused on esoteric theory, and that too many (university) faculty hold their noses when writing programs. > If you want to do that with IS majors, go ahead, but not CS majors. It's just > plain evil. I think many CS students would benefit from treating programming as a goal-oriented design activity. In any event, I don't think my school teaches VB any more --- and it was never a course for majors. > I think Python can fix a lot of this. I've actually been "concerned" > that if we switch to Python, they'll learn CS concepts too quickly, > and we'll run out of things to do in four years :-). Toby -- Dr. Toby Donaldson School of Computing Science Simon Fraser University From tjd at sfu.ca Sat Jun 4 09:53:10 2005 From: tjd at sfu.ca (Toby Donaldson) Date: Sat, 04 Jun 2005 00:53:10 -0700 Subject: [Edu-sig] A case against GUIs in intro CS :-) In-Reply-To: <42A0D09A.8030005@tekNico.net> Message-ID: On 6/3/05 2:50 PM, "Nicola Larosa" wrote: >> Event-driven programming is a narrow, over-emphasized slice of the >> software experience, > > No, this is going too far. Event-driven, asynchronous programming is not > limited to GUIs: it is instead a powerful, if a little invasive ;-) , > concurrency model. Anyone who "got" Twisted ( http://twistedmatrix.com/ ) > will never program the same way again. Drop those threads for good! Another nice example of event-driven programming is parsing. Some (simple) parsing problems can be nicely implemented in an object-oriented, event-driven way. Toby -- Dr. Toby Donaldson School of Computing Science Simon Fraser University From ajsiegel at optonline.net Sat Jun 4 14:06:34 2005 From: ajsiegel at optonline.net (Arthur) Date: Sat, 04 Jun 2005 08:06:34 -0400 Subject: [Edu-sig] A case against GUIs in intro CS :-) In-Reply-To: Message-ID: <0IHK00HR46WX8B@mta8.srv.hcvlny.cv.net> > Behalf Of Toby Donaldson > To: Chuck Allison; Jeffrey Elkner > I more commonly hear students complain that CS doesn't do a good job of > preparing them for a career in software engineering. That it is too > focused > on esoteric theory, and that too many (university) faculty hold their > noses > when writing programs. Question. I don't remember SQL and database ever coming up here. It is the only the combination of skills I developed in learning Python and in learning SQL and database design that has allowed me to become useful in the real world - in the making $ sense of the word. Luckily I find database stuff interesting enough, and SQL powerful enough in the context of database, that I have been able to throw myself into the effort to get my arms around these technologies. And they seem to be very core skills for making one's way in the world as a developer. Where does it fit into the CS curriculum? Art From Scott.Daniels at Acm.Org Sat Jun 4 19:29:02 2005 From: Scott.Daniels at Acm.Org (Scott David Daniels) Date: Sat, 04 Jun 2005 10:29:02 -0700 Subject: [Edu-sig] A case against GUIs in intro CS :-) In-Reply-To: <0IHK00HR46WX8B@mta8.srv.hcvlny.cv.net> References: <0IHK00HR46WX8B@mta8.srv.hcvlny.cv.net> Message-ID: Arthur wrote: > I don't remember SQL and database ever coming up here.... > Where does it fit into the CS curriculum? It is typically its own course (it takes a completely different attitude than "another programming language"). Most programmers "pick it up" after school. Usually they "don't want to understand," but "just have to get this coded." There are too many texts that cater to that attitude, to the detriment of the consumer. This attitude leads to bad (inefficient), product-specific SQL. The best texts I've found for DB for the programmer are Joe Celko's books; he has a good blend of practical and enough theory to steer it. He is also one of the few practical programming authors to write about how to write in SQL without picking a single vendor and teaching you how to use their product. --Scott David Daniels Scott.Daniels at Acm.Org From chuck at freshsources.com Sat Jun 4 20:09:45 2005 From: chuck at freshsources.com (Chuck Allison) Date: Sat, 4 Jun 2005 12:09:45 -0600 Subject: [Edu-sig] A case against GUIs in intro CS :-) In-Reply-To: <0IHK00HR46WX8B@mta8.srv.hcvlny.cv.net> References: <0IHK00HR46WX8B@mta8.srv.hcvlny.cv.net> Message-ID: <298906142.20050604120945@freshsources.com> Hello Toby, Saturday, June 4, 2005, 1:50:30 AM, you wrote: TD> On 6/3/05 11:00 AM, "Chuck Allison" wrote: >> I think VB is the absolute >> worst way to introduce programming, TD> Worse than COBOL? Or the C pre-processor? :-) Well, worse than what is being used today. These aren't on the plate. >> and emphasizing GUI in a first exposure to computing is a mistake. TD> My feeling is that it was not so much GUI-first as design-first that made TD> the VB course I taught so interesting. By drawing a GUI first, you are doing TD> some design, and even making decisions about certain variables and data TD> structures. Your goal is clear: you want to write a program that implements TD> the GUI. And it's not just the visuals that students would work out before TD> writing code, but they also thought about the interaction, and how the TD> interface should behave. It makes programming very goal-oriented. Teaching design early is a good thing. What I object to over-emphasizing GUIs is that newbies feel that 1) Event-driven programming is the only way to go, and 2) if there isn't a GUI, you're not programming. I am reacting to a strong contingent that has been in my face a lot. Thee are many who really believe this. GUI has it's place, though, as I have suggested. There are actually subtle dangers in event-driven design itself. I heartily suggest everyone read Miro Samek's "Who Moved My State", C/C++ Users Journal, April 2003. He says it much better than I can, and he's one who Really Knows. TD> I more commonly hear students complain that CS doesn't do a good job of TD> preparing them for a career in software engineering. That it is too focused TD> on esoteric theory, and that too many (university) faculty hold their noses TD> when writing programs. I have heard this too, but my college is not one of those. We cater to industry, while not skimping on theory. -- Best regards, Chuck From chuck at freshsources.com Sat Jun 4 20:11:08 2005 From: chuck at freshsources.com (Chuck Allison) Date: Sat, 4 Jun 2005 12:11:08 -0600 Subject: [Edu-sig] A case against GUIs in intro CS :-) In-Reply-To: <0IHK00HR46WX8B@mta8.srv.hcvlny.cv.net> References: <0IHK00HR46WX8B@mta8.srv.hcvlny.cv.net> Message-ID: <1664696777.20050604121108@freshsources.com> Hello Arthur, Saturday, June 4, 2005, 6:06:34 AM, you wrote: A> Question. A> I don't remember SQL and database ever coming up here. A> It is the only the combination of skills I developed in learning Python and A> in learning SQL and database design that has allowed me to become useful in A> the real world - in the making $ sense of the word. A> Luckily I find database stuff interesting enough, and SQL powerful enough in A> the context of database, that I have been able to throw myself into the A> effort to get my arms around these technologies. A> And they seem to be very core skills for making one's way in the world as a A> developer. A> Where does it fit into the CS curriculum? A> Art We teach it in a few places. First, we have a required Database class at the junior level. Then, several classes thereafter use DB in the assignments. And of course it usually makes its way into the capstone project for those majoring in software engineering. -- Best regards, Chuck From urnerk at qwest.net Sat Jun 4 22:01:13 2005 From: urnerk at qwest.net (Kirby Urner) Date: Sat, 4 Jun 2005 13:01:13 -0700 Subject: [Edu-sig] A case against GUIs in intro CS :-) In-Reply-To: <1664696777.20050604121108@freshsources.com> Message-ID: <20050604200115.D678D1E400B@bag.python.org> To some extent what's bogus about the GUI vs. no-GUI debate is that you /have/ to have an interface to the user at some point, whether this is accomplished with bells and whistles or not. So both the command line and the windowing environment are meant to accomplish the same purpose: closing the feedback loop between user and CPU. I'd like a CS0/CS1 to take a more resolutely historical approach and clomp through the command line era in grand style, taking very seriously the command line switches, man pages, HTML manuals or whatever. Especially in UNIX, these commands were designed to be chained, switched, piped, redirected. They were tiny toys, power tools, micro apps. The accomplished sysadmin had enough of them down to perform serious kung fu. So my CS0 is a combination of command line Linux, Python shell, Python shell invoking command line Linux, Python programs run as scripts, from the command line. This would seem very austere to newbies, but we'd perpetuate the ethos that GUIs are for gimps -- you don't need those handicaps to play the game. But it'd be a mock attitude, i.e. we secretly respect GUIs (the good ones) and write them ourselves. But the command line has lost none of its power in the meantime. However, as I've also reiterated, I'm not designing a CS curriculum. This is a CS/math hybrid, with emphasis on the math. So the Linux/POSIX notation, along with dot-notation, will have a means-to-an-end feel, Python taking us even further, into graphical and tactile output territory for example, e.g. the 1000s-of-frequency Waterman polyhedra (whatever that means right?). Kirby From nico at tekNico.net Sat Jun 4 22:44:58 2005 From: nico at tekNico.net (Nicola Larosa) Date: Sat, 04 Jun 2005 22:44:58 +0200 Subject: [Edu-sig] A case against GUIs in intro CS :-) In-Reply-To: <298906142.20050604120945@freshsources.com> References: <0IHK00HR46WX8B@mta8.srv.hcvlny.cv.net> <298906142.20050604120945@freshsources.com> Message-ID: > There are actually subtle dangers in event-driven design itself. I > heartily suggest everyone read Miro Samek's "Who Moved My State", > C/C++ Users Journal, April 2003. He says it much better than I can, > and he's one who Really Knows. After a little Googling, here it is: http://www.quantum-leaps.com/writings/samek0304.pdf It looks interesting, at a first glance. I'll read it soon. -- Nicola Larosa - nico at tekNico.net Forget everything you ever learned about wxPython/Twisted integration. It is no longer relevant. Forget that any of the ugly wxPython+Twisted Python Cookbook entries, lame wiki examples, twisted.internet.wxreactor, etc. even exist. -- Bob Ippolito, April 2005 From ajsiegel at optonline.net Sun Jun 5 03:51:53 2005 From: ajsiegel at optonline.net (Arthur) Date: Sat, 04 Jun 2005 21:51:53 -0400 Subject: [Edu-sig] A case against GUIs in intro CS :-) In-Reply-To: <20050604200115.D678D1E400B@bag.python.org> Message-ID: <0IHL00I6W96ORA@mta5.srv.hcvlny.cv.net> > -----Original Message----- > From: edu-sig-bounces at python.org [mailto:edu-sig-bounces at python.org] On > Behalf Of Kirby Urner > To some extent what's bogus about the GUI vs. no-GUI debate is that you > /have/ to have an interface to the user at some point, whether this is > accomplished with bells and whistles or not. So both the command line and > the windowing environment are meant to accomplish the same purpose: > closing > the feedback loop between user and CPU. Python has presented what I think is another alternative. The entry point to PyGeo is purposefully not a GUI. I think that getting what one should get from the process of doing a geometric construction - in order for it to have the cognitive impact that makes it a meaningful activity - rules out a GUI event sequence. I believe this firmly, despite the fact that almost all other dynamic geometry applications of which I am aware take the opposite tack - click here to create a point, click there to create another point, do this to connect the points, etc and etc. I like to think that the attempt of PyGeo is to create an interface that is neither a GUI or an API, but an SUI - a script users interface Much thought and intention has gone into the design of the PyGeo SUI (it is the SUI I want to use to *Do* geometry), but I suspect it comes off to some as if the author just hasn't gotten around to the GUI yet, or is trying to be stubbornly geeky, or something. In my view, the more GUI intensive efforts are the less mature. It sometimes what you don't say that is the more important statement, as it sometimes the GUI that you don't create. If the purpose is to get to the end result, the construction on the screen, maybe the GUI approach makes sense. If the process of getting to the construction is the essence of the activity, which in what I am intending it indeed is, then the more sophisticated GUI approach is clearly less sophisticated. Art > > I'd like a CS0/CS1 to take a more resolutely historical approach and clomp > through the command line era in grand style, taking very seriously the > command line switches, man pages, HTML manuals or whatever. Especially in > UNIX, these commands were designed to be chained, switched, piped, > redirected. They were tiny toys, power tools, micro apps. The > accomplished > sysadmin had enough of them down to perform serious kung fu. > > So my CS0 is a combination of command line Linux, Python shell, Python > shell > invoking command line Linux, Python programs run as scripts, from the > command line. This would seem very austere to newbies, but we'd > perpetuate > the ethos that GUIs are for gimps -- you don't need those handicaps to > play > the game. But it'd be a mock attitude, i.e. we secretly respect GUIs (the > good ones) and write them ourselves. But the command line has lost none > of > its power in the meantime. > > However, as I've also reiterated, I'm not designing a CS curriculum. This > is a CS/math hybrid, with emphasis on the math. So the Linux/POSIX > notation, along with dot-notation, will have a means-to-an-end feel, > Python > taking us even further, into graphical and tactile output territory for > example, e.g. the 1000s-of-frequency Waterman polyhedra (whatever that > means > right?). > > Kirby > > > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig From ajsiegel at optonline.net Sun Jun 5 15:06:28 2005 From: ajsiegel at optonline.net (Arthur) Date: Sun, 05 Jun 2005 09:06:28 -0400 Subject: [Edu-sig] A case against GUIs in intro CS :-) In-Reply-To: <0IHL00I6W96ORA@mta5.srv.hcvlny.cv.net> Message-ID: <0IHM0091V4GX2O@mta1.srv.hcvlny.cv.net> > -----Original Message----- > From: edu-sig-bounces at python.org [mailto:edu-sig-bounces at python.org] On > Behalf Of Arthur > Sent: Saturday, June 04, 2005 9:52 PM > To: 'Kirby Urner'; 'Edu-sig' > Subject: Re: [Edu-sig] A case against GUIs in intro CS :-) > > -----Original Message----- > > From: edu-sig-bounces at python.org [mailto:edu-sig-bounces at python.org] On > > Behalf Of Kirby Urner > > If the purpose is to get to the end result, the construction on the > screen, > maybe the GUI approach makes sense. If the process of getting to the > construction is the essence of the activity, which in what I am intending > it > indeed is, then the more sophisticated GUI approach is clearly less > sophisticated. Which is the point that leads me to be resistance/suspicions/paranoias/concerns in respect to the introduction of technology into the classroom, more generally. Kirby's efforts as well as my own do not attempt to entice based on their technical sophistication. Raw simple unadorned transparent is what makes sense in a serious effort to make cognitive connections. But such an approach - once it is introduced on a computer - cannot be taken seriously, because it is raw simple transparent and unadorned, and that's not how we use computers, these days. HCI studies are generally designed to measure results, comfort levels, etc. So I don't think they are likely to ever uncover the truths here, where the results are not the point, and a certain level of discomfort (avoiding glibness) is for the better. Art > > Art From ajsiegel at optonline.net Sun Jun 5 17:03:30 2005 From: ajsiegel at optonline.net (Arthur) Date: Sun, 05 Jun 2005 11:03:30 -0400 Subject: [Edu-sig] A case against GUIs in intro CS :-) In-Reply-To: <0IHM0091V4GX2O@mta1.srv.hcvlny.cv.net> Message-ID: <0IHM00BJW9VXTV@mta1.srv.hcvlny.cv.net> > -----Original Message----- > From: Arthur [mailto:ajsiegel at optonline.net] > To: 'Arthur'; 'Kirby Urner'; 'Edu-sig' > > Behalf Of Arthur > So I don't think they are likely to ever uncover the truths here, where > the > results are not the point, and a certain level of discomfort (avoiding > glibness) is for the better. The only realms that I can think of in which the notion of the voluntary adoption of and adaptation to discomfort has been successfully introduced is Religion Athletic training I have decided to (at this time) forego the incorporation of the Church of the Awkward Interface (hmmmm... foregoing some nice tax benefits), and concentrate for the time being on the athletic training meme. See how far I get. Art From urnerk at qwest.net Sun Jun 5 18:08:06 2005 From: urnerk at qwest.net (Kirby Urner) Date: Sun, 5 Jun 2005 09:08:06 -0700 Subject: [Edu-sig] A case against GUIs in intro CS :-) In-Reply-To: <0IHM00BJW9VXTV@mta1.srv.hcvlny.cv.net> Message-ID: <20050605160806.4C8311E400C@bag.python.org> > The only realms that I can think of in which the notion of the voluntary > adoption of and adaptation to discomfort has been successfully introduced > is > > Religion > Athletic training > > I have decided to (at this time) forego the incorporation of the Church of > the Awkward Interface (hmmmm... foregoing some nice tax benefits), and > concentrate for the time being on the athletic training meme. > > See how far I get. > > Art I think the athletic training metaphor is a fine one to milk. I'm drawn to the bicycle world in particular, where there's the actual activity of riding, which may be very strenuous (distance racing is one of the most punishing of all competitive sports), but also the job of maintaining the bike. Race car people do the maintenance too, including deep rebuilding of engine components, but the bicycle is more transparent, lighter weight, so I'll stick with them. Horses would have been another option, but our urban kids wouldn't get it. To me, the *nix OS as approached through the command line feels like a bicycle repair shop. Lots of little tools, all of which do something useful and specialized. Used in concert, you can do wonders with your bicycle, which on this analogy might be some project or application you're developing (maybe for someone else -- bicycle shops aren't confined to working on the owner's bike, especially given ssh). The *nix OS, unlike Windows, is all about giving the developer a lot of developer tools. Microsoft sees those as extra (e.g. Visual Studio), and as intensively GUI-based. That's because DOS was written for the end user, the stereotypical consumer of apps. Early Windows was merely a GUI-based wrapper for DOS (at least at first) and preserved the "developers do it elsewhere (i.e. on our more expensive platforms)" aesthetic. Also, although bicycle technology has changed over the years, it's still very inter-generational. Likewise the command line. Some may consider it antiquated, superseded by the GUI, the desktop. That's not really a correct assumption. People still need to build and fix bicycles, and the command line tools still make sense. Some are more obscure than others, but it's not a waste of time to get fluent with at least a subset of them. The link to math and Python is that math notations aim to be self-contained i.e. to take my course, you don't need to take any other mathematician's course, because like she or he, I'm trained to build everything from axioms right in front of you, such that my towering theorems are seen to rest on my secure foundations, and you're suitably impressed -- like, math is impressive. So if we're playing around with shells, doing math, we'll at least need to at least be able to ssh, ls, cd and such. We don't tell you to go down the hall for that; just stay in your seat and all will become clear, and if you've heard it before, listen again, because this is the math department now, and math is different. Kirby From ajsiegel at optonline.net Sun Jun 5 19:40:42 2005 From: ajsiegel at optonline.net (Arthur) Date: Sun, 05 Jun 2005 13:40:42 -0400 Subject: [Edu-sig] A case against GUIs in intro CS :-) In-Reply-To: <0IHM00CCGCTGBB@mta17.srv.hcvlny.cv.net> Message-ID: <0IHM007J7H41AY@mta5.srv.hcvlny.cv.net> > -----Original Message----- > From: Kirby Urner [mailto:urnerk at qwest.net] > Sent: Sunday, June 05, 2005 12:08 PM > To: 'Arthur'; 'Edu-sig' > Subject: RE: [Edu-sig] A case against GUIs in intro CS :-) > > > The only realms that I can think of in which the notion of the voluntary > > adoption of and adaptation to discomfort has been successfully > introduced > > is > > > > Religion > > Athletic training > > > > I have decided to (at this time) forego the incorporation of the Church > of > > the Awkward Interface (hmmmm... foregoing some nice tax benefits), and > > concentrate for the time being on the athletic training meme. > > > > See how far I get. > > > > Art > > I think the athletic training metaphor is a fine one to milk. Less far-out when I recall that my 10th grade math teacher and my junior varsity wrestling coach were one-in-the-same. And I promise that training for collegiate style wrestling is all about adaptation to discomfort. Perhaps explains how I can get through 8 chapters on Lisp syntax ;) > I'm drawn > to > the bicycle world in particular, where there's the actual activity of > riding, which may be very strenuous (distance racing is one of the most > punishing of all competitive sports), but also the job of maintaining the > bike. The real point, I think, is that it is not the most efficient way to get from here to there. But its workings are transparent, and there is no ambiguity as to whom is supplying the power. Art From tjd at sfu.ca Mon Jun 6 00:13:22 2005 From: tjd at sfu.ca (Toby Donaldson) Date: Sun, 05 Jun 2005 15:13:22 -0700 Subject: [Edu-sig] A case against GUIs in intro CS In-Reply-To: References: Message-ID: <42A37902.8080406@sfu.ca> > I'd like a CS0/CS1 to take a more resolutely historical approach and clomp > through the command line era in grand style, taking very seriously the > command line switches, man pages, HTML manuals or whatever. Especially in > UNIX, these commands were designed to be chained, switched, piped, > redirected. They were tiny toys, power tools, micro apps. The accomplished > sysadmin had enough of them down to perform serious kung fu. While I don't think a completely command-lined based approach would work well for a large mixed-audience CS0/1 class, I think it is an important and useful tool that developers should know about. Unfortunately, most students are not excited by system administration. Indeed, many programmers dislike it too. Similarly, most university instructors would be turned off by the idea; "system administration" is a a dirty word in "proper" CS education. As a case-study in programming, system administration is a good example of how to get simple programs to do useful things for you. > So my CS0 is a combination of command line Linux, Python shell, Python shell > invoking command line Linux, Python programs run as scripts, from the > command line. A side-effect of relying IDEs for programming is that most students only know how to run a program through the IDE. I think in a first course showing students how to launch programs from the command-line is good idea. I would allow but not require students to use the command-line for program *development*. > This would seem very austere to newbies, but we'd perpetuate > the ethos that GUIs are for gimps -- you don't need those handicaps to play > the game. But it'd be a mock attitude, i.e. we secretly respect GUIs (the > good ones) and write them ourselves. Yikes. Any "gimp" who has had to work with a programmer "educated" in this sort user-hostile rhetoric knows that it leaves a lot to be desired. I can't understand why anyone would want to actively promote it, except as a joke about the foolishness of some programmers. A wiser approach is to encourage students to use the best tool for the job. Toby From ajsiegel at optonline.net Mon Jun 6 02:19:15 2005 From: ajsiegel at optonline.net (Arthur) Date: Sun, 05 Jun 2005 20:19:15 -0400 Subject: [Edu-sig] A case against GUIs in intro CS In-Reply-To: <42A37902.8080406@sfu.ca> Message-ID: <0IHM001I6ZI19U@mta8.srv.hcvlny.cv.net> > -----Original Message----- > From: edu-sig-bounces at python.org [mailto:edu-sig-bounces at python.org] On > Behalf Of Toby Donaldson > A wiser approach is to > encourage students to use the best tool for the job. Were it only that easy. Perhaps it is easy, except when its important. For example, what is the best tool for the job of teaching introductory computer science? The best tool for the job is apparently not apparent. Or is the definition of the job that is not? Art From urnerk at qwest.net Mon Jun 6 06:42:37 2005 From: urnerk at qwest.net (Kirby Urner) Date: Sun, 5 Jun 2005 21:42:37 -0700 Subject: [Edu-sig] A case against GUIs in intro CS In-Reply-To: <42A37902.8080406@sfu.ca> Message-ID: <20050606044238.D71D51E400C@bag.python.org> > > This would seem very austere to newbies, but we'd perpetuate > > the ethos that GUIs are for gimps -- you don't need those handicaps to > > play the game. But it'd be a mock attitude, i.e. we secretly respect > > GUIs (the good ones) and write them ourselves. > > Yikes. Any "gimp" who has had to work with a programmer "educated" in this > sort user-hostile rhetoric knows that it leaves a lot to be desired. I > can't understand why anyone would want to actively promote it, except as a > joke about the foolishness of some programmers. A wiser approach is to > encourage students to use the best tool for the job. > > Toby The use of 'gimp' was a play on Gimp, the source of GTK, a premier X-Windows library. It's not supposed to come across as hostile, but simply as reassurance to a resolute core group, that command-line savvy is not in vain. We're contenders. We matter. That sort of thing. Cheer leading. And then there's an edge to it, because you don't want to envy the competition so much that your concentration fails. So we bad-mouth the GUI people a little, but only to keep our spirits up, as we're secretly in love with GNOME, KDE, and the rest of them. In fact, we're all on the same team. I code GUIs, and I like command-line straightforwardness. I'm representative of a huge group of coders. Kirby From dave at lakegregoryics.com Tue Jun 7 07:13:28 2005 From: dave at lakegregoryics.com (dave@lakegregoryics.com) Date: Mon, 6 Jun 2005 22:13:28 -0700 Subject: [Edu-sig] Elementary School Instruction Message-ID: <20050607051328.30045.qmail@gem-wbe01.mesa1.secureserver.net> Has anyone here had experience teaching Python to Elementary School children 9 to 12 years of age? This kids are part of a gifted students elective program (upwards of 120 students) in the area where I live. I am in the planning stages of a 3 part series (18 weeks) covering beginning Python and would appreciate hearing about any experience and/or advice you might have. Thanks, Dave Lanham LGICS From chandrakirti at gmail.com Tue Jun 7 12:11:01 2005 From: chandrakirti at gmail.com (Lloyd Hugh Allen) Date: Tue, 7 Jun 2005 06:11:01 -0400 Subject: [Edu-sig] Elementary School Instruction In-Reply-To: <20050607051328.30045.qmail@gem-wbe01.mesa1.secureserver.net> References: <20050607051328.30045.qmail@gem-wbe01.mesa1.secureserver.net> Message-ID: <24d253d905060703114da6a52@mail.gmail.com> The summer camp where I had taught Python had a middle school session for students in grades 6-8, which is about that age group. There was a strong correlation between students who did well with Python and students who demonstrated readiness for Algebra I. At the time that I did this, PyKarel worked but GVR (which are both simulations of Karel the Robot, which was originally a paper-based concrete "programming" activity) was not quite ready for Windows (or at least I couldn't get it to run on Windows), so I had to take the activities and modify them to fit the syntax of the environment (which was somewhere between the original syntax and GVR). This was worthwhile though--first I introduced each concept in this environment, in which the students were able to see exactly what was happening, and then when I taught the corresponding skill in Python a few days later I was able to say, "Remember when you had the Robot take out the trash? We used something called a 'while' loop for that. This is the same while, except that we have to get inside the computer's head to know what's going on instead of being able to see what the robot is doing." I also did graphics with them relatively early...I think I have that lesson somewhere around here, but it seems to be on my other computer...which isn't listening to me right now. It might be cranky about the power outage from the thunderstorms last night. The essence of the activity was that I had them sketch their face on graph paper, identify the coordinates of the rectangle bounding each rectangle or oval (or the coordinates of the endpoint of each line segment and/or vertices of each polygon) on the paper, and then use Tkinter to draw their self portrait. The first round of this they used "monolithic" style programs (BUT WITH SUBSTANTIVE COMMENTS, e.g., "#now I'm drawing the mouth", and then these were pretty easily converted to functional versions. Once they used functions, we could take this person's head() and fairly easily put that person's hair() on it, sometimes with amusing results. Between Karel and being able to use graphics early, even some of the students who initially were bummed that their parents sent them to math camp (which I myself wish that I had known about when I was in school) found some motivation to dig deep...not necessarily to do what I "wanted" them to do in terms of the lesson for that day, but hey, if they're programming I'm happy (at least in that low-stakes but mostly high-motivation environment). It's always nice to get feedback, and especially pretty feedback. These activities can act as a "hook." -Lloyd On 6/7/05, dave at lakegregoryics.com wrote: > Has anyone here had experience teaching Python to Elementary School > children 9 to 12 years of age? This kids are part of a gifted students > elective program (upwards of 120 students) in the area where I live. I > am in the planning stages of a 3 part series (18 weeks) covering > beginning Python and would appreciate hearing about any experience > and/or advice you might have. > > Thanks, > > Dave Lanham > LGICS > > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig > From inxdr at yahoo.com.au Tue Jun 7 12:20:14 2005 From: inxdr at yahoo.com.au (Darren Payne) Date: Tue, 7 Jun 2005 20:20:14 +1000 (EST) Subject: [Edu-sig] Edu-sig Digest, Vol 23, Issue 9 In-Reply-To: Message-ID: <20050607102014.1560.qmail@web54602.mail.yahoo.com> I have run a 2 day course @ the University of New South Wales (UNSW) for gifted 10 - 11 year olds as part of the Junior Scientia program for gifted children. However, this was using java not Python. I based the course on a book by a teacher [Jeff Spence - Teaching Java applet Games ... used to be available from java4schools.com] who had been on exchange in my home town. I expect the livewires course would be just as suitable. if you email me offlist I will zip the course and send it to you - it is all web based so can run off an intranet. At UNSW I found it easiest to drop all of the "stuff" in the html dir of the unix account I used - which made it live to the world via Internet. The classes could then go directly to the URL to access all materials. --- edu-sig-request at python.org wrote: > Send Edu-sig mailing list submissions to > edu-sig at python.org > > To subscribe or unsubscribe via the World Wide Web, > visit > http://mail.python.org/mailman/listinfo/edu-sig > or, via email, send a message with subject or body > 'help' to > edu-sig-request at python.org > > You can reach the person managing the list at > edu-sig-owner at python.org > > When replying, please edit your Subject line so it > is more specific > than "Re: Contents of Edu-sig digest..." > > > Today's Topics: > > 1. Elementary School Instruction > (dave at lakegregoryics.com) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 6 Jun 2005 22:13:28 -0700 > From: dave at lakegregoryics.com > Subject: [Edu-sig] Elementary School Instruction > To: edu-sig at python.org > Message-ID: > > <20050607051328.30045.qmail at gem-wbe01.mesa1.secureserver.net> > Content-Type: TEXT/plain; CHARSET=US-ASCII > > Has anyone here had experience teaching Python to > Elementary School > children 9 to 12 years of age? This kids are part of > a gifted students > elective program (upwards of 120 students) in the > area where I live. I > am in the planning stages of a 3 part series (18 > weeks) covering > beginning Python and would appreciate hearing about > any experience > and/or advice you might have. > > Thanks, > > Dave Lanham > LGICS > > > > ------------------------------ > > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig > > > End of Edu-sig Digest, Vol 23, Issue 9 > ************************************** > ----------------------------------------------------------------------------------- regards Darren Payne Hurlstone Agricultural High School Ph: 9829 9222 Fax: 98292026 Send instant messages to your online friends http://au.messenger.yahoo.com From lac at strakt.com Tue Jun 7 13:26:42 2005 From: lac at strakt.com (Laura Creighton) Date: Tue, 07 Jun 2005 13:26:42 +0200 Subject: [Edu-sig] A case against GUIs in intro CS :-) In-Reply-To: Message from Chuck Allison of "Fri, 03 Jun 2005 00:36:08 MDT." <1496555689.20050603003608@freshsources.com> References: <1496555689.20050603003608@freshsources.com> Message-ID: <200506071126.j57BQgGL030504@ratthing-b246.strakt.com> I have often wondered if we didn't lose something when the first programming people learn to do is no longer batch processing -- the sort I learned to do with cards. At any rate, I keep meeting people who have severe problems understanding how to write programs that do not interact with a user at all. They keep wanting to have 'conversations' with an assumed 'program operator' ... It is a fundamental conceptual problem, for some of them. The notion that somebody could want to 'get data from here' without clicking on a mouse for a filename at all stops some people cold, even though they have already had 1 or 2 introductory progamming courses. For them, the _GUI_ is the computer, and the computer is relentlessly interactive... Laura From urnerk at qwest.net Tue Jun 7 17:32:49 2005 From: urnerk at qwest.net (Kirby Urner) Date: Tue, 7 Jun 2005 08:32:49 -0700 Subject: [Edu-sig] Elementary School Instruction In-Reply-To: <20050607051328.30045.qmail@gem-wbe01.mesa1.secureserver.net> Message-ID: <20050607153248.B03051E4002@bag.python.org> Hi Dave -- I had some home schoolers in that age group. One activity that proved popular with "madlibs" which is where you have this canned paragraph with blanks in place of some adjectives, nouns, verbs (you're likely familiar with the genre -- the story is usually pretty zany). Example: http://www.4dsolutions.net/satacad/sa6299/madlib1.py (note, the text is from a published madlibs book, credit given). I found kids enjoyed this activity, which came after a fair amount of shell activity around substitution, which happened after we'd introduced the dictionary as a data structure, e.g.: >>> thewords = {'noun1':'house', 'noun2':'mouse'} >>> print "In this %(noun1)s there lives a %(noun2)s." % thewords In this house there lives a mouse. Once these concepts and syntax are clear, then I think it's OK to work with pre-programmed code, i.e. I didn't make them write the simple loop that gathered their word choices and stuffed them in a dictionary. But we did go over said code. As with human language learning, it's easier to read grammatical code than it is to speak or write it (because so much of the work is already done). I then used a lot of this same substitution technology to write scene description language for POV-Ray. The kids also enjoyed using POV-Ray directly, without mediation by Python. Typical code: http://www.4dsolutions.net/satacad/pytools/povray.py A prerequisite here is some appreciation for XYZ coordinates. I got lucky. My home schooling students already knew all about that stuff. Some of this stuff at my web site was done with older kids (high school) so if you poke around, you'll see material that's obviously too advanced for 9-12 year olds. What really slows kids down is an inability to keyboard at all efficiently -- hunt and peck, with a lot of hunting. Typing skills remain as important as always. A prime motivator to increase speed these days is IM and IRC, but sometimes kids this young don't have a peer group that uses these typing-intensive interfaces. Kirby > -----Original Message----- > From: edu-sig-bounces at python.org [mailto:edu-sig-bounces at python.org] On > Behalf Of dave at lakegregoryics.com > Sent: Monday, June 06, 2005 10:13 PM > To: edu-sig at python.org > Subject: [Edu-sig] Elementary School Instruction > > Has anyone here had experience teaching Python to Elementary School > children 9 to 12 years of age? This kids are part of a gifted students > elective program (upwards of 120 students) in the area where I live. I > am in the planning stages of a 3 part series (18 weeks) covering > beginning Python and would appreciate hearing about any experience > and/or advice you might have. > > Thanks, > > Dave Lanham > LGICS > > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig From ajudkis at verizon.net Wed Jun 8 23:35:50 2005 From: ajudkis at verizon.net (Andy Judkis) Date: Wed, 08 Jun 2005 17:35:50 -0400 Subject: [Edu-sig] Elementary School Instruction References: Message-ID: <002701c56c72$11b71590$6401a8c0@Gandalf> I am winding up my first year as a high school technology teacher, after 20+ years as an engineer and programmer. I teach 10th graders (ages 15 or 16) in a magnet high school for kids interested in medical careers. The school is competive to get into, and while the students are not all brilliant, the average ability is better than the population as a whole -- FWIW, average SATs are in the low 600s. For better or worse, I've gotten to put together my curriculum, and I have included a 3-4 week introduction to Python programming as part of it. We have block scheduling, so 4 weeks is about 30 hours in the classroom -- not a trivial amount of time. I have worked very hard to put something together, and many of the kids just don't get it. Last semester I started off with the Livewires materials, but almost immediately discovered that the kids were helpless whenever the materials said "now how would you do x?" So I walked them through it. If I gave them a trivial problem to solve that required them to recognize that some sort of looping would be required. . . forget it. This semester I started the unit off with a week of RUR-PLE, which I thought would help a lot. RUR-PLE is a very nice piece of work, and it's a very good way for the kids to dip their toes into the pool. It helped, but seeing where they are now -- well, they still don't get it at all. Even the difference between var = "hello" and var = hello or print foo() and print foo isn't really sinking in. I show examples, I give them exercises to do, I have them work together, but very few of them seem to build any understanding. So the idea that much younger kids are grasping syntax like this: >>> thewords = {'noun1':'house', 'noun2':'mouse'} >>> print "In this %(noun1)s there lives a %(noun2)s." % thewords makes me weep in frustration. When I first mentioned that I was planning to teach some programming, a more experienced teacher at the school immediately said "Oh, you can't teach these kids programming, you'll have to spoon-feed them all the way." At the time, I dismissed that notion, but now I'm wondering if she isn't right. So, my question is, if you wanted a group of certainly-not-stupid 16 year old kids to at least get a taste of programming, understanding that many of them are there because it's a required course, and they're not predisposed to be interested in it, what would you do? What is a minimal set of things they ought to be exposed to? How much time would you spend on it? What do you think they ought to be able to do at the end of the time? Thanks, Andy From inxdr at yahoo.com.au Thu Jun 9 13:35:38 2005 From: inxdr at yahoo.com.au (Darren Payne) Date: Thu, 9 Jun 2005 21:35:38 +1000 (EST) Subject: [Edu-sig] School Instruction [Andy] In-Reply-To: Message-ID: <20050609113538.15460.qmail@web54605.mail.yahoo.com> I have a great deal of sympathy and empathy for you Andy. I teach in a large selective (read magnet) school in NSW, Australia and I FIND EXACTLY THE SAME TRAITS. Note: I have also taught some really TRULLY gifted kids at my current school - and I am constantly bedazzled at their capacity to learn, digest and DO the most amazing things. I have been really lucky with some kids where I know just enough to keep pointing them in directions which they (a). enjoy and (b). are beneficial for them and (c) continue to develop their interests. I could ramble on ... going round & round on this topic for ages. Suffice to say i have turned to Gamemaker since last year (term 4) to capitalise on the motivation of being able to make REAL games - using that as a lever to introduce higher order concepts because it is REQUIRED in order to achieve a certain outcome. I hope to be able to make a move back to Python +PyGame in future years - have to see, at present it seems our interests will be fulfilled using Gamemaker. ----------------------------------------------------------------------------------- regards Darren Payne Hurlstone Agricultural High School Ph: 9829 9222 Fax: 98292026 Send instant messages to your online friends http://au.messenger.yahoo.com From sachs at cyb.org Thu Jun 9 16:38:14 2005 From: sachs at cyb.org (Josef Sachs) Date: Thu, 9 Jun 2005 10:38:14 -0400 Subject: [Edu-sig] UPDATE 2: High School Network Security In-Reply-To: <20050519152856.52928.qmail@web81608.mail.yahoo.com> References: <20050519152856.52928.qmail@web81608.mail.yahoo.com> Message-ID: <17064.21590.73551.53524@panix2.panix.com> >>>>> On Thu, 19 May 2005 08:28:56 -0700 (PDT), Frank Noschese said: > Thanks again so much for all your help! I replied to the tech > coodinator with some of your responses...they will reconsider the > installation at their next meeting (but I did unfortunately ruffle a > few feathers). I hope you will tell your students what it took for them to be able to do your project. Sometimes the most valuable lessons are "incidental" to the official syllabus. You have provided your students a lesson in character: initiative, responsibility, questioning and even challenging authority. Your students are very fortunate. From christian.mascher at gmx.de Thu Jun 9 17:54:30 2005 From: christian.mascher at gmx.de (Christian Mascher) Date: Thu, 09 Jun 2005 17:54:30 +0200 Subject: [Edu-sig] Elementary School Instruction In-Reply-To: References: Message-ID: <42A86636.3030007@gmx.de> > I am winding up my first year as a high school technology teacher, after 20+ > years as an engineer and programmer. I teach 10th graders (ages 15 or 16) > in a magnet high school for kids interested in medical careers. I think your experiences are quite normal, so don't be frustrated. > So the idea that much younger kids are grasping syntax like > this: > >>> thewords = {'noun1':'house', 'noun2':'mouse'} > >>> print "In this %(noun1)s there lives a %(noun2)s." % thewords > makes me weep in frustration. No, you shouldn't. You can't expect this from most children I know of. This requires a lot of abstract thinking, which is based on lots of experience and "having seen this again and again". What you and I can read in code is so different from a beginners view, we probably can't imagine it. Working with 15/16 year olds (the 'normal' ones with little formal training in math/programming), it does help very much to stick to a few restricted environments as turtle programming simulations with random() and doing lots of exercises with apparently little changes to the algorithms. We tend to be to fast at this stage, because Python is (for aus) so easily readable. The problem might be that students appear to get bored. But it won't help to go faster if you haven't built up some solid ground, be it very simple algorithmically. Turtle-Graphics helps a bit with the motivation ... Loops are not easy for beginners. Still the turtle or Robot helps, because you don't have to dicuss variable assignments at this stage, which actually _is_ a separate difficult subject. Look at the heaps of exercise the TeachScheme Project uses for solving absolutely simple programs in the first chapters. They know why the do it this way. I guess, I'm a bit frustrated myself that I have no Kings Way to teach programming faster, when I see so many possibilities to solve problems with Python myself. Christian > So, my question is, if you wanted a group of certainly-not-stupid 16 year > old kids to at least get a taste of programming, understanding that many of > them are there because it's a required course, and they're not predisposed > to be interested in it, what would you do? What is a minimal set of things > they ought to be exposed to? How much time would you spend on it? What do > you think they ought to be able to do at the end of the time? From dave at lakegregoryics.com Thu Jun 9 18:46:06 2005 From: dave at lakegregoryics.com (dave@lakegregoryics.com) Date: Thu, 9 Jun 2005 09:46:06 -0700 Subject: [Edu-sig] Elementary School Instruction Message-ID: <20050609164606.9114.qmail@webmail10.mesa1.secureserver.net> Andy, My experience is that there should be a certain amount of aptitude screening before teaching programming to anyone. The best way is to put a 2-3 person panel together, each with different teaching approaches AND a passion for their discipline. I don't require the kids to be pre-algebra or better, but they should grasp certain concepts within about 5 minutes of conversation. If they can't get certain basic concepts in that time, then it's just simply not their time to study programming. Dave Lanham LGICS From urnerk at qwest.net Thu Jun 9 19:43:15 2005 From: urnerk at qwest.net (Kirby Urner) Date: Thu, 9 Jun 2005 10:43:15 -0700 Subject: [Edu-sig] Elementary School Instruction In-Reply-To: <002701c56c72$11b71590$6401a8c0@Gandalf> Message-ID: <20050609174322.E2F251E4003@bag.python.org> > So, my question is, if you wanted a group of certainly-not-stupid 16 year > old kids to at least get a taste of programming, understanding that many > of them are there because it's a required course, and they're not > predisposed to be interested in it, what would you do? What is a minimal > set of things they ought to be exposed to? How much time would you spend > on it? What do you think they ought to be able to do at the end of the > time? > > Thanks, > Andy Hi Andy -- It's difficult to judge an ecology remotely -- even up close we don't know how to manage wildlife successfully (is Crichton's point, or one of his character's, in 'State of Fear', my recent airplane reading). In other words, I'd have to be in your classroom for awhile in order to speak specifically of my impressions. In some schools, there's a conspiracy among the students to make teachers work hard on the most primitive basics, a kind of unionization around the premise that any "star students" make the others look bad, so if you think you're going to study hard and show off, forget about it (if you want a social life that is, and we can make sure that you do). Funny thing is: many of these students grow up to become classroom teachers and continue operating along these same principles (a union of grown-ups, fancy that). In my recent teaching experiences where Python was involved, the students tended to not know each other socially outside of my classroom. They converged to an unfamiliar, high tech, vaguely industrial location (not their familiar school) and the teacher (me) was clearly not like a classroom teacher, e.g. he (me) didn't seem to spend a lot of time in classrooms (this was an exception, not the rule). All of the above changes a huge number of parameters, including that "not predisposed to be interested" part. In other news, I was invited to speak at Europython and have been listed on the web site as a speaker, Education track. To that end, I've produced a PDF outlining my specific objectives regarding Python in a mathematics context, K-12 or college (my focus is K-12, given my background as a high school mathematics teacher in New Jersey). I've linked to this PDF from my blog: http://worldgame.blogspot.com/2005/06/dot-notation.html Kirby From francesconoschese at sbcglobal.net Fri Jun 10 03:57:57 2005 From: francesconoschese at sbcglobal.net (Frank Noschese) Date: Thu, 9 Jun 2005 18:57:57 -0700 (PDT) Subject: [Edu-sig] UPDATE 3: High School Network Security Message-ID: <20050610015757.90194.qmail@web81608.mail.yahoo.com> Hi everyone, The Movable Python CDs worked very well and many students have created some very cool programs: projectile motion simulators, simple harmonic oscillators, Lorenz attractors, and Sierpinski pentagons, to name a few. By far the best thing about using VPython with beginners (as I'm sure you'd agree) is how "lenient" you can be when programming: creating variables whenever you'd like, not having to declare variable types, creating additional object attributes easily, using default attribute values, etc. It definitely makes programming more accessible. The graphing package and the built in vector operations in VPython were a big help, too! Based on the success of the student projects, I am looking to make VPython an integral part of our AP Physics curriculum next year, rather than the afterthought it was this year. Believe it or not, I am meeting with some people from our technology team on Tuesday (as per their request) to discuss how to "safely" install VPython on the school network. Another success story! Thanks again to everyone for their kind support! Frank Noschese John Jay High School Cross River, NY --- Josef Sachs wrote: > >>>>> On Thu, 19 May 2005 08:28:56 -0700 (PDT), Frank Noschese said: > > > Thanks again so much for all your help! I replied to the tech > > coodinator with some of your responses...they will reconsider the > > installation at their next meeting (but I did unfortunately ruffle a > > few feathers). > > I hope you will tell your students what it took for them to be able > to do your project. Sometimes the most valuable lessons are "incidental" > to the official syllabus. You have provided your students a lesson > in character: initiative, responsibility, questioning and even challenging > authority. Your students are very fortunate. > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig > From ajudkis at verizon.net Fri Jun 10 04:31:20 2005 From: ajudkis at verizon.net (Andy Judkis) Date: Thu, 09 Jun 2005 22:31:20 -0400 Subject: [Edu-sig] Elementary School Instruction References: <0IHT00JLYVW2MZA0@vms043.mailsrvcs.net> Message-ID: <002801c56d64$7d265af0$6401a8c0@Gandalf> Hi Kirby, Thanks for responding. I'm fortunate in that in our school, there really isn't a stigma associated with being a good student. The culture is really pretty good that way. I would love to blame my problems on the kids but I think the problem is really me, and my unrealistic expectations about how long it really takes to begin to get a sense of what programs and programming are about. Which brings me back to the questions: 1) how do you motivate typical kids to be interested enough in this to climb this particular hill? and 2) what is a reasonable set of things for them to learn in a 20-30 class hour unit on Python? Thanks again, Andy From winstonw at stratolab.com Fri Jun 10 05:18:50 2005 From: winstonw at stratolab.com (Winston Wolff) Date: Thu, 9 Jun 2005 23:18:50 -0400 Subject: [Edu-sig] Programming Exercises In-Reply-To: References: <08991054.20050525180035@freshsources.com> <24650577.20050526025447@freshsources.com> Message-ID: I just purchased the book "Python Programming" by Michael Dawson. I like it very much for teaching absolute beginners Python, and I have borrowed a bunch of his examples. All the examples revolve around games, from simple text based games to later graphics games with TKInter and PyGame/Livewire. If your students have a little experience in another language, this might be good. -winston On May 26, 2005, at 1:10 PM, Scott David Daniels wrote: > Chuck Allison wrote: > >> Hello Scott, >> >> Thursday, May 26, 2005, 1:55:15 AM, you wrote: >> >> SDD> Chuck Allison wrote: >> >> >>>> Hello edu-sig, >>>> >>>> Does anyone know of a good source of programming exercises/ >>>> projects >>>> to use when teaching Python to people who already know another >>>> language? Solutions don't need to be available - I just need some >>>> good sample programming assignments. Thanks. >>>> >>>> >> >> SDD> You need to tell us what yu are interested in / would like to >> do. >> SDD> Do you want to find eigenvectors? Do you want to do GUI >> work? .... >> >> Good question. Mostly I need general assignments (using sequences, >> mappings, text processing, basic OO, launching processes for testing, >> etc.), but also simple mail apps and basic COM (like processing >> Microsoft Word docs). No higher math. Some basic GUI ones would be >> nice too (will be using wxPython). Thanks! >> >> >> > First, do the Python tutorial if you have not. Try following Dive > Into Python if it meets your tastes. > > For text processing: > > Create or obtain a couple of plain ASCII texts. One should be short > for testing and development, and another long for fun and production. > Look to Project Gutenberg if you don't have anything long yourself. > Make a concordance (words to position) that you can save and restore > w/o re-counting your text. Find the N (50 for big) most frequent > words used. > > Once you have all that working, figure out how to show all instances > of a selected word "in context". For extra credit, words, sorted by > frequency or alphabetically (button selectable) presented on a wx > window that show your "word in context" when clicking on a word. > > That should hold you for a day or two. > > --- > > My bias is to go test-forward, so (if you want to try that) here is > a start (a first test to pass). Most of this is boilerplate, look at > the body of test_words to see the only actual test here. Create a > test_wordy.py file as so: > > import unittest > from StringIO import StringIO > import wordy # the module you are actually testing > > class TestWords(unittest.TestCase): > def test_words(self): > source = StringIO("a test") > self.assertEqual(['a', 'test'], list(wordy.aswords > (source))) > > if __name__ == '__main__': > unittest.main() > > Now, when you run python on this file you will get a failure. The > first > one is that wordy.py doesn't exist. Keep fixing until your test > passes. > Then add tests for new behavior, watch them fail, and fix the source > until it works. > > --Scott David Daniels > Scott.Daniels at Acm.Org > > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig > From urnerk at qwest.net Fri Jun 10 06:18:09 2005 From: urnerk at qwest.net (Kirby Urner) Date: Thu, 9 Jun 2005 21:18:09 -0700 Subject: [Edu-sig] Elementary School Instruction In-Reply-To: <002801c56d64$7d265af0$6401a8c0@Gandalf> Message-ID: <20050610041810.3D9171E4003@bag.python.org> Hi Andy -- Yeah, I wouldn't know about your class in particular. I'm glad your school hasn't been hit by the so damaging "we refuse to learn" syndrome. Such a missed opportunity! Good thing we have those community colleges in case one decides to go back and review what one /could/ have gotten, for free, the first time (though in the field of computers, the technology will likely have changed in some ways since high school -- so you have to keep going back to school anyway). I hesitate to list out any one list of proficiencies, but let me give it a go: an appreciation for Python's most basic data structures, the ideas of module (standard library, 3rd party, user defined), of namespace, the concept of dot notation and how this fits into class/object ideas. Dot notation is of special importance, because we find it in so many languages besides Python, including in the architecture of the Internet itself, where net.4dsolutions becomes a qualifying path name, something I might use in Java to distinguish my namespace (or class path). People ask about the "dot com" crash. What was that all about anyway? Sometimes you can snag student interest through storytelling. Finding the interesting stories (interesting to /them/) -- that's always the challenge, no? When I taught at the police station (West Precinct, HPD), the premise was "so you want to be an open source developer" and so interest in Python piggy-backed on top of the self concept of the average enrollee. If you want to think of yourself as "able to program" (and these kids did), then "in Python" isn't a stupid way to go (kids don't want to be stupid -- usually). This course wasn't just Python though. It was basic Linux command line, a little vi, demos/talks about diff/patch, the protocols, the layers, ip numbers, dns servers, sockets and ports. A lot of this was just spoken about, or communicated with movies e.g. 'Warriors of the Net' and 'Revolution OS' (we screened both, plus some others). Kirby > -----Original Message----- > From: Andy Judkis [mailto:ajudkis at verizon.net] > Sent: Thursday, June 09, 2005 7:31 PM > To: Kirby Urner; edu-sig at python.org > Subject: Re: [Edu-sig] Elementary School Instruction > > Hi Kirby, > > Thanks for responding. > > I'm fortunate in that in our school, there really isn't a stigma > associated > with being a good student. The culture is really pretty good that way. I > would love to blame my problems on the kids but I think the problem is > really me, and my unrealistic expectations about how long it really takes > to > begin to get a sense of what programs and programming are about. Which > brings me back to the questions: > 1) how do you motivate typical kids to be interested enough in this to > climb > this particular hill? and > 2) what is a reasonable set of things for them to learn in a 20-30 class > hour unit on Python? > > Thanks again, > Andy From peter at mapledesign.co.uk Fri Jun 10 11:47:50 2005 From: peter at mapledesign.co.uk (Peter Bowyer) Date: Fri, 10 Jun 2005 10:47:50 +0100 Subject: [Edu-sig] Teaching programming to physics students Message-ID: <6.2.1.2.0.20050610104620.03b92b68@127.0.0.1> Hi, For those of you who remember my previous email, I have been given the go-ahead to do my masters project investigating and developing techniques to teach programming to second year physics undergraduates at the University of Southampton. What is my motivation for doing this project? When my peers took it many were put off programming by the current course - it seemed a boring and useless topic only interesting if you wanted to do computational physics. Over 90% of the students taking the course 2 years ago had never programmed before. As I enjoy tinkering with code, I hated seeing people put off something that is fun, hence the project. The existing course, which until last year was taught in the first year, can be found at http://www.phys.soton.ac.uk/teach/year1/notes/lab1/. The aim of the course (according to the new coordinator) is to teach the students problem solving skills using the computer - which involves teaching programming before they can start. The current course does very little relating back to reality - it's very much teaching programming and don't ask why you'd ever want this. I am aiming to show why these skills are useful and how programming technique can make the student's life easier in future years, and hope that this will increase the enthusiasm of the students. I am planning to use Python for the course, in no small part due to the VPython module. This is OK because it's a student project, but if I want the course to go beyond this and be adopted by the department then Python will be a problem, as the lecturer in charge believes that Java is more useful to teach students as Computer Scientists are taught it, while other lecturers favour C (the argument that the current students never want to program again after being introduced to those languages is not accepted). With Oxford University having switched the computational physics course back from Python to C I do not have this as a good example for the choice of Python. I need to determine how much can be taught in 12 weeks. My original idea was to teach enough for students to be able to write VPython simulations of physics phenomena, but I am not sure whether this is realistic or not. Because this is a course to teach them how to think I do not want it to degenerate into a 'run this example, and note the output. Run this one. Try modifying the code if time is left' kind of course. I'm excited by this project, but starting to feel I've bitten off more than I can chew, so any advice or suggestions you can make would be great. Do any of you have existing course material for teaching programming to physicists (or engineers) or for teaching physics using programming which you can share? I have been requested to provide some coverage of alternative teaching methods and techniques in my report. If anyone can point me to resources on this topic I'd be most grateful. Peter From urnerk at qwest.net Sat Jun 11 06:39:24 2005 From: urnerk at qwest.net (Kirby Urner) Date: Fri, 10 Jun 2005 21:39:24 -0700 Subject: [Edu-sig] Elementary School Instruction In-Reply-To: <42A86636.3030007@gmx.de> Message-ID: <20050611043926.6D29C1E4003@bag.python.org> > > So the idea that much younger kids are grasping syntax like > > this: > > >>> thewords = {'noun1':'house', 'noun2':'mouse'} > > >>> print "In this %(noun1)s there lives a %(noun2)s." % thewords > > makes me weep in frustration. > > No, you shouldn't. You can't expect this from most children I know of. > This requires a lot of abstract thinking, which is based on lots of > experience and "having seen this again and again". What you and I can > read in code is so different from a beginners view, we probably can't > imagine it. > This is why I think math class and programming should be more or less the same subject and/or course of study in K-12.[1] Because in math we're already paying very close attention to nit picky details of syntax. cos(x) and cos(-x) mean different things. I'd like to see worksheets where students take the role of the Python interpreter and come back with the proper response to stuff like: 1. >>> a = 4 + 4 >>> a ____ 2. >>> a * 3 ____ 3. >>> a + a + a ____ And so on. Scheme has books like this. Cover one side with your hand and reveal the answers as you go down the page, mentally answering. Matthias has a great book like that, from the early days of the project. With Python, you need to get into the list pretty early. That's a rich syntax. 23. >>> thelist = ['carbon dioxide', 'mercury', 'iron sulfide', 'argon'] >>> thelist.sort() >>> thelist _______________ 24. >>> thelist[2] ___________ And so on. It's OK if the answers are easily available (like, check it on your computer). The concept here is to develop expectations, so that you're not neutral about what the computer comes back with. You've developed some mental reflexes of your own, and now anticipate what Python will do. That's called "knowing Python." 44. >>> thenumbers = {'one':1, 'two':2, 'three':3} >>> print "Easy as %(one)s-%(two)s-%(three)s!" _______________ 45. >>> thewords = {'noun1':'house', 'noun2':'mouse'} >>> print "The %(noun2)s is in the %(noun1)s." _________________ I don't regard the syntax for interpolating dictionary values into a string any more arcane or difficult than run-of-the-mill algebraic expressions. I agree that junior starts out staring blankly and meaningless strings. But if we're able to make headway in algebra, we should be able to make headway in Python. I suggest that learning them in tandem would actually make both easier; each would leverage the other, so to speak. Kirby [1] http://mathforum.org/kb/message.jspa?messageID=3800953&tstart=0 (the mock battle I mention is something along the lines of OSCON versus the NCTM -- science fiction, but still worth thinking about IMO). From rsenra at acm.org Sat Jun 11 16:07:35 2005 From: rsenra at acm.org (Rodrigo Dias Arruda Senra) Date: Sat, 11 Jun 2005 11:07:35 -0300 Subject: [Edu-sig] Lisping In-Reply-To: <24d253d905052607392206db22@mail.gmail.com> References: <0IH300IH5L69EP@mta4.srv.hcvlny.cv.net> <24d253d905052607392206db22@mail.gmail.com> Message-ID: <20050611110735.30cd35b1@Goku> [ Lloyd Hugh Allen ] ----------------------------------------------- | As a math teacher, I always fear that I am teaching my students a | particular piece of technology rather than the concept that I am | trying to teach. As a small example, I am confident that my students | can find the point of intersection between two lines with a TI-83, but | less confident that they can find it with a TI-92 or a Casio-whatever; | and I often fear that they don't recognize that they would get the | same answer by solving each equation for y, setting the y's equal to | each other, and then solving for x. | # cut | It is fine and good to learn a single language, but this is not | computer science. A single language is just a tool. It is necessary to | learn several languages in order to have an idea of what computer | science actually means. | Prerequisite to this is knowledge and use of more than one language. I couldn't agree more. I see people trying to teach a _pattern_ directly, as a shortcut to wisdom-transferring. I humbly believe that to teach a _pattern_, the educator must *carefully* choose the samples and guide the student to discover the _pattern_. Nevertheless, this path is harder for the educator, and thus less traveled day-after-day. best regards, Senra -- ,_ | ) Rodrigo Senra |(______ ----------------------------------------------- _( (|__|] GPr Sistemas http://www.gpr.com.br _ | (|___|] Blog http://rodsenra.blogspot.com ___ (|__|] IC - Unicamp http://www.ic.unicamp.br/~921234 L___(|_|] ----------------------------------------------- From ajsiegel at optonline.net Sat Jun 11 17:15:36 2005 From: ajsiegel at optonline.net (Arthur) Date: Sat, 11 Jun 2005 11:15:36 -0400 Subject: [Edu-sig] Not Pi Message-ID: <0IHX00CTWEE9US@mta4.srv.hcvlny.cv.net> Finally a site that captures the essence on interactive web learning. http://www.sock-monkey.com/pi.html Art From rsenra at acm.org Sat Jun 11 17:31:41 2005 From: rsenra at acm.org (Rodrigo Dias Arruda Senra) Date: Sat, 11 Jun 2005 12:31:41 -0300 Subject: [Edu-sig] A case against GUIs in intro CS :-) In-Reply-To: References: <0IHH00B20OCJNH@mta5.srv.hcvlny.cv.net> Message-ID: <20050611123141.2144c738@Goku> Arthur wrote: | > The author communicates respect for his audience. He says things once. | > Even hard things.......Him repeating himself is not going to help | > because he has already said it the best way he could | > find to say it. Saying it a second time, he could only be saying it a | > second best way. I see your point, and I beg to differ. In terms of human communication, there is hardly one best way to convey any message. Therefore, 'the second best way' might be a matter of reader perspective (not writer). The argument """there is nothing stopping me from reading it five or six times if I need to""" can be counter-argumented by '''I can skip text as much I'm confident'''. Moreover, there is no learning without some degree of repetion. Therefore, 'say things once' might turn from 'good-there-is-no-repetion' into 'blast-I-have-to-read-it-back-again'. Communicating well: clearly, enjoyably, effectively takes time, hard struggles for balance, and tough decisions. "Avoiding repetition == respect" is an oversimplification to me. best regards, Senra -- ,_ | ) Rodrigo Senra |(______ ----------------------------------------------- _( (|__|] GPr Sistemas http://www.gpr.com.br _ | (|___|] Blog http://rodsenra.blogspot.com ___ (|__|] IC - Unicamp http://www.ic.unicamp.br/~921234 L___(|_|] ----------------------------------------------- From chuck at freshsources.com Sat Jun 11 18:03:09 2005 From: chuck at freshsources.com (Chuck Allison) Date: Sat, 11 Jun 2005 10:03:09 -0600 Subject: [Edu-sig] Elementary School Instruction In-Reply-To: <20050611043926.6D29C1E4003@bag.python.org> References: <20050611043926.6D29C1E4003@bag.python.org> Message-ID: <1384575365.20050611100309@freshsources.com> Hello Kirby, Friday, June 10, 2005, 10:39:24 PM, you wrote: KU> 44. KU> >>> thenumbers = {'one':1, 'two':2, 'three':3} KU> >>> print "Easy as %(one)s-%(two)s-%(three)s!" KU> _______________ KU> 45. KU> >>> thewords = {'noun1':'house', 'noun2':'mouse'} KU> >>> print "The %(noun2)s is in the %(noun1)s." Aren't these missing the dictionary names in the print statements? -- Best regards, Chuck From ajsiegel at optonline.net Sat Jun 11 18:06:07 2005 From: ajsiegel at optonline.net (Arthur) Date: Sat, 11 Jun 2005 12:06:07 -0400 Subject: [Edu-sig] A case against GUIs in intro CS :-) In-Reply-To: <20050611123141.2144c738@Goku> Message-ID: <0IHX00LVWGQD9J@mta4.srv.hcvlny.cv.net> > -----Original Message----- > From: edu-sig-bounces+ajsiegel=optonline.net at python.org [mailto:edu-sig- > bounces+ajsiegel=optonline.net at python.org] On Behalf Of Rodrigo Dias > Arruda Senra > Sent: Saturday, June 11, 2005 11:32 AM > To: edu-sig at python.org > Subject: Re: [Edu-sig] A case against GUIs in intro CS :-) > "Avoiding repetition == respect" is an oversimplification to me. I don't disagree, really - except that it is near impossible to say anything that is not an oversimplification. It is true that I do find that I tend to need more than one perspective on the same subject in order to flesh it out in a way that gives it dimension. And generally accomplish it by reading more than one book/tutorial/whatever, often almost side-by-side, when trying to digest a subject. I think this is one of the reasons I could not adjust well to traditional schooling, especially when it came to introductory material for technical subjects. We are generally expected follow patiently a single text. I learned that I need multiple sources to effectively learn. It is in this sense that the appearance of the Internet was such a catalyst for new learning opportunities in my own case. Multiple sources, on most any subject, at my fingertips. And it is maybe because I tend to take that approach, that I tend to appreciate an author giving his best shot at communicating *a* perspective. Not many. I *will* need another perspective, to be sure - but I will get that from another source, who hopefully is giving it their best shot at communicating their perspective - which if substantive enough will almost always be shaded in its own way, and therefore not simply redundant as to my other source/sources. I am thinking more about how I tend to study math and geometry than programming, directly. But I have this crazy theory that the pursuits follow similar cognitive paths. Art From rsenra at acm.org Sat Jun 11 18:49:07 2005 From: rsenra at acm.org (Rodrigo Dias Arruda Senra) Date: Sat, 11 Jun 2005 13:49:07 -0300 Subject: [Edu-sig] A case against GUIs in intro CS :-) In-Reply-To: <0IHX00LVWGQD9J@mta4.srv.hcvlny.cv.net> References: <20050611123141.2144c738@Goku> <0IHX00LVWGQD9J@mta4.srv.hcvlny.cv.net> Message-ID: <20050611134907.13a3cfab@Goku> [ Arthur ] ----------------------------------------------- | | | > -----Original Message----- | > From: edu-sig-bounces+ajsiegel=optonline.net at python.org [mailto:edu-sig- | > bounces+ajsiegel=optonline.net at python.org] On Behalf Of Rodrigo Dias | > Arruda Senra | > "Avoiding repetition == respect" is an oversimplification to me. | | I don't disagree, really - except that it is near impossible to say anything | that is not an oversimplification. Well, the term 'oversimplification' itself is not an oversimplification. ;o) Just kidding. | And it is maybe because I tend to take that approach, that I tend to | appreciate an author giving his best shot at communicating *a* perspective. I respect that, but that can be quite expensive as well, from book costs POV. Moreover, a good communicator may be capable to convey multiple-perspectives competently. Perhaps that makes more sense in other domains than in math, and maybe that is why we have this different perspectives about it . cheers, Senra -- ,_ | ) Rodrigo Senra |(______ ----------------------------------------------- _( (|__|] GPr Sistemas http://www.gpr.com.br _ | (|___|] Blog http://rodsenra.blogspot.com ___ (|__|] IC - Unicamp http://www.ic.unicamp.br/~921234 L___(|_|] ----------------------------------------------- From andre.roberge at gmail.com Sat Jun 11 21:24:00 2005 From: andre.roberge at gmail.com (=?ISO-8859-1?Q?Andr=E9_Roberge?=) Date: Sat, 11 Jun 2005 16:24:00 -0300 Subject: [Edu-sig] Teaching programming to physics students In-Reply-To: <6.2.1.2.0.20050610104620.03b92b68@127.0.0.1> References: <6.2.1.2.0.20050610104620.03b92b68@127.0.0.1> Message-ID: Peter Bowyer wrote: > Hi, > > For those of you who remember my previous email, I have been given the > go-ahead to do my masters project investigating and developing techniques > to teach programming to second year physics undergraduates at the > University of Southampton. [Snip] > > I'm excited by this project, but starting to feel I've bitten off more than > I can chew, so any advice or suggestions you can make would be great. Do > any of you have existing course material for teaching programming to > physicists (or engineers) or for teaching physics using programming which > you can share? > > I have been requested to provide some coverage of alternative teaching > methods and techniques in my report. If anyone can point me to resources > on this topic I'd be most grateful. > My first suggestion would be to go through the edu-sig archives. :-) Then, I would take a chance and order: Python Scripting for Computational Science Series: Texts in Computational Science and Engineering, Vol. 3 Langtangen, Hans P. The author has a collection of slides here: http://www.ifi.uio.no/in228/lecsplit/ If I may suggest one additional topic (which I didn't see after a quick scan, it would be to explore simple functional programming techniques, and "demonstrate" the fundamental theorem of calculus, as inspired by Kirby. (http://aroberge.blogspot.com/2005/04/computing-derivatives-using-python.html) I wish I had some teaching material to offer you; perhaps in a few years, when I leave the administrative side of academia. Good luck! Andr? From urnerk at qwest.net Sun Jun 12 02:20:03 2005 From: urnerk at qwest.net (urnerk@qwest.net) Date: Sat, 11 Jun 2005 20:20:03 -0400 Subject: [Edu-sig] Elementary School Instruction Message-ID: <102540-2200560120203388@M2W031.mail2web.com> KU> >>> thewords = {'noun1':'house', 'noun2':'mouse'} KU> >>> print "The %(noun2)s is in the %(noun1)s." Aren't these missing the dictionary names in the print statements? -- Best regards, Chuck Yes indeed, you get an A. Now go teach Python grasshopper, there is nothing more I can teach you. Kirby -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web.com/ . From urnerk at qwest.net Sun Jun 12 02:26:21 2005 From: urnerk at qwest.net (urnerk@qwest.net) Date: Sat, 11 Jun 2005 20:26:21 -0400 Subject: [Edu-sig] Not Pi Message-ID: <205700-22005601202621886@M2W085.mail2web.com> Thanks Art, exploring this web site was a fun experience in the humanities. Good to see people still know how to write. Kirby Original Message: ----------------- From: Arthur ajsiegel at optonline.net Date: Sat, 11 Jun 2005 11:15:36 -0400 To: edu-sig at python.org Subject: [Edu-sig] Not Pi Finally a site that captures the essence on interactive web learning. http://www.sock-monkey.com/pi.html Art -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web.com/ . From ajsiegel at optonline.net Sun Jun 12 16:29:38 2005 From: ajsiegel at optonline.net (Arthur) Date: Sun, 12 Jun 2005 10:29:38 -0400 Subject: [Edu-sig] A case against GUIs in intro CS :-) In-Reply-To: <20050611134907.13a3cfab@Goku> Message-ID: <0IHZ002HV6Y473@mta6.srv.hcvlny.cv.net> > From: Rodrigo Dias Arruda Senra [mailto:rsenra at acm.org] > Sent: Saturday, June 11, 2005 12:49 PM > To: Arthur > Cc: edu-sig at python.org > Subject: Re: [Edu-sig] A case against GUIs in intro CS :-) > > Moreover, a good communicator may be capable to convey multiple- > perspectives > competently. Perhaps that makes more sense in other domains than in math, > and maybe that is why we have this different perspectives about it > . Maybe, maybe not. Turns out that I got a little flummoxed trying to make it through "Practical Common Lisp" cover to cover. Backing off, and digesting a few chapters of another Lisp introduction, """ Successful Lisp: How to Understand and Use Common Lisp """ http://psg.com/~dlamkins/sl/ helps immensely. Yes, it could get expensive. Thankfully "Successful Lisp" is available complete online (not my first choice - I'd rather own it, and may eventually.) More generally, the whole idea of approaching Lisp is to get another perspective on programming. Obviously there is no good way to effectively communicate the Lisp perspective from, say, a book on Python. One of the few points of consensus on edu-sig seems to be the usefulness of learning multiple languages as a means to gaining (what I call) dimension, as a programmer. I have read great books on analytic geometry, and great books on synthetic geometry - but no great books giving each approach equal weighting. Its up to me to synergize. In the end, I have yet to understand there to be a great difference with tackling programming and math. Of course I took the approach of in fact learning them together, as one undertaking - adding some cross-dimension to each undertaking. I am leaning toward an unprovable "not" on the thesis that learning and teaching math and programming are truly distinct domains Kirby seems to have an idea or two along these lines. ;) But he and I seemed to have started here with that perspective, seem to maintained it, and seem to be quite unconvincing to many others. But I shouldn't speak for Kirby - noticing him to be fairly capable of speaking for himself ;) Art From ducasse at iam.unibe.ch Sun Jun 12 18:19:12 2005 From: ducasse at iam.unibe.ch (ducasse) Date: Sun, 12 Jun 2005 18:19:12 +0200 Subject: [Edu-sig] [ANN] Have fun programming with your kids Message-ID: Hi If you are a parent, an educator or a programmer having kids this is for you! After 4 years of work, my new book "Squeak: Learn programming with Robots" will be out soon. http://smallwiki.unibe.ch/botsinc/ http://www.amazon.com/exec/obidos/tg/detail/-/1590594916/ qid=1117218524/sr=1-1/ref=sr_1_1/002-5642974-5143261?v=glance&s=books With Bots Inc you will learn how to program robots in an interactive environment. Bots Inc proposes three teaching approaches: direct command of robots, scripting robots and programming robots. The book contains 24 chapters going step by step over topics with a lot of examples. Bots Inc is fun but it is not a toy, it teaches you 100% real programming. Bots Inc is built on top of the rich open-source multimedia Squeak environment that you can also discover. My goal is to explain key elementary programming concepts (such as loops, abstraction, composition, and conditionals) to novices of all ages. I believe that learning by experimenting and solving problems with fun is central to human knowledge acquisition. Therefore, I have presented programming concepts through simple but not trivial problems such as drawing golden rectangles or simulating animal behavior. The ideal reader I have in mind is an individual who wants to have fun programming. This person may be a teenager or an adult, a schoolteacher, or somebody teaching programming to children in some other organization. Such an individual does not have to be fluent in programming in any language. As a father of two young boys I also wrote this book for all the parents that want to have fun programming with their kids in a powerful interactive environment. Programming in Squeak is an interactive, fun but deep experience. The present book teaches elementary programming aspect, the following book will introduce a new fun environment and teach object-oriented programming. Testimonies "I am using the version of the book on your web site to teach my oldest daughter Becca some programming. She absolutely loves it. We are doing the Bot graphics right. My other kids are showing interest as well. My Fall semester schedule leaves me with almost no time free but in the Spring I hope to bring Squeak and your book to our elementary school's "gifted" program." C. David Shaffer "I'm using the Bot Lab environment for three years and found it really valuable in teaching computer science concepts for a young audience (and even less young !). The bots commanded through balloon (as in comic strips) is a very nice introduction for young children, and when this aspect is well understood, you can use the Bot Workspace to teach the notion of script, a first step in programming languages. The Micro Browser allows children to add new behavior for their bots, and have fun with their creation. This three-layers tool - Balloon, Micro Workspace, Micro Browser - offers to the teacher a fun way to introduce gently the basis of object-oriented programming concepts. With Bots Inc, learning is playing ! ;-)" Samir Saidani - University of Caen - France "I recently started a course with 7th-graders (age about 13 years) with Stephane's book --- they love it. They all know about syntactic issues from maths --- in a way they know that an expression in a formal language must be well formed. So they easily grasp the fact such as "there must be a colon after the message-name if an argument follows". Of cause they don't really read the error-messages, they just see "there must be some error" and they remember the simple rules. Don't underestimate Smalltalk --- it's easy understandable because it has a simple and straight-forward design." Klaus Fuller - Germany Have fun... Stef http://www.iam.unibe.ch/~ducasse/ "if you knew today was your last day on earth, what would you do different? ... especially if, by doing something different, today might not be your last day on earth" Calvin&Hobbes From urnerk at qwest.net Mon Jun 13 07:08:50 2005 From: urnerk at qwest.net (Kirby Urner) Date: Sun, 12 Jun 2005 22:08:50 -0700 Subject: [Edu-sig] Explaining Classes and Objects Message-ID: <20050613050852.197D91E4004@bag.python.org> So I'm back to helping Bernie Gunn with Python again. He's in charge of the Geokem web site, where lots of scientific information gets collated -- global data basically, much of it geochemical. The HQS is in New Zealand. I salute Bernie, a relatively old guy, for taking a flying leap to our OO paradigm, coming from a strongly procedural school of thought ala Turbo Pascal. He had it all nailed down in TP, and was producing mega amounts of good graphical data. But now he's thinking ahead, about the long term future of his site, and Python looks like a great candidate. Based on my working with Bernie, I think it's helpful to start early with the class/object distinction. He thinks in terms of graphical objects and is using Zelle's graphics.py to re-explore the world of Rectangles etc. That's a good starting point. He's starting to get that it's object.method(arguments), or noun.verb(inputs). He realizes that: rectobj = Rectangle(...) rectobj.setWidth(10) rectobj.draw() is about initializing a new object of the Rectangle class (defined in graphics.py), and using two of its methods, setWidth and draw. Except both these methods are inherited by Rectangle from GraphicsObject through _BBox. Rectangle itself only defines __init__, clone and the private _draw. OO really is a different world. I think it still makes sense to teach the subject historically, even though we *can* start with objects at the same time. In other words, have students relive some of the trauma of moving from the procedural paradigm to the object oriented one -- not to traumatize, but to give the flavor of what "paradigm" even means (including that switching between them may be difficult). Bernie is getting it, and that's testament to Python's transparent syntax (as well as to my dedication in getting my message across; because I think Bernie, and Geokem, are really cool and deserve Python's support). Kirby From ajsiegel at optonline.net Mon Jun 13 14:21:33 2005 From: ajsiegel at optonline.net (Arthur) Date: Mon, 13 Jun 2005 08:21:33 -0400 Subject: [Edu-sig] Another loop around garphics programming Message-ID: <0II000MQJVMXIE@mta9.srv.hcvlny.cv.net> I had written - >I have read great books on analytic geometry, and great books on synthetic >geometry - but no great books giving each approach equal weighting. Its up >to me to synergize. Thinking about this more carefully - I synergize these perspectives on geometry precisely by learning the skill of programming, providing myself the ability to make analytical geometry actionable in the synthetic realm. Which, in the end, is a fancy way of stating that I taught myself some of the fundamentals of computer graphics programming - just with a bit more "pretense" than is normally brought to the subject. There's gold here, I have no doubt. I reference the authority of Felix Klein. Art From lac at strakt.com Mon Jun 13 14:41:38 2005 From: lac at strakt.com (Laura Creighton) Date: Mon, 13 Jun 2005 14:41:38 +0200 Subject: [Edu-sig] Explaining Classes and Objects In-Reply-To: Message from "Kirby Urner" of "Sun, 12 Jun 2005 22:08:50 PDT." <20050613050852.197D91E4004@bag.python.org> References: <20050613050852.197D91E4004@bag.python.org> Message-ID: <200506131241.j5DCfcXF008787@ratthing-b246.strakt.com> In a message of Sun, 12 Jun 2005 22:08:50 PDT, "Kirby Urner" writes: >OO really is a different world. I think it still makes sense to teach the >subject historically, even though we *can* start with objects at the same >time. In other words, have students relive some of the trauma of moving >from the procedural paradigm to the object oriented one -- not to >traumatize, but to give the flavor of what "paradigm" even means (including >that switching between them may be difficult). This may make sense for people who already know procedureal programming, but I don't think that it is a good idea for the rest of the world. I think that you need to learn about exception handling _early_ ... say right after you learn how to write a loop, and unit testing, and test driven design from the moment you get out of the 'how to play with the interpreter' stage. There isn't a lot of use in teaching people the procedural necessity of doing a huge amount of data validation, and how to deal with the 'cannot happen' of malformed data. It makes for really ugly code -- where it is close to impossible to find out what the code is supposed to do when nothing is wrong, and everything is working properly, because over 80% of it is to detect problems you hope you will never see ... just my 2 cents, Laura From peter at mapledesign.co.uk Mon Jun 13 17:00:40 2005 From: peter at mapledesign.co.uk (Peter Bowyer) Date: Mon, 13 Jun 2005 16:00:40 +0100 Subject: [Edu-sig] Teaching programming to physics students In-Reply-To: References: <6.2.1.2.0.20050610104620.03b92b68@127.0.0.1> Message-ID: <6.2.1.2.0.20050613153234.02432008@127.0.0.1> At 20:24 11/06/2005, Andr? Roberge wrote: >My first suggestion would be to go through the edu-sig archives. :-) Heh, I've been trying but haven't found the search tool too helpful, with few results for 'physics'. Is there an official searchable archive (aka something with a good search index)? Thanks for the book recommendation, I've ordered it from the library. >If I may suggest one additional topic (which I didn't see after a quick >scan, it would be to explore simple functional programming techniques, >and "demonstrate" the fundamental theorem of calculus, >as inspired by Kirby. >(http://aroberge.blogspot.com/2005/04/computing-derivatives-using-python.html) Thanks for the idea, it looks a fun idea to work in. Peter -- Maple Design - quality web design and programming http://www.mapledesign.co.uk From arnd.baecker at web.de Mon Jun 13 17:26:25 2005 From: arnd.baecker at web.de (Arnd Baecker) Date: Mon, 13 Jun 2005 17:26:25 +0200 (CEST) Subject: [Edu-sig] Teaching programming to physics students In-Reply-To: <6.2.1.2.0.20050613153234.02432008@127.0.0.1> References: <6.2.1.2.0.20050610104620.03b92b68@127.0.0.1> <6.2.1.2.0.20050613153234.02432008@127.0.0.1> Message-ID: Hi, we have been running a computational physics course, for the third time by now. All the material given to the students can be found at http://www.comp-phys.tu-dresden.de/cp2005/ However, it is all in German. But still you might get an idea... Best, Arnd From urnerk at qwest.net Mon Jun 13 18:13:55 2005 From: urnerk at qwest.net (Kirby Urner) Date: Mon, 13 Jun 2005 09:13:55 -0700 Subject: [Edu-sig] Explaining Classes and Objects In-Reply-To: <200506131241.j5DCfcXF008787@ratthing-b246.strakt.com> Message-ID: <20050613161356.83EFE1E4005@bag.python.org> > In a message of Sun, 12 Jun 2005 22:08:50 PDT, "Kirby Urner" writes: > > >OO really is a different world. I think it still makes sense to teach > >the subject historically, even though we *can* start with objects at > >the same time. In other words, have students relive some of the trauma > >of moving from the procedural paradigm to the object oriented one -- > >not to traumatize, but to give the flavor of what "paradigm" even means > >(including that switching between them may be difficult). > > > This may make sense for people who already know procedureal programming, > but I don't think that it is a good idea for the rest of the world. I > think that you need to learn about exception handling _early_ ... say > right after you learn how to write a loop, and unit testing, and test > driven design from the moment you get out of the 'how to play with the > interpreter' stage. The average beginner isn't going to know any programming, so why not start with class/object right from the top? Yet the procedural model requires less setup I think, less background. There's no "class hierarchy" to discuss. This is where the parallel experience with math, in algebra, will help, as in Python we have top-level functions, and procedural programming is mainly just organizing the flow in terms of a main procedure branching to and returning from numerous subprocedures e.g.: def main(args): vars = sub1(args) vars = sub2(vars) vars = sub3(vars) return vars Procedural code starts as simply as: def f(x): return x*x My approach is to start with a lot of a rule-based numeric sequences (the above generates square numbers): triangular numbers, Fibonacci numbers, other polyhedral numbers. This means writing a bunch of free-standing functions. But then suddenly you need one to call the other, i.e. when doing tetrahedral numbers, you need to stack consecutive triangles: def tri(n): return n*(n+1)//2 def tetra(n): sum = 0 for i in range(n): sum += tri(i) # <-- function calling function return sum There was an earlier paradigm shift for the first users of procedural languages, such as FORTRAN. Formerly, it was OK to use a very convoluted flow based on GOTO -- lots of jumping around, giving us "spaghetti code." The Dykstra came along and preached the gospel of "structured programming" (more like the above). A lot of programmers fought the idea of a "right" way to do flow. Having listened to more than a couple CS teachers describe their curricula, I'm seeing the procedural-first, OO-next approach is fairly widespread. The good thing about Python though is the OO model is deeply engrained, and just to begin explaining dot-notation is to enter the class/object discussion. What I come to is it's easier to think of objects as something you use, as primitives in the language, within procedural flows. Then take what you've learned about writing functions to write methods and start rolling your own classes. At that point, the full power of the OO model will start to dawn. What you say about getting into exceptions early is food for thought. I think you're probably right. Error handling is where the procedural flow gets especially ugly, what with all those case-based validations (switch statements trying to pin down all the ways a piece of data might be wrong). However, once again I think students may gain a deeper appreciation for exception handling once they've been exposed to the old way of doing it. But that doesn't mean weeks and months of coding in an "obsolete" style. One could go through the history in a short lecture, with projected examples. > There isn't a lot of use in teaching people the procedural necessity of > doing a huge amount of data validation, and how to deal with the 'cannot > happen' of malformed data. It makes for really ugly code -- where it is > close to impossible to find out what the code is supposed to do when > nothing is wrong, and everything is working properly, because over 80% of > it is to detect problems you hope you will never see > ... > > just my 2 cents, > Laura Yes, you've got a point. Validation still consumes lines of code, and we still prompt the user to try again, but the code isn't so gnarly. Kirby From Scott.Daniels at Acm.Org Mon Jun 13 18:16:12 2005 From: Scott.Daniels at Acm.Org (Scott David Daniels) Date: Mon, 13 Jun 2005 09:16:12 -0700 Subject: [Edu-sig] Explaining Classes and Objects In-Reply-To: <20050613050852.197D91E4004@bag.python.org> References: <20050613050852.197D91E4004@bag.python.org> Message-ID: Kirby Urner wrote: > Based on my working with Bernie, I think it's helpful to start early with > the class/object distinction.... > rectobj = Rectangle(...) > rectobj.setWidth(10) > rectobj.draw() > A useful note here: all programmers are _used_ to using objects: The file for I/O is an OS-defined object (without the nifty syntax in such cases). OO provides (A) a way to define abstractions that behave like the file abstraction yourself, and (B) a way to (at least sometimes) define an abstaction that is "just like that other abstraction except." Until you have A, B doesn't make sense. B is hard to teach in that you need to go slowly -- the changes made by inheritance take a while to "get." --Scott David Daniels Scott.Daniels at Acm.Org From radenski at chapman.edu Mon Jun 13 19:55:37 2005 From: radenski at chapman.edu (Radenski, Atanas) Date: Mon, 13 Jun 2005 10:55:37 -0700 Subject: [Edu-sig] Explaining Classes and Objects Message-ID: > From: edu-sig-bounces at python.org [mailto:edu-sig-bounces at python.org] On > Behalf Of Kirby Urner > Sent: Monday, June 13, 2005 9:14 AM [... del...] > The average beginner isn't going to know any programming, so why not start > with class/object right from the top? The Objects First approach has gained popularity among educators and seems to have become a sort of fashion. The idea is, indeed, to start teaching introductory programming with objects and even classes first. My experience is that the Objects First approach is difficult for instructors and students alike. Classes are not a feasible choice to start with because they are a most complex structure in a programming language that builds on knowledge of virtually anything else. Also, starting with classes significantly delays the study of very fundamental language elements. I have seen introductory books that postpone the simple yet indispensable decision structures and loops until as the second half of the book! Postponing basic control structures for so late in a course may deprive students from having fun with writing small yet self-contained and interesting programs. Speaking of myself, if I, when I as a beginner programmer did not know much of control structures until the second part on my course, I would not find programming very interesting. With a dynamic language as Python, it is tempting to try a Statements First approach to introductory programming. This approach may consist of (1) statement-by-statement execution in interactive mode of the Python interpreter and (2) writing statements directly within a module and executing them in file input mode. The learning benefits of interactive programming are indisputable. However, learning how to program by writing modules that are plain sequences of statements may be detrimental to the student's ability to design and write well-structured programs. Python is a language that offers a reasonable *Middle Way* between the Objects First and Statements First approaches. The Middle Way consists of (1) using functions from the very beginning to encapsulate code and structure programs, and (2) introducing control structures as early as possible, but ONLY AS PARTS OF WELL STRUCTURED FUNCTIONS. The Middle Way allows students to write interesting and well-structured programs early in the course, and prepares the ground for classes and objects in the second part of the course. > My approach is to start with a lot of a rule-based numeric sequences (the > above generates square numbers): triangular numbers, Fibonacci numbers, > other polyhedral numbers. This means writing a bunch of free-standing > functions. I do something similar. I start with *sets* with functions. My first program is not hello world, but a module of two Fahrenheit-Celsius converter functions: F2C and C2F (these are not pure functions and do input/print). A transition from modules (that comprise functions but not upper-level statements) to classes comes quite natural at a later stage of the course. > What I come to is it's easier to think of objects as something you use, as > primitives in the language, within procedural flows. Indeed, using built-in objects is simpler than defining and using classes. Still, the concept of objects needs two underlying concepts: variables and method (function) calls. Object variables are not so trivial because object assignment is a reference assignment and therefore creates aliases. Method calls require understanding of arguments and return values. Thus, it is beneficial to study functions, variables, and controls structures for a while, before coming to built-in objects. Personally I believe that lists, dictionaries, and strings offer a great opportunity to introduce objects. There a lot of interesting methods that can be explored interactively and that can be used to write interesting programs. Introducing objects with GUIs is OK, but GUI objects seem to offer fewer opportunities for interactive exploration than lists, dictionaries, and strings. I cover class definitions as a last theme in my CS1 with Python course. The continuation is CS2 with Java, an entirely class-oriented course. No CS2 student has ever complained that classes seem unnatural or difficult to understand. This is because, I believe, classes come at the right time - after all underlying concepts have been well understood. Atanas Radenski mailto:radenski at chapman.edu http://www.chapman.edu/~radenski/ It takes a lot of time to be a genius, you have to sit around so much doing nothing, really doing nothing -- Gertrude Stein From urnerk at qwest.net Mon Jun 13 20:48:08 2005 From: urnerk at qwest.net (Kirby Urner) Date: Mon, 13 Jun 2005 11:48:08 -0700 Subject: [Edu-sig] Explaining Classes and Objects In-Reply-To: Message-ID: <20050613184809.13BF21E4004@bag.python.org> > Classes are not a feasible choice to start with because they are a most > complex structure in a programming language that builds on knowledge of > virtually anything else. > We agree on a lot of points. Because just about any decent Python script makes use of core data structures, such as the list, even if only as a range() return, dot-notation starts to be relevant right from the top. Explaining dot-notation as thing.action(inputs) identifies these "things" as the objects, with dot-notation being a postfix notation for calling, setting and getting. > Indeed, using built-in objects is simpler than defining and using > classes. Still, the concept of objects needs two underlying concepts: > variables and method (function) calls. Object variables are not so > trivial because object assignment is a reference assignment and > therefore creates aliases. Method calls require understanding of > arguments and return values. Thus, it is beneficial to study functions, > variables, and controls structures for a while, before coming to > built-in objects. > Yes, but I still need to explain dot-notation, even in the early days of just doing simple functions. Indeed, I might argue that the simplest intro to conditional flow might be the if clause in list comprehension syntax, i.e. now that we're comfortable with generating in the form [f(x) for x in range(n)], let's now add ... if x%2] or some such. However, the idea of "a list object" should already be in place by this time, i.e. we've looked at [].sort() and so on. Why I'm not so concerned about the fine points of passing by reference, aliases and like that is I'm confidant that class/object thinking is already engrained, simply through exposure to Aristotelian taxonomies. Kids visit the zoo. They understand "cat family" inheriting "mammalian" characteristics, under the kingdom of "animal" (which excludes spinach). So there's your class hierarchy, generic blueprints vs. instances, and individual state variables. Now express that in dot-notation e.g. thetiger.yawns(). In other words, go to the roots of the metaphor and forget about the nitpicky details of computer languages. Come back to that later, but get enough of the concepts to make dot-notation comfortable very early in the game. I'm a philo major, not a CS major, which may account for my willingness to "forget about ... computer languages" from time to time (whenever convenient). > Personally I believe that lists, dictionaries, and strings offer a great > opportunity to introduce objects. There a lot of interesting methods > that can be explored interactively and that can be used to write > interesting programs. Introducing objects with GUIs is OK, but GUI > objects seem to offer fewer opportunities for interactive exploration > than lists, dictionaries, and strings. I'm inclined to agree. On the other hand, I see a need to instill in newcomers that visualization is going to be part of what's coming. They want some assurance up front that graphical content won't be ignored. So sometimes I feel pulled towards GUI-based examples ala John Zelle's graphics.py simply because I know students *want* to go there, and I'm reluctant to resist them. That being said, I don't like doing *only* GUI-based examples. Anyway, IDLE is a GUI, so if you're doing shell in IDLE, you're ipso facto using a GUI (the same could be said of an x-term window). > I cover class definitions as a last theme in my CS1 with Python course. > The continuation is CS2 with Java, an entirely class-oriented course. No > CS2 student has ever complained that classes seem unnatural or difficult > to understand. This is because, I believe, classes come at the right > time - after all underlying concepts have been well understood. > > Atanas Radenski > mailto:radenski at chapman.edu http://www.chapman.edu/~radenski/ > I think this is a viable and likely-to-be-popular approach. Use Python for a first year, then switch gears and get more heavily into OO at the same time, say with Java or C# or... Some will encourage Jython (which I have no problem with -- wish I had more time to play with it). My own framework is based in somewhat different assumptions: pre-college students trying to avoid learning everything twice, once *with* dot-notation and once without. My working hypothesis: the class/object metaphor is useful enough to merit inclusion of dot-notation in mainstream K-12 mathematics. For example, if you want to invert a matrix, write thematrix.invert() -- presuming its invertible. Or you can still write thematrix**(-1) too if you like (operator overloading at your service). So in my course, we're learning about matrices, vectors, polynomials, integers modulo N *as objects*. It's a "programming to learn" course, i.e. the use of Python is a means to an end: a stronger conceptual grasp of various core mathematical ideas, algorithms, ways of approaching a problem. We have yet to clearly differentiate between CS and traditional mathematics at this level (that comes later, when it comes time to specialize). Kirby From Scott.Daniels at Acm.Org Mon Jun 13 21:41:52 2005 From: Scott.Daniels at Acm.Org (Scott David Daniels) Date: Mon, 13 Jun 2005 12:41:52 -0700 Subject: [Edu-sig] Explaining Classes and Objects In-Reply-To: <20050613184809.13BF21E4004@bag.python.org> References: <20050613184809.13BF21E4004@bag.python.org> Message-ID: Kirby Urner wrote: >>Classes are not a feasible choice to start with because they are a most >>complex structure in a programming language that builds on knowledge of >>virtually anything else. >> > > > We agree on a lot of points. > > Because just about any decent Python script makes use of core data > structures, such as the list, even if only as a range() return, dot-notation > starts to be relevant right from the top. Explaining dot-notation as > thing.action(inputs) identifies these "things" as the objects, with > dot-notation being a postfix notation for calling, setting and getting. > > Yes, but I still need to explain dot-notation, even in the early days of > just doing simple functions. > You might try: "These names don't just exist in some primordial soup. There has to be a place they get stored. There is a bit of "magic": import __main__ a = 24 print a, __main__.a __main__.a = 365 print a, __main__.a And even: print a, __main__.a, __main__.__main__.a Now everything is dot notation, with some of the "thing." stuff assumed. Eventually you'll have to say locacal variables don't really work like that, but they are close. --Scott David Daniels Scott.Daniels at Acm.Org From urnerk at qwest.net Mon Jun 13 22:40:15 2005 From: urnerk at qwest.net (Kirby Urner) Date: Mon, 13 Jun 2005 13:40:15 -0700 Subject: [Edu-sig] Explaining Classes and Objects In-Reply-To: Message-ID: <20050613204015.699AE1E4004@bag.python.org> > You might try: "These names don't just exist in some primordial soup. > There has to be a place they get stored. There is a bit of "magic": > import __main__ > a = 24 > print a, __main__.a > __main__.a = 365 > print a, __main__.a > > And even: > > print a, __main__.a, __main__.__main__.a > After which I might go: >>> dir(__main__) ['__builtins__', '__doc__', '__main__', '__name__', 'a'] >>> dir(__builtins__) That'd connect back to Laura's focus on exception handling -- clearly the Error related content in __builtins__ is significant. >>> type(ArithmeticError) >>> dir(ArithmeticError) ['__doc__', '__getitem__', '__init__', '__module__', '__str__'] >>> ArithmeticError.__module__ 'exceptions' >>> EnvironmentError.__module__ 'exceptions' >>> import exceptions >>> dir(exceptions) > Now everything is dot notation, with some of the "thing." stuff assumed. > Eventually you'll have to say locacal variables don't really work like > that, but they are close. > universe.milkyway.sun.earth.hawaii.maui is another way to introduce dot-notation. It's about progressively zooming in, or out, through a succession of progressively more, or less, encompassing domains. This gets us back to the root class/object metaphor, which allows us to appreciate the ordinary interaction of any two objects as involving encapsulation, polymorphism and message-passing i.e. the original SmallTalk paradigm. Kirby > > --Scott David Daniels > Scott.Daniels at Acm.Org > From dcrosta at sccs.swarthmore.edu Mon Jun 13 22:54:34 2005 From: dcrosta at sccs.swarthmore.edu (Dan Crosta) Date: Mon, 13 Jun 2005 16:54:34 -0400 Subject: [Edu-sig] Explaining Classes and Objects In-Reply-To: References: <20050613050852.197D91E4004@bag.python.org> Message-ID: <42ADF28A.3030000@sccs.swarthmore.edu> whoops, sent this reply off-list by accident (apologies to Scott) ---- Here's a thought that just jumped into my mind, I don't know if it has any value, but bear me out: I think it probably makes most sense to introduce programming to totally new people in a procedural/structured/whatever you want to call it way. My feeling is that most people who haven't done any programming think of a computer program as a big list of instructions for what to do, and this model should be pretty easy to introduce to them. Now you start to try to do more compliated things, and you have to start accumulating global state so that your many functions can do meaningful things without having to pass loads of arguments around. Pretty soon, depending on the topic, you probably want a way to group global variables together -- the first approach might be to name them similarly, like foo_bar and foo_baz for bar and baz relating to foo. But what if you have two different things of type foo? Now introduce objects as essentially structs. You have a class definition, like: class Foo: bar = someDefault baz = someDefault and just work with that for a while. Now, you are passing around Foo's as arguments to your functions, and you realize that certain functions can only work on Foo's, while others can only work on OtherThing's. Isn't it logical to group your functions in the same way as your variables? Oh, look, thats object-orientation (or the core of it), and you got there all on your own. My experience as a student has been that the best teachers are the ones who give you all but the conclusion, and let you make the final leap yourself. That, I think, makes the knowledge both more likely to stick, and the excercise (which is probably at least somewhat artificial, as most exercies tend to be) more exciting, as you feel like you're making a new contribution to how it all works. Anyway, that's roughly how I had been introduced to OO programming over the years: first BASIC, learning the, well, basics, of program organization with sub's; next, larger scale programs, maybe in C, organizing static members and functions into files; soon structs; then full-on OO with Java (which I loathe), and later Python and C++. Just my $0.02 dsc From lac at strakt.com Tue Jun 14 01:40:30 2005 From: lac at strakt.com (Laura Creighton) Date: Tue, 14 Jun 2005 01:40:30 +0200 Subject: [Edu-sig] Explaining Classes and Objects In-Reply-To: Message from "Kirby Urner" of "Mon, 13 Jun 2005 09:13:55 PDT." <200506131613.j5DGDtIt020441@theraft.strakt.com> References: <200506131613.j5DGDtIt020441@theraft.strakt.com> Message-ID: <200506132340.j5DNeUeb011100@theraft.strakt.com> It may be that I have the joy of teaching 10 year olds, and you have to deal with more experienced folk. raise "that was stupid!" #translate that into your language has enormous 'teacher-as-hero' value around here. I know all the arguments as to why string exceptions should be removed from python. I even agree with them. But raise 'you are an idiot!' in some circles has its own sort of charm .... Laura ps -- i am not entirely sold on oo programming. clearly it is the correct way to model certain problems, but a more functional approach seems better suited to other kinds. I think teaching TDD is more important than OO these days. Am I only reflecting my own loves and predjudice? In a message of Mon, 13 Jun 2005 09:13:55 PDT, "Kirby Urner" writes: >> In a message of Sun, 12 Jun 2005 22:08:50 PDT, "Kirby Urner" writes: >> >> >OO really is a different world. I think it still makes sense to teach >> >the subject historically, even though we *can* start with objects at >> >the same time. In other words, have students relive some of the traum >a >> >of moving from the procedural paradigm to the object oriented one -- >> >not to traumatize, but to give the flavor of what "paradigm" even mean >s >> >(including that switching between them may be difficult). >> >> >> This may make sense for people who already know procedureal programming >, >> but I don't think that it is a good idea for the rest of the world. I >> think that you need to learn about exception handling _early_ ... say >> right after you learn how to write a loop, and unit testing, and test >> driven design from the moment you get out of the 'how to play with the >> interpreter' stage. > >The average beginner isn't going to know any programming, so why not star >t >with class/object right from the top? > >Yet the procedural model requires less setup I think, less background. >There's no "class hierarchy" to discuss. > >This is where the parallel experience with math, in algebra, will help, a >s >in Python we have top-level functions, and procedural programming is main >ly >just organizing the flow in terms of a main procedure branching to and >returning from numerous subprocedures e.g.: > >def main(args): > vars = sub1(args) > vars = sub2(vars) > vars = sub3(vars) > return vars > >Procedural code starts as simply as: > >def f(x): > return x*x > >My approach is to start with a lot of a rule-based numeric sequences (the >above generates square numbers): triangular numbers, Fibonacci numbers, >other polyhedral numbers. This means writing a bunch of free-standing >functions. But then suddenly you need one to call the other, i.e. when >doing tetrahedral numbers, you need to stack consecutive triangles: > >def tri(n): > return n*(n+1)//2 > >def tetra(n): > sum = 0 > for i in range(n): > sum += tri(i) # <-- function calling function > return sum > >There was an earlier paradigm shift for the first users of procedural >languages, such as FORTRAN. Formerly, it was OK to use a very convoluted >flow based on GOTO -- lots of jumping around, giving us "spaghetti code." >The Dykstra came along and preached the gospel of "structured programming >" >(more like the above). A lot of programmers fought the idea of a "right" >way to do flow. > >Having listened to more than a couple CS teachers describe their curricul >a, >I'm seeing the procedural-first, OO-next approach is fairly widespread. >The >good thing about Python though is the OO model is deeply engrained, and j >ust >to begin explaining dot-notation is to enter the class/object discussion. > What I come to is it's easier to think of objects as something you use, as >primitives in the language, within procedural flows. Then take what you' >ve >learned about writing functions to write methods and start rolling your o >wn >classes. At that point, the full power of the OO model will start to daw >n. > >What you say about getting into exceptions early is food for thought. I >think you're probably right. Error handling is where the procedural flow >gets especially ugly, what with all those case-based validations (switch >statements trying to pin down all the ways a piece of data might be wrong >). > >However, once again I think students may gain a deeper appreciation for >exception handling once they've been exposed to the old way of doing it. >But that doesn't mean weeks and months of coding in an "obsolete" style. >One could go through the history in a short lecture, with projected >examples. > >> There isn't a lot of use in teaching people the procedural necessity of >> doing a huge amount of data validation, and how to deal with the 'canno >t >> happen' of malformed data. It makes for really ugly code -- where it i >s >> close to impossible to find out what the code is supposed to do when >> nothing is wrong, and everything is working properly, because over 80% >of >> it is to detect problems you hope you will never see >> ... >> >> just my 2 cents, >> Laura > >Yes, you've got a point. Validation still consumes lines of code, and we >still prompt the user to try again, but the code isn't so gnarly. > >Kirby > From chuck at freshsources.com Tue Jun 14 05:48:24 2005 From: chuck at freshsources.com (Chuck Allison) Date: Mon, 13 Jun 2005 21:48:24 -0600 Subject: [Edu-sig] Explaining Classes and Objects In-Reply-To: References: <20050613050852.197D91E4004@bag.python.org> Message-ID: <623791511.20050613214824@freshsources.com> Hello Scott, Monday, June 13, 2005, 10:16:12 AM, you wrote: SDD> Kirby Urner wrote: >> Based on my working with Bernie, I think it's helpful to start early with >> the class/object distinction.... >> rectobj = Rectangle(...) >> rectobj.setWidth(10) >> rectobj.draw() >> SDD> A useful note here: all programmers are _used_ to using objects: SDD> The file for I/O is an OS-defined object (without the nifty syntax SDD> in such cases). OO provides (A) a way to define abstractions that SDD> behave like the file abstraction yourself, and (B) a way to (at SDD> least sometimes) define an abstaction that is "just like that other SDD> abstraction except." Until you have A, B doesn't make sense. B SDD> is hard to teach in that you need to go slowly -- the changes made SDD> by inheritance take a while to "get." They're used to using objects in real life, but they're not used to having scaffolding when it's not needed. Case in point: class Hello { public static void main(String[] args) { System.out.println("Hello"); } } What's a beginner supposed to do with this Java program? What's "public?" "static?" "void?" etc. Of course: print 'Hello' they can handle just fine. After a little experience with the interpreter, they can easily pick up methods: words = s.split() They just grok immediately that what follows the dot pertains to what is before it. This is a perfect lead-in to real classes. After having taught C, C++, and Java for years, and mathematics for decades, my 2 cents are: 1) Start with what they know from real life (numbers, simple computations, text processing), in this sense, you begin "procedural" to some degree 2) Python is the best thing I've seen in 30 years of computing for pedogogical and productive purposes. Only when I want speed do I see a need for something else (I'm a C++ guy). As I predicted last week, my current corporate teaching of Python at Symantec is exceeding expectations. I am teaching testers, mostly with no programming experience, Python programming. Man are we smokin'! Man are they going fast! And they are *so* impressed. We just finished our third 4-hour session with list comprehensions and all about dictionaries (every method, including iterators). After modules we'll hit classes. This has been one of the easiest and most rewarding teaching experiences in my career. Even those who have a little Python exposure are amazed when they see truly Pythonic solutions. Python lets you start where people are and naturally proceed to higher-level abstractions. But wait at least until the 4th or 5th day before you do classes :-). -- Best regards, Chuck From chandrakirti at gmail.com Tue Jun 14 11:24:01 2005 From: chandrakirti at gmail.com (Lloyd Hugh Allen) Date: Tue, 14 Jun 2005 05:24:01 -0400 Subject: [Edu-sig] Explaining Classes and Objects In-Reply-To: <623791511.20050613214824@freshsources.com> References: <20050613050852.197D91E4004@bag.python.org> <623791511.20050613214824@freshsources.com> Message-ID: <24d253d90506140224bc0cdd6@mail.gmail.com> On 6/13/05, Chuck Allison wrote: ... > they can handle just fine. After a little experience with the > interpreter, they can easily pick up methods: > > words = s.split() ... I believe that "dir( )", when combined with an interactive shell, is the most powerful command in Python. For an example, I made an apparently overly-complicated database to interpret my school's records. When I was trying to figure out which rooms were used by which teachers (in both directions--room by teacher and teacher by room), I started by doing dir(school) to remember what my categories had been, and then eventually figured out what I could loop over and what attribute I wanted. I eventually remembered that school.classes.periods.teachers could be compared to school.classes.periods.rooms in order to come up with what I wanted. This is also how I explore modules with which I am not familiar, and one of the first things I ask my students to do is to import math dir(math) From john.zelle at wartburg.edu Tue Jun 14 16:48:03 2005 From: john.zelle at wartburg.edu (John Zelle) Date: Tue, 14 Jun 2005 09:48:03 -0500 Subject: [Edu-sig] Updated graphics library Message-ID: <42AEEE23.8020001@wartburg.edu> Hello all, For those of you who use my graphics.py library for teaching, I wanted to let you know that I've just released an update to version 3.2. This version has two important improvements over the last release (3.0): 1. Significantly improved performance of communication with the Tk thread. 2. A new Pixmap object that can be used for simple image manipulation programs. Pixmap is a wrapper around the TK photoimage class and allows creation and manipulation of gif, ppm, and bitmap graphics files through setPixel and getPixel methods. As usual, the package and updated documentation are available at: http://mcsp.wartburg.edu/zelle/python The threading updates have been fairly well tested at this point, as we've used them already in a CS1 class. The Pixmap object is not as extensively tested, but it's so simple that I feel it is ready for release. Id' be happy to hear any feedback (good or bad). --John -- John M. Zelle, Ph.D. Wartburg College Professor of Computer Science Waverly, IA john.zelle at wartburg.edu (319) 352-8360 From urnerk at qwest.net Tue Jun 14 17:23:10 2005 From: urnerk at qwest.net (Kirby Urner) Date: Tue, 14 Jun 2005 08:23:10 -0700 Subject: [Edu-sig] Explaining Classes and Objects In-Reply-To: <24d253d90506140224bc0cdd6@mail.gmail.com> Message-ID: <20050614152311.D7C1D1E4002@bag.python.org> > This is also how I explore modules with which I am not familiar, and > one of the first things I ask my students to do is to > > import math > dir(math) Plus there's help, is in >>> help('math') # don't even need to import first if you don't want Kirby From urnerk at qwest.net Tue Jun 14 17:29:25 2005 From: urnerk at qwest.net (Kirby Urner) Date: Tue, 14 Jun 2005 08:29:25 -0700 Subject: [Edu-sig] Explaining Classes and Objects In-Reply-To: <200506132340.j5DNeUeb011100@theraft.strakt.com> Message-ID: <20050614152926.36E131E4002@bag.python.org> Laura Creighton: > I think teaching TDD is more important than OO these days. Am I > only reflecting my own loves and predjudice? I agree the TDD (test driven development) is getting a lot of focus these days. I don't regard TDD and OO as mutually exclusive though -- possible to learn both -- at the same time even. Kirby From dyoo at hkn.eecs.berkeley.edu Tue Jun 14 19:26:13 2005 From: dyoo at hkn.eecs.berkeley.edu (Danny Yoo) Date: Tue, 14 Jun 2005 10:26:13 -0700 (PDT) Subject: [Edu-sig] Explaining Classes and Objects In-Reply-To: <200506132340.j5DNeUeb011100@theraft.strakt.com> Message-ID: > ps -- i am not entirely sold on oo programming. clearly it is the > correct way to model certain problems, but a more functional approach > seems better suited to other kinds. > > I think teaching TDD is more important than OO these days. Am I only > reflecting my own loves and predjudice? Hi Laura, If so, it's a prejudice that's shared by a few other people. *grin* Oleg Kiselyov has a paper called "Subclassing errors, OOP, and practically checkable rules to prevent them": http://okmij.org/ftp/Computation/Subtyping/ where he brings up the idea that subclassing can be tricky, and that OOP in general can be more complex just because one has to hold a class hierarchy in one's head to know exactly what's going on. One of the references in his paper is also interesting: http://research.microsoft.com/Users/luca/Papers/BadPropertiesOfOO.html The attributes of a good "engineering language" in Luca's terms might not necessarily be an ideal "teaching language". But I think it's useful to read some of the criticism from the procedural side of things, to better understand the strengths and weaknesses of OOP. Best of wishes to you! From urnerk at qwest.net Tue Jun 14 22:49:46 2005 From: urnerk at qwest.net (Kirby Urner) Date: Tue, 14 Jun 2005 13:49:46 -0700 Subject: [Edu-sig] Explaining Classes and Objects In-Reply-To: Message-ID: <20050614204946.7DD1C1E4028@bag.python.org> Here's an approach to learning dot-notation: take common household appliances that have user controls, and implement them as Python classes. For example, a TV typically has a volume control that goes louder and quieter, but doesn't allow numeric inputs, and doesn't exceed upper and lower bounds. The channel control typically goes "around the dial" meaning you can use the "higher" or "lower" direction (here symbolized with "+" and "-") to go around and around -- *or* you may enter the channel number directly. Adjusting volume and/or channel only makes sense if the TV is on. I've tried to capture the above logic in the class definition below. I'm using a variety of techniques, including some exception handling and type checking around input validation. Various conditionals, but no loops. All the state variables are private. The user is supposed to use the __repr__ method to get a state report. This design is not very friendly to external classes -- but why should it be? It's simulating a TV, which is pretty much a closed box from the user's point of view. Typical session: >>> from hhobjects import TV >>> mytv1 = TV('Bedroom') >>> mytv2 = TV('Living Room') # two TVs makes the object/class distinction >>> mytv1.power() >>> mytv1.volume('+') >>> mytv2.channel(3) # ...each TV has its own state TV Living Room is turned off >>> mytv2.power() >>> mytv2.channel(3) >>> mytv2 TV Living Room: power: on channel: 3 volume: 0 >>> mytv1 TV Bedroom: power: on channel: 0 volume: 1 >>> mytv1.channel('-') >>> mytv1 TV Bedroom: power: on channel: 99 volume: 1 If doing this in a classroom, we might have students interact with the TV class for awhile, then start looking at source code. In a more advanced class, we might specify the API, and ask students for their own class definitions. Intermediate level: the code below could be improved with some refactoring, plus we'd like a brightness control -- go for it. Next lesson: "how to pickle your television for later" Kirby ==== class TV: """ Simulate TV with power, channel, volume controls """ channels = 100 # range is 0-99 def __init__(self, label): """ Initialize a TV with power off """ self.label = label self._power = 'off' self._channel = 0 self._volume = 0 def power(self): """ Power is an on/off toggle """ if self._power == 'on': self._power = 'off' else: self._power = 'on' def _checkpower(self): """ Channel or volume changes are inactive if power is off """ try: assert self._power=='on' except: print "TV %s is turned off" % self.label return False return True def volume(self, val): """ Volume may go one notch higher or lower within range, will not exceed limits """ try: assert type(val)==type("") and val in '+-' except: print "+ or -" return if self._checkpower(): if self._volume > 0 and val == '-': self._volume -= 1 if self._volume < 10 and val == '+': self._volume += 1 def channel(self, val): """ Channel may go higher or lower, or supports direct entry of channel number. Going higher over the top, or below 0, takes you "around the dial" """ if self._checkpower(): if type(val)==type(1): try: assert TV.channels >= val >= 0 except: print "Channel out of range." self._channel = val elif val == '-': self._channel = (self._channel - 1) % TV.channels elif val == '+': self._channel = (self._channel + 1) % TV.channels else: print "+, -, or channel number" def __repr__(self): """ Used for checking state. TV does not want users directly accessing its internal state variables """ if self._power == 'on': return "TV %s: power: %s channel: %s volume: %s" \ % (self.label, self._power, self._channel, self._volume) if self._power == 'off': return "TV %s: power: %s" % (self.label, self._power) From chuck at freshsources.com Wed Jun 15 01:16:09 2005 From: chuck at freshsources.com (Chuck Allison) Date: Tue, 14 Jun 2005 17:16:09 -0600 Subject: [Edu-sig] Explaining Classes and Objects In-Reply-To: <42ADF28A.3030000@sccs.swarthmore.edu> References: <20050613050852.197D91E4004@bag.python.org> <42ADF28A.3030000@sccs.swarthmore.edu> Message-ID: <776562828.20050614171609@freshsources.com> Hello Dan, What you have done here is recap the journey from C to object-based C idioms to C++. This is what happened to me in the 80s. It's a very natural progression. Fortunately, we can short-cut it tremendously for students, but it's still a journey worth taking. Monday, June 13, 2005, 2:54:34 PM, you wrote: DC> whoops, sent this reply off-list by accident (apologies to Scott) DC> ---- DC> Here's a thought that just jumped into my mind, I don't know if it has DC> any value, but bear me out: DC> I think it probably makes most sense to introduce programming to totally DC> new people in a procedural/structured/whatever you want to call it way. DC> My feeling is that most people who haven't done any programming think of DC> a computer program as a big list of instructions for what to do, and DC> this model should be pretty easy to introduce to them. DC> Now you start to try to do more compliated things, and you have to start DC> accumulating global state so that your many functions can do meaningful DC> things without having to pass loads of arguments around. Pretty soon, DC> depending on the topic, you probably want a way to group global DC> variables together -- the first approach might be to name them DC> similarly, like foo_bar and foo_baz for bar and baz relating to foo. But DC> what if you have two different things of type foo? DC> Now introduce objects as essentially structs. You have a class DC> definition, like: DC> class Foo: DC> bar = someDefault DC> baz = someDefault DC> and just work with that for a while. Now, you are passing around Foo's DC> as arguments to your functions, and you realize that certain functions DC> can only work on Foo's, while others can only work on OtherThing's. DC> Isn't it logical to group your functions in the same way as your DC> variables? Oh, look, thats object-orientation (or the core of it), and DC> you got there all on your own. DC> My experience as a student has been that the best teachers are the ones DC> who give you all but the conclusion, and let you make the final leap DC> yourself. That, I think, makes the knowledge both more likely to stick, DC> and the excercise (which is probably at least somewhat artificial, as DC> most exercies tend to be) more exciting, as you feel like you're making DC> a new contribution to how it all works. DC> Anyway, that's roughly how I had been introduced to OO programming over DC> the years: first BASIC, learning the, well, basics, of program DC> organization with sub's; next, larger scale programs, maybe in C, DC> organizing static members and functions into files; soon structs; then DC> full-on OO with Java (which I loathe), and later Python and C++. DC> Just my $0.02 DC> dsc DC> _______________________________________________ DC> Edu-sig mailing list DC> Edu-sig at python.org DC> http://mail.python.org/mailman/listinfo/edu-sig -- Best regards, Chuck From urnerk at qwest.net Wed Jun 15 01:43:43 2005 From: urnerk at qwest.net (urnerk@qwest.net) Date: Tue, 14 Jun 2005 19:43:43 -0400 Subject: [Edu-sig] A footnote in time saves nine Message-ID: <170940-220056214234343300@M2W091.mail2web.com> In: http://mail.python.org/pipermail/edu-sig/2000-August/000599.html I often talk about ?relative primes? i.e. two numbers with no factors in common. At some point, a poster to sci.math took me to task for proffering ?relative primes? as a term, since the regular usage is ?relatively prime.? Two numbers are ?relatively prime? not ?relative primes.? Yeah, sci.math is like that. :-D Kirby -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web.com/ . From tim.peters at gmail.com Wed Jun 15 02:04:42 2005 From: tim.peters at gmail.com (Tim Peters) Date: Tue, 14 Jun 2005 20:04:42 -0400 Subject: [Edu-sig] A footnote in time saves nine In-Reply-To: <170940-220056214234343300@M2W091.mail2web.com> References: <170940-220056214234343300@M2W091.mail2web.com> Message-ID: <1f7befae0506141704430c5f90@mail.gmail.com> [Kirby Urner] > In: > > http://mail.python.org/pipermail/edu-sig/2000-August/000599.html > > I often talk about "relative primes" i.e. two numbers with no factors in > common. > > At some point, a poster to sci.math took me to task for proffering > "relative primes" as a term, since the regular usage is "relatively prime." > Two numbers are "relatively prime" not "relative primes." > > Yeah, sci.math is like that. :-D Luckily, you can call them "coprime" instead, and not even piss _me_ off : http://en.wikipedia.org/wiki/Coprime From chuck at freshsources.com Thu Jun 16 04:56:45 2005 From: chuck at freshsources.com (Chuck Allison) Date: Wed, 15 Jun 2005 20:56:45 -0600 Subject: [Edu-sig] [Fwd: Quick Question] Message-ID: <42B0EA6D.5050202@freshsources.com> Dear EDU-SIG: Here is a question from a client I'm teaching a beginning Python class to. If you have a quick answer it would be *greatly* appreciated! -- Chuck Allison -------------- next part -------------- An embedded message was scrubbed... From: Johan Jeffery Subject: Quick Question Date: Wed, 15 Jun 2005 18:30:55 -0600 Size: 3681 Url: http://mail.python.org/pipermail/edu-sig/attachments/20050615/f5c99902/QuickQuestion.eml From chuck at freshsources.com Thu Jun 16 05:21:04 2005 From: chuck at freshsources.com (Chuck Allison) Date: Wed, 15 Jun 2005 21:21:04 -0600 Subject: [Edu-sig] [Fwd: Quick Question] In-Reply-To: <42B0EA6D.5050202@freshsources.com> References: <42B0EA6D.5050202@freshsources.com> Message-ID: <42B0F020.4050906@freshsources.com> Oops - wrong forum. Sorry. Chuck Allison wrote: > Dear EDU-SIG: > > Here is a question from a client I'm teaching a beginning Python class > to. If you have a quick answer it would be *greatly* appreciated! > > -- Chuck Allison > > ------------------------------------------------------------------------ > > Subject: > Quick Question > From: > Johan Jeffery > Date: > Wed, 15 Jun 2005 18:30:55 -0600 > To: > chuck at freshsources.com > > To: > chuck at freshsources.com > > > > Quick question since the next class isn't until Monday. Do you know > of any modules in Python that can convert a bitmap from one format to > another, specifically .BMPs to .JPGs? > > We have a need to do this conversion. Our developers have grown fond > of screen shots as they give much information that may not be written > up in a bug. However, our most common tool for getting a screen shot > is a screen capture in VMWare which only does .BMP format files. They > are about 2.3 Mb apiece. Where as a .JPG of the same thing is only > about 34 - 175 Kb. The space savings is significant. So, we need a > way of efficiently convert these screenshots. This class presents me > an opportunity to create a utility to do this for us. Hence, the > question. > > Thanks! > > - Johan > >------------------------------------------------------------------------ > >_______________________________________________ >Edu-sig mailing list >Edu-sig at python.org >http://mail.python.org/mailman/listinfo/edu-sig > > From delza at livingcode.org Thu Jun 16 06:50:20 2005 From: delza at livingcode.org (Dethe Elza) Date: Wed, 15 Jun 2005 21:50:20 -0700 Subject: [Edu-sig] [Fwd: Quick Question] In-Reply-To: <42B0EA6D.5050202@freshsources.com> References: <42B0EA6D.5050202@freshsources.com> Message-ID: The standard python way to do this is via the Python Imaging Library (PIL)[1]. The standard unix way of doing this is via ImageMagick[2], which can easily be called from python if it is installed. There are other ways which are more platform dependent. HTH. --Dethe [1] http://www.pythonware.com/products/pil/ [2] http://www.imagemagick.org/script/index.php On 15-Jun-05, at 7:56 PM, Chuck Allison wrote: > Dear EDU-SIG: > > Here is a question from a client I'm teaching a beginning Python > class to. If you have a quick answer it would be *greatly* > appreciated! > > -- Chuck Allison > > From: Johan Jeffery > Date: June 15, 2005 5:30:55 PM PDT (CA) > To: chuck at freshsources.com > Subject: Quick Question > > > > > Quick question since the next class isn't until Monday. Do you > know of any modules in Python that can convert a bitmap from one > format to another, specifically .BMPs to .JPGs? > > We have a need to do this conversion. Our developers have grown > fond of screen shots as they give much information that may not be > written up in a bug. However, our most common tool for getting a > screen shot is a screen capture in VMWare which only does .BMP > format files. They are about 2.3 Mb apiece. Where as a .JPG of > the same thing is only about 34 - 175 Kb. The space savings is > significant. So, we need a way of efficiently convert these > screenshots. This class presents me an opportunity to create a > utility to do this for us. Hence, the question. > > Thanks! > > - Johan > > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig > > What dark passions and ancient evils have been held in check by the grim totalitarianism of the profit motive? --Bruce Sterling From urnerk at qwest.net Fri Jun 17 00:22:58 2005 From: urnerk at qwest.net (Kirby Urner) Date: Thu, 16 Jun 2005 15:22:58 -0700 Subject: [Edu-sig] Recent projects Message-ID: <20050616222300.7776C1E4040@bag.python.org> 1. Rational Number Class and Continued Fractions I went back and redid a Rational class (again!) and fed it to a continued fractions procedure (I know there's a non-recursive one that's cool -- I think Tim Peters showed me it years ago). Golden Mean = Phi = the fraction: 453973694165307953197296969697410619233826 ------------------------------------------ 280571172992510140037611932413038677189525 (approximately). See link: The pedagogy of "how things work" (Math Forum thread) at my http://www.4dsolutions.net/ocn/cp4e.html 2. Jython + POV-Ray I had occasion to use Jython: the old Qhull algorithm for finding a convex hull has been implemented in Java by John Lloyd. This means I could conflate what had been two programs (Python + Qhull) into one (Jython). Of course I still need POV-Ray to render the results. See link: http://www.4dsolutions.net/ocn/wgraphics4.html * * * The Jython piece will probably feature in my talk at OSCON, which is about how the Open Source community, Python's in particular, has benefited the Design Science community (see talk description for details). Waterman polyhedra have been one of our research topics for some years. Kirby From daveb at davebsoft.com Fri Jun 17 08:26:28 2005 From: daveb at davebsoft.com (Dave Briccetti) Date: Thu, 16 Jun 2005 23:26:28 -0700 Subject: [Edu-sig] Python at grades 5-9 summer program Message-ID: <42B26D14.4000804@davebsoft.com> Hi all. I'm pleased that I've finally discovered what a great resource Edu-sig is. I've read selected threads back to December and I'm very impressed with the people here. I met Guido van Rossum at this talk back in Oct 2003: http://www.stanford.edu/class/ee380/Abstracts/031029.html I told Guido I would be teaching Python to kids in Summer 2004, and he suggested I come here. I think I took a quick peek, but it wasn't really until tonight that I've spent a few hours and gotten to know some of you through your postings. I've been a professional programmer since 1978, and a self-employed consultant since 1983. These days I work mostly in Java on Linux, Windows, and MacOS X. In the summers I teach for six weeks at a community college program for grades 5-9 in Pleasant Hill, California (not far from San Francisco). Over the years I've taught QBASIC, Visual Basic, C++, and Java. Several years ago I started attending open-to-the-public lectures at Stanford and PARC, such as this talk by Alan Kay: http://hci.stanford.edu/cs547/abstracts/02-03/030425-kay.html The more I heard brilliant computer scientists such as Kay talk, the more convinced I became that teaching kids Visual Basic was not a good thing. (By the way, there's a funny line from Kay in the video of that talk. He's lamenting the current state of affairs in computer science at universities. He says, "And here I sit in the oxymoronically-named 'Gates Computer Science' Building....") An IBM researcher friend of mine suggested I teach Python as a beginner language and so last summer I did. And it was a huge success! Next week I start teaching it for Summer 2005. A few weeks ago I got an email from an adult who is a friend of a student who will be in my Python class this year. The man works in industry, and wanted to know why I would teach Python and not Visual C++. He said he was "revolted" by the idea, or something like that. I was annoyed, but politely responded that I thought Python was a better language for teaching beginners, is free, is cross platform; that I wasn't a factory for the next generation of Microsoft programmers, etc. He persisted, suggesting that I'm some tired old professor who was just teaching what he knows instead of something useful. At this point I withdrew from the conversation, with the funny saying coming to mind: "Never try to teach a pig to sing...." Anyway, after spending the last several hours reading your posts here, I'm ever so convinced that I'm doing the right thing for these kids. I look forward to getting to know many of you, and becoming a better teacher for it. Perhaps I'll have some ideas to share with you. Dave Briccetti Dave Briccetti Software Consulting, Lafayette, California www.davebsoft.com, http://davebsoft.com/cfk/ Diablo Valley College, College for Kids Program http://www.dvc.edu/college4kids/ From shugarma at chapman.edu Wed Jun 15 22:35:17 2005 From: shugarma at chapman.edu (Shugarman, Arnold) Date: Wed, 15 Jun 2005 13:35:17 -0700 Subject: [Edu-sig] Python Workshop at Chapman University Message-ID: Chapman University is conducting a summer workshop, "Teaching Introductory Computer Science: The Python Way" for computer science teachers who want an alternative to either purely commercial languages, such as Java or C++, or purely educational languages, such as Scheme, for introductory computer science courses. The instructor, Professor Atanas Radenski has successfully used Python in the first semester introductory computer science course and Java in the second semester at Chapman University with increased student interest and comprehension of programming principles. Professor Radenski has developed comprehensive online study packs to support his courses. The online study packs substantially reduce the instructor's work load in two ways. First, the online study packs offer a variety of detailed self-guided labs that most students can do by themselves, without any, or with very little, help from the instructor. Second, the online study packs support a self-evaluation honor system based on online quizzes and lab reports which considerably reduces the amount of tedious grading. The program is designed for high school computer science instructors. College and university faculty will also benefit from learning about this dual language approach to teaching introductory computer science. Prior knowledge of the Python language is not required. The workshop consists of a three-day program on the Chapman campus, August 10 - 12, 2005, and an on-line program of web study-packs that can be completed any time between August 13 - December 15, 2005. The on-line portion of the workshop will require about 20 to 30 hours to complete. Please see http://www.chapman.edu/wcls/MathCS/sWorkshop/Python/default.asp for complete details on the Python workshop and an on-line registration form. Or contact Arnold Shugarman (Shugarman at chapman.edu ) for more information. Arnold Shugarman Arnold L. Shugarman, Ph.D. Administrator, Integrated Circuit & Embedded System Design Department of Mathematics and Computer Science Beckman 403 Chapman University One University Drive Orange, CA 92866 714-744-7862 714-628-7340 (fax) 714-206-6136 (cell) shugarman at chapman.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20050615/06d738e4/attachment.htm From david at handysoftware.com Fri Jun 17 18:11:31 2005 From: david at handysoftware.com (David Handy) Date: Fri, 17 Jun 2005 12:11:31 -0400 Subject: [Edu-sig] Python at grades 5-9 summer program In-Reply-To: <42B26D14.4000804@davebsoft.com> References: <42B26D14.4000804@davebsoft.com> Message-ID: <20050617161131.GA7676@arno2> On Thu, Jun 16, 2005 at 11:26:28PM -0700, Dave Briccetti wrote: > Hi all. I'm pleased that I've finally discovered what a great resource > Edu-sig is. Hi Dave, welcome aboard. > I've been a professional programmer since 1978, and a self-employed > consultant since 1983. These days I work mostly in Java on Linux, Windows, > and MacOS X. In the summers I teach for six weeks at a community college > program for grades 5-9 in Pleasant Hill, California (not far from San > Francisco). Over the years I've taught QBASIC, Visual Basic, C++, and > Java. You sound like a man after my own heart. Professional software developer with a desire to teach young people. Me too. In fact this week I sat down with my 8 and 11 year old sons and taught them binary arithmetic and logic design (AND, OR, and NOT gates) just like my father taught me when I was 10...it's a generational thing. > A few weeks ago I got an email from an adult who is a friend of a student > who will be in my Python class this year. The man works in industry, and > wanted to know why I would teach Python and not Visual C++... suggesting > that I'm some tired old professor who was just teaching what he knows > instead of something useful. I'm rolling on the floor laughing! Python boosts productivity more than 4x over C++ for me and thousands of other developers and that's not useful? Sounds like he's the one stubbornly sticking with the things he knows instead of learning things that are new and different. I'm not worried about folks like that, let them have their own opinions. What bothers me though is that I'm meeting young people who have been influenced by folks like that. They want to skip Python and go straight to C++ because that's what they think "cool" game developers do. They've got to understand that games they think are so "cool" are written by teams that consist of 3 to 5 programmers and 50 or more graphic artists, designers, etc. working full time for a long time with costs in the millions. They want so much to impress their peers, their teacher, etc. They need to understand that people will be a lot more impressed by something that's funny and original that they did themselves in Python and it actually runs vs. something they attempted in C++ and it would have been the next Starcraft only they never got it finished or working. That's the beauty of Python -- your success rate goes way up. Anyway, welcome again to EDU-SIG. David Handy Computer Programming is Fun! http://www.handysoftware.com/cpif/ From daveb at davebsoft.com Sat Jun 18 06:55:49 2005 From: daveb at davebsoft.com (Dave Briccetti) Date: Fri, 17 Jun 2005 21:55:49 -0700 Subject: [Edu-sig] Python at grades 5-9 summer program In-Reply-To: <20050617161131.GA7676@arno2> References: <42B26D14.4000804@davebsoft.com> <20050617161131.GA7676@arno2> Message-ID: <42B3A955.6070604@davebsoft.com> David Handy wrote: >... > >You sound like a man after my own heart. Professional software developer >with a desire to teach young people. Me too. > > Glad to know you, David. >In fact this week I sat down with my 8 and 11 year old sons and taught them >binary arithmetic and logic design (AND, OR, and NOT gates) just like my >father taught me when I was 10...it's a generational thing. > > Cool! >>A few weeks ago I got an email from an adult who is a friend of a student >>who will be in my Python class this year. The man works in industry, and >>wanted to know why I would teach Python and not Visual C++... suggesting >>that I'm some tired old professor who was just teaching what he knows >>instead of something useful. >> >> > >I'm rolling on the floor laughing! Python boosts productivity more than 4x >over C++ for me and thousands of other developers and that's not useful? >Sounds like he's the one stubbornly sticking with the things he knows >instead of learning things that are new and different. > >I'm not worried about folks like that, let them have their own opinions. >What bothers me though is that I'm meeting young people who have been >influenced by folks like that. They want to skip Python and go straight to >C++ because that's what they think "cool" game developers do. > > Yes, I've seen this! In 2003, Will Wright, creator of the best selling computer game of all time, The Sims, came and talked to my class (it was outstanding!). After he told the kids that their game infrastructure was written in C++, several of my kids got really interested in learning C++, much to my dismay. I remember wishing that his stuff had been in Java, at least. >They've got to understand that games they think are so "cool" are written by >teams that consist of 3 to 5 programmers and 50 or more graphic artists, >designers, etc. working full time for a long time with costs in the >millions. They want so much to impress their peers, their teacher, etc. They >need to understand that people will be a lot more impressed by something >that's funny and original that they did themselves in Python and it actually >runs vs. something they attempted in C++ and it would have been the next >Starcraft only they never got it finished or working. That's the beauty of >Python -- your success rate goes way up. > > Yes, excellent thoughts. I'm in the habit now of making sure everybody knows up front just how huge an endeavor it is to create a modern computer game. I try to set their expectations really low. When parents come to open house I say something similar, to help them know how excited to get by the relatively unimpressive-looking (to a lay person) programs their kids have written. This year we will attempt to make a simple multiplayer network game in Python. Previously we've done this in Java, and only with advanced students. It has been successful, but I have only managed to find 6-8 qualified students on average, vs. the 30 or so I get in the easier classes (I have 2 or 3 TAs). These are my classes, if anybody's interested: http://davebsoft.com/cfk/ I will be publishing lesson plans and other details here: http://dbschools.com/dbschools/servlet/main/template/InfoSelection.vm?entity_id=6 Anyone is welcome to create an account here, and subscribe to any channels they find interesting, and then the information will be automatically emailed out. http://dbschools.com/ I welcome feedback--and real live visitors, for that matter. We're not far from San Francisco. >Anyway, welcome again to EDU-SIG. > > Thanks! >David Handy >Computer Programming is Fun! >http://www.handysoftware.com/cpif/ > > Dave From rodrigo.senra at terra.com.br Sun Jun 19 16:46:52 2005 From: rodrigo.senra at terra.com.br (Rodrigo Dias Arruda Senra) Date: Sun, 19 Jun 2005 11:46:52 -0300 Subject: [Edu-sig] Explaining Classes and Objects In-Reply-To: <20050613161356.83EFE1E4005@bag.python.org> References: <200506131241.j5DCfcXF008787@ratthing-b246.strakt.com> <20050613161356.83EFE1E4005@bag.python.org> Message-ID: <20050619114652.2044a4e7.rodrigo.senra@terra.com.br> [ Kirby ] ----------- | > >OO really is a different world. I think it still makes sense to teach | > >the subject historically, even though we *can* start with objects at | > >the same time. +1, did that in practice and worked really well. [ Laura ]: ------------ | > This may make sense for people who already know procedureal programming, | > but I don't think that it is a good idea for the rest of the world. I | > think that you need to learn about exception handling _early_ I couldn't agree more. Even though I did not planned to teach exceptions in an introductory undergraduate programming course, that came as a natural result of adopting Python. While exploring the interactive prompt, sooner or later the students have to face something like: >>> x Traceback (most recent call last): File "", line 1, in ? NameError: name 'x' is not defined There had to be an explanation for that, and a way to deal with it. So I had to squeeze the unplanned topic of exception handling into the course plan ;o). | > right after you learn how to write a loop, and unit testing, and test | > driven design from the moment you get out of the 'how to play with the | > interpreter' stage. I agree with you on the importance of TDD. Nevertheless, I'm not sure on the feasibility of introducing this practice during introductory courses. Perhaps, is not a matter of feasibility, but a conscious choice of cutting the red tape a bit, and allow a more free and joyfull first encounter with programming. | The average beginner isn't going to know any programming, so why not start | with class/object right from the top? Time permitting . OTOH, a bottom level approach has the advantage of introducing a mechanism after the need for it is felt. | Yet the procedural model requires less setup I think, less background. | There's no "class hierarchy" to discuss. Indeed. | Having listened to more than a couple CS teachers describe their curricula, | I'm seeing the procedural-first, OO-next approach is fairly widespread. That is also true here in Brazil. best regards, Senra -- Rodrigo Senra ------------------------------------------------ GPr Sistemas http://www.gpr.com.br Blog http://rodsenra.blogspot.com IC - Unicamp http://www.ic.unicamp.br/~921234 ------------------------------------------------ From ajsiegel at optonline.net Mon Jun 20 02:05:40 2005 From: ajsiegel at optonline.net (Arthur) Date: Sun, 19 Jun 2005 20:05:40 -0400 Subject: [Edu-sig] pick-up line Message-ID: <0IIC00FFCW9PBKR1@mta5.srv.hcvlny.cv.net> Owen Mackenzie, protagonist of John Updike's latest novel "Villages", is trying to make conversation with one of the few woman in his class (its MIT in the 50's ) """ He went on, in a voice that sounded whiny in his own ears, "I didn't expect all this rather creepy mathematical logic, Frege and Russel and Godel's paradoxes -- all this propositional calculus, my God, what a tempest in a hypothetical teapot! I thought we were going to learn how to program digital computers. """ Kirby's fault indirectly I am reading this. The son of his friend who joined us when Kirby was in NY is a literature major, and mentioned liking Updike. I was selling math. On a gander, I tried to make a connection - googling, to discover that Updike's latest novel is about a geek of his generation. And that Updike's father taught math. Thought it a fun way to get some history of geekdom under my belt, and indeed it is. BTW, he gets (as in marries) the girl. Art From ajsiegel at optonline.net Tue Jun 21 20:47:52 2005 From: ajsiegel at optonline.net (Arthur) Date: Tue, 21 Jun 2005 14:47:52 -0400 Subject: [Edu-sig] FW: [Visualpython-users] Vpython with pygame.game Message-ID: <0IIG00FKM6UJ3G80@mta3.srv.hcvlny.cv.net> Thought this post to the vpython list would be of interest to some of those not subscribed there. Brief overview - it looks like a very substantial effort to combine elements of VPython, PyGame, Scipy in a pedagogical environment for scientific visualization. +1 Art -----Original Message----- From: visualpython-users-admin at lists.sourceforge.net [mailto:visualpython-users-admin at lists.sourceforge.net] On Behalf Of cchuang Sent: Tuesday, June 21, 2005 4:02 AM To: visualpython-users at lists.sourceforge.net Subject: [Visualpython-users] Vpython with pygame.game Hi, I had released a booklet about VPython and Pygame. All are written within TeXmacs with its Python plugin and shell plugin. In this booklet, there are some vpython examples including: 1. a 3D reflected Brownian partitle travels within a box, (Neuman condition). As the RBM particle hits one of the walls, the hitting sound will be rendering by pygame.sound. 2. Runge-Kutta method for ODE.s. Model the projectile of baseball and Rutherford Scattering Experiment. The file can be downloaded from: ftp://math.cgu.edu.tw/pub/KNOPPIX/game4.pdf In this file server, we also apply some variant KNOPPIX bootable DVD image file, based on knoppix-3.8. Python Environment is also included, for example, visual, scipy etc. User can easily extend his/her need with the help of unionfs in KNOPPIX. In other words, users can read, write even install the packages on the DVD-linux. Hope this really help to you! ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Visualpython-users mailing list Visualpython-users at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/visualpython-users From urnerk at qwest.net Fri Jun 24 21:23:39 2005 From: urnerk at qwest.net (Kirby Urner) Date: Fri, 24 Jun 2005 12:23:39 -0700 Subject: [Edu-sig] Lined up for EuroPython Message-ID: <20050624192340.CC1EF1E4007@bag.python.org> So I'm basically on the runway, waiting to take off -- not really, that's tomorrow morning. The Powerpoint/PDF slides and background essay have been preloaded, as instructed. If you check the slides, you'll notice a "Python plays well with others" discussion, with mention of PIL, wxPython, POV-Ray, VPython, PyGame and others, but with no mention of entirely free-standing packages with Python bindings. PyGeo (a stage for spatial geometry) is sort of like that, as Arthur talks of an interpreted setting, and more forgiving syntax i.e. several formulations of the same command would be acceptable (but the examples weren't specifically Pythonic as I recall). And Cinderella 2, which I've been evaluating a little in beta, for its Jythonic hooks to the GUI stage (a stage for plane geometry, with refreshing dynamic aspects). Anyway, I don't get into the many bindings (Blender is another great example), even Zope and the Chandler stuff, mainly in the interests of keeping to within my allotted time. My focus is really the mathematics, and the curriculum I'm promulgating, in conjunction with on-the-road field testing, and by a process of multiple collaborations. Kirby From ajsiegel at optonline.net Sat Jun 25 16:10:02 2005 From: ajsiegel at optonline.net (Arthur) Date: Sat, 25 Jun 2005 10:10:02 -0400 Subject: [Edu-sig] Lined up for EuroPython Message-ID: <0IIN0016E8PI8R30@mta7.srv.hcvlny.cv.net> >PyGeo (a stage for spatial geometry) is sort of like that, as Arthur talks >of an interpreted setting, and more forgiving syntax i.e. several >formulations of the same command would be acceptable (but the examples >weren't specifically Pythonic as I recall). Appreciate the mention of PyGeo - but not sure where you are going. What I did with the PyGeo scripting interface is try to give it some geometric intelligence, and do so while avoiding the use of a lot of keyword arguments when creating objects - making use of factory functions in a way I think is kind of cool. For example - there is a factory function called "Intersect", which creates Point objects. Say I have 3 Plane instances and a Line instance previously created. >>>Intersect(plane1,plane,2,plane3) will give the unique point of intersection (barring degenerate cases) of the 3 planes. >>>Intersect(plane1, line) Or >>>Intersect(line, plane1) will give the unique point of intersection (barring degenerate cases) of the line and the plane. A condensed version of the Intersect function looks like: def Intersect(*args,**kws): __sigs__=[[Real._Plane,Real._Line], [Real._Plane,Real._Plane,Real._Plane]] t,i = method_get(__sigs__,args) if t is None: raise Argument_Type_Error(__sigs__,args) else: if i==0 or i==1: return PlaneLineIntersect(t[0],t[1],**kws) elif i==3: return PlanesIntersect(t[0],t[1],t[2],**kws) "method_get" is a package level funtion which does compares the __sigs list to the args for all factory functions and gives back the information necessary to call the correct class with the correct arguments in the correct order. def method_get(sigs,args): def order(sig,_args): w=[] args=_args[:] for S in sig: v=[issubclass(a.__class__,S) for a in args] if 1 in v: w.append(args[v.index(1)]) args.pop(v.index(1)) return w args=list(args) for i in range(len(args)): if type(args[i])== int: args[i]=float(args[i]) ret=[] for S in sigs: if len(args) == len(S): final_args = order(S,args) if len(final_args) == len(S): ret.append([final_args,sigs.index(S)]) if ret: return max(ret) else: return None,None So to add a new Intersect class possibility, all I need to do is add its signature to the Intersect __sigs list, and it will be called appropriately. End of story. And so on throughout PyGeo. Among the scripting flexibility that exists is the fact that one is of course not forced to *use* the factory function interface, PlaneLineIntersect(plane1, line) works fine, as well. But of course from a geometric point of view the order of arguments (plane and line) should not have significance - and I can't avoid it being so without the use of keyword arguments - which I was intent on avoiding. So in my mind "PlaneLine Intersect" is the API entrance, "Intersect" the scripting entrance. Use what works for you, for what you are trying to do. What could be more Pythonic? Took me a while to develop this mechanism - don't know how fragile it might be for general use - but works fine in Pygeo and I think it accomplishes in a concise maintainable way, what I am trying to accomplish. Well probably some improvement to "method_get", if nothing else. Bon voyage and have fun at EuroPython. Art From urnerk at qwest.net Sat Jun 25 20:59:21 2005 From: urnerk at qwest.net (Kirby Urner) Date: Sat, 25 Jun 2005 11:59:21 -0700 Subject: [Edu-sig] Edu-sig Digest, Vol 22, Issue 26 In-Reply-To: <0IH700G1P8OIZE@mta5.srv.hcvlny.cv.net> Message-ID: <20050625185927.691281E4008@bag.python.org> > But one that has only been exasperated by an initiatives like CP4E. > Exacerbated? > Do I have a right to resent the fact that I have needed to make myself > into a pain-in-the-ass, and face insult, within the Python community in > order to try to re-direct its thinking in approaching the educational > community and positioning Python as a factor within it. > > Whether I do or not, I do. > > Art Hmmmm. Methinks you over-dramatize. Most of the Python community (always changing/growing) isn't aware of these little tempests in teapots, nor is there some monolithic "hive mind" that characterizes all thinking Pythonic. You've taken aim at bloated, graphics-intensive environments (like Alice) that insulate students from learning any real programming, giving them instead some dumbed down command set and a lot of gee whiz razzle-dazzle. No real maturity develops. I appreciate the concern and share it to some degree. It all comes down to diet. A little Alice is OK, like a little cheesecake. Better work out in the gym with LISP afterwards. But I don't think you needed to make your points at the cost of casting yourself as a pariah, ostracized prophet or whatever. You're just a guy with a strong point of view. There's plenty of room for that around here. If you really want the bouncers to throw you out of the bar, so you can *really* feel bitter, you'll have to do better than that -- plus stop being so funny. Kirby From urnerk at qwest.net Sat Jun 25 21:06:21 2005 From: urnerk at qwest.net (Kirby Urner) Date: Sat, 25 Jun 2005 12:06:21 -0700 Subject: [Edu-sig] Edu-sig Digest, Vol 22, Issue 26 In-Reply-To: Message-ID: <20050625190626.CF6DD1E400C@bag.python.org> > On the down side, the Python IDEs I've seen are nowhere near as good as > the Java IDEs such as Eclipse or IDEA. This is no problem for Catholic > coders who dislike IDEs, and it is less of problem for Python because > of its good syntax, but an IDE that supports refactoring and incremental > compiling sure would be nice. > > Toby > -- > Dr. Toby Donaldson > School of Computing Science > Simon Fraser University I've used the Python plug-in for Eclipse some. It wasn't in final form, but did sport a lot of those Eclipse features. If you're willing to spend money, there's the Wing IDE. I've downloaded the free trial version, but have yet to evaluate it properly. I fully agree that we could use some more featureful IDEs, including free ones -- which reminds me, it's been awhile since I played with DrPython. I think I'll go grab it before the meter runs out on my Hotspot wireless account (I'm in the Vancouver airport international departure lounge). Kirby From missive at hotmail.com Sat Jun 25 21:07:42 2005 From: missive at hotmail.com (Lee Harr) Date: Sat, 25 Jun 2005 23:37:42 +0430 Subject: [Edu-sig] Lined up for EuroPython Message-ID: >"method_get" is a package level funtion which does compares the __sigs list >to the args for all factory functions and gives back the information >necessary to call the correct class with the correct arguments in the >correct order. Reminds me of this article about "multiple dispatch" : http://www-106.ibm.com/developerworks/linux/library/l-pydisp.html _________________________________________________________________ Don't just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ From ajsiegel at optonline.net Sat Jun 25 22:10:49 2005 From: ajsiegel at optonline.net (Arthur) Date: Sat, 25 Jun 2005 16:10:49 -0400 Subject: [Edu-sig] Lined up for EuroPython In-Reply-To: Message-ID: <0IIN00GH1PEA0IG0@mta5.srv.hcvlny.cv.net> > -----Original Message----- > From: edu-sig-bounces at python.org [mailto:edu-sig-bounces at python.org] On > Behalf Of Lee Harr > Sent: Saturday, June 25, 2005 3:08 PM > To: edu-sig at python.org > Subject: Re: [Edu-sig] Lined up for EuroPython > > >"method_get" is a package level funtion which does compares the __sigs > list > >to the args for all factory functions and gives back the information > >necessary to call the correct class with the correct arguments in the > >correct order. > > > Reminds me of this article about "multiple dispatch" : > http://www-106.ibm.com/developerworks/linux/library/l-pydisp.html > See the relationship - but the article is a little too technical for me to understand what is the same and what is different about what I'm doing and "multiple dispatch". Usually "too technical for me" means mostly a lack of a grasp of the vocabulary, and I am a bit stubborn in not working to get up to speed on programming vocabulary. I never understood what a "factory function" was until I invented one ;) - and only then realized it had been invented a million times before. Starting by wishing that Python had the kind of method overloading that Java features, I ended up with a solution that more concisely, more specifically, and more completely solves the problem I was trying to solve than I ever would have come to had Python in fact *had* method overloading. Though method overloading would have been *easier* ;) Art From david at handysoftware.com Sun Jun 26 04:34:53 2005 From: david at handysoftware.com (David Handy) Date: Sat, 25 Jun 2005 22:34:53 -0400 Subject: [Edu-sig] Computer Programming is Fun! Beginning Computer Programming with Python Message-ID: <20050626023453.GF20184@arno2> Hi fellow EDU-SIGer's - A few times over the last year I have mentioned on this list my project to write a beginning programming book using Python. At least one edu-sig subscriber has used this book successfully in teaching an 8th-grade programming class. My book is now ready for sale to the public. Here is the "official" announcement: Written by a homeschooling Dad and professional software developer, "Computer Programming is Fun!" fills a need for a book that teaches computer programming to teenage youth. The author set out to write a book like the one he used to teach himself programming at age 12. In the 1980's programming students began learning with BASIC, but for the new millenium the author chose the more modern Python language. Python is used by NASA, Google, and George Lucas' Industrial Lights and Magic, but is simple enough for beginners to learn. Testimonial: Mr. Handy I got my program to work! I thought today's lesson was really good, I espically [sic] liked the section where you told about how sound and other stuff actually works. I liked your theme song, and using these notes I can make a soundtrack for future space battles. (An 11-year-old in North Carolina) This book has been successfully used by both homeschooling families and public school teachers. A syllabus outline at the beginning of the book lets you select the lessons you want from one of three learning tracks: a data processing track, a video game track, or a simple turtle graphics track, depending on the student's interests and level of learning. All necessary software, including the Python programming language and sample programs, are included on a CD in the back of the book. This book is geared for either self-study or classroom use. Neither the student nor the teacher need have any prior programming experience. 208 pages, $29.95 plus taxes and shipping if applicable Order from the author's web site: http://www.handysoftware.com/cpif/ "Why teach computer programming to teenagers? For the same reason you would teach them piano or any other musical instrument. Consider the computer an instrument for the mind." David Handy cpif at handysoftware.com (919)773-9881 From delza at livingcode.org Sun Jun 26 06:11:09 2005 From: delza at livingcode.org (Dethe Elza) Date: Sat, 25 Jun 2005 21:11:09 -0700 Subject: [Edu-sig] Edu-sig Digest, Vol 22, Issue 26 In-Reply-To: <20050625190626.CF6DD1E400C@bag.python.org> References: <20050625190626.CF6DD1E400C@bag.python.org> Message-ID: <63F8358F-FBB1-4193-ACE5-6ADF38EF14C4@livingcode.org> Kirby (and the rest of you edu-sig-ers), Next time you're going to be in Vancouver, give me a shout-out. I'd love to catch up face-to-face. I know I've been fairly low-key on the list lately, but I'm still following along with interest. Toby, The state of python IDEs is something that comes up a lot, especially on the mac-python list (where the choices are even more limited). I'm looking forward to Komodo being available for OS X, but if you're on another platform it's worth trying out. If you like Eclipse, I understand their Python plugins are shaping up nicely. There are a *ton* of Python IDEs, and I haven't evaluated them all (or any very deeply, I'm more of a Catholic using TextWrangler and Vim), but in large part it depends on what features you're looking for. Some of the Python IDEs are very living products--if it does 80-90% of what you need, but is missing a feature or two that would really make it shine for you, a little feedback to the developers can go a long way. On the mac-python list I've seen IDE developers come and ask what our wishlist features are to guide their development. So there are options, and they are improving all the time. --Dethe On 25-Jun-05, at 12:06 PM, Kirby Urner wrote: >> On the down side, the Python IDEs I've seen are nowhere near as >> good as >> the Java IDEs such as Eclipse or IDEA. This is no problem for >> Catholic >> coders who dislike IDEs, and it is less of problem for Python because >> of its good syntax, but an IDE that supports refactoring and >> incremental >> compiling sure would be nice. >> >> Toby >> -- >> Dr. Toby Donaldson >> School of Computing Science >> Simon Fraser University >> >> > > I've used the Python plug-in for Eclipse some. It wasn't in final > form, but > did sport a lot of those Eclipse features. > > If you're willing to spend money, there's the Wing IDE. I've > downloaded the > free trial version, but have yet to evaluate it properly. > > I fully agree that we could use some more featureful IDEs, > including free > ones -- which reminds me, it's been awhile since I played with > DrPython. > I think I'll go grab it before the meter runs out on my Hotspot > wireless > account (I'm in the Vancouver airport international departure lounge). > > Kirby > > > > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig > > Choosing software is not a neutral act. It must be done consciously; the debate over free and proprietary software can?t be limited to the differences in the applications? features and ergonomics. To choose an operating system, or software, or network architecture is to choose a kind of society. --Lemaire and Decroocq (trans. by Tim Bray) From ajsiegel at optonline.net Sun Jun 26 17:40:29 2005 From: ajsiegel at optonline.net (Arthur) Date: Sun, 26 Jun 2005 11:40:29 -0400 Subject: [Edu-sig] Edu-sig Digest, Vol 22, Issue 26 Message-ID: <0IIP00A297GWD900@mta8.srv.hcvlny.cv.net> Kirby writes - > -- plus stop being so funny. One time, it was even on purpose ;) Art From urnerk at qwest.net Mon Jun 27 13:39:14 2005 From: urnerk at qwest.net (urnerk@qwest.net) Date: Mon, 27 Jun 2005 07:39:14 -0400 Subject: [Edu-sig] Computer Programming is Fun! Beginning ComputerProgramming with Python Message-ID: <229200-220056127113914318@M2W043.mail2web.com> Congrats on getting this done! Kirby Original Message: ----------------- From: David Handy david at handysoftware.com Date: Sat, 25 Jun 2005 22:34:53 -0400 To: edu-sig at python.org Subject: [Edu-sig] Computer Programming is Fun! Beginning ComputerProgramming with Python Hi fellow EDU-SIGer's - -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web.com/ . From urnerk at qwest.net Mon Jun 27 13:53:02 2005 From: urnerk at qwest.net (urnerk@qwest.net) Date: Mon, 27 Jun 2005 07:53:02 -0400 Subject: [Edu-sig] re Guido's talk at Europython Message-ID: <129170-22005612711532208@M2W054.mail2web.com> So I attended Guido's 'Why I Invented Python' talk in conference room VV today (Swedes like V and K above other letters, it seems to me). I learned quite a bit of history from this talk. He paid a lot of tribute to ABC (a language for non-programmers needing to write programs) for being inspirational, but he also learned from its failures, and its "world-wide non-adoption." Python would be different (and it was). Whereas ABC was for non-professional programmers, Python was designed from the ground up to be a tool for pro programmers. It was also meant to be a project one person could implement, so Guido dropped certain features of ABC, even if he liked them, if the implementation was hairy (e.g. type inferencing). Chief among ABC's features that he wanted to keep: the interactive prompt. Indeed, this is a feature of Python that newcomers to the language often say they most appreciate (even if they've programmed before -- immediate feedback is a great way to attain mastery relatively quickly). [ In my own case, coming from dBase and its "dot prompt" (and previously APL) I'd come to take such interactivity for granted, and probably would never have invested in Python had it been lacking this advantageous feature. ] I hadn't realized he first developed Python on a Fat Mac, but always with the intent to make it cross-platform, i.e. to run on Amoeba, the OS he was working on at the time, and Unix, the production OS at work. Python was first conceived as a scripting language for Amoeba, something to fill the gap between the shell and C programming. He looked at Perl but found it rather non-portable (it took a Unix environment for granted, at least at that point). Nor had I fully appreciated that, although the architecture was OO from the beginning, the capability for users to add their own classes came a few months later. The fact that types and classes weren't well integrated at first traces to user classes being "second class citizens" at first. There's an emphasis on newcomers to Python this year: neopytes, they're being called. Guido helped launch that track. Every available seat in VV was taken. Kirby -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web.com/ . From ajsiegel at optonline.net Mon Jun 27 16:20:20 2005 From: ajsiegel at optonline.net (Arthur) Date: Mon, 27 Jun 2005 10:20:20 -0400 Subject: [Edu-sig] re Guido's talk at Europython In-Reply-To: <129170-22005612711532208@M2W054.mail2web.com> Message-ID: <0IIQ007BRYIBCHE0@mta5.srv.hcvlny.cv.net> > -----Original Message----- > From: edu-sig-bounces at python.org [mailto:edu-sig-bounces at python.org] On > Behalf Of urnerk at qwest.net > Sent: Monday, June 27, 2005 7:53 AM > To: edu-sig at python.org > Subject: [Edu-sig] re Guido's talk at Europython > > So I attended Guido's 'Why I Invented Python' talk in conference room VV > today (Swedes like V and K above other letters, it seems to me). > > I learned quite a bit of history from this talk. He paid a lot of tribute > to ABC (a language for non-programmers needing to write programs) for > being > inspirational, but he also learned from its failures, and its "world-wide > non-adoption." Python would be different (and it was). I had listened to a recent interview Guido gave ("Building an Open Source Project and Community") that covered much of the same territory. http://www.itconversations.com/shows/detail545.html And enjoyed it - found it candid, down-to-earth, and suitably proud. Art From rballard at pivot.net Mon Jun 27 16:42:24 2005 From: rballard at pivot.net (Richard Ballard) Date: Mon, 27 Jun 2005 10:42:24 -0400 Subject: [Edu-sig] Re computer programming is fun Message-ID: <42C01050.5000407@pivot.net> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20050627/ebb03d1a/attachment.htm From ajsiegel at optonline.net Mon Jun 27 17:20:45 2005 From: ajsiegel at optonline.net (Arthur) Date: Mon, 27 Jun 2005 11:20:45 -0400 Subject: [Edu-sig] Edu-sig Digest, Vol 22, Issue 26 Message-ID: <0IIR00MA817ZZS00@mta8.srv.hcvlny.cv.net> Kirby writes - >You've taken aim at bloated, graphics-intensive environments (like Alice) >that insulate students from learning any real programming, giving them >instead some dumbed down command set and a lot of gee whiz razzle-dazzle. >No real maturity develops. Yes and no, in terms of what motivates my hysterias. My objection to projects like Alice is nothing more specific, really, than my subjective sense of where it is coming from, what motivates it, and its level of sincerity and integrity. It is difficult both to defend such subjective assessments, and to back away from them. When the stakes are as I imagine them to be - that is. There are plenty of areas in which I am willing to be kind. Or at least silent. This area - education, technology, and children - ain't one of them. Art From gvanrossum at gmail.com Mon Jun 27 17:26:24 2005 From: gvanrossum at gmail.com (Guido van Rossum) Date: Mon, 27 Jun 2005 08:26:24 -0700 Subject: [Edu-sig] Edu-sig Digest, Vol 22, Issue 26 In-Reply-To: <0IIR00MA817ZZS00@mta8.srv.hcvlny.cv.net> References: <0IIR00MA817ZZS00@mta8.srv.hcvlny.cv.net> Message-ID: On 6/27/05, Arthur wrote: > Kirby writes - > > >You've taken aim at bloated, graphics-intensive environments (like Alice) > >that insulate students from learning any real programming, giving them > >instead some dumbed down command set and a lot of gee whiz razzle-dazzle. > >No real maturity develops. > > Yes and no, in terms of what motivates my hysterias. > > My objection to projects like Alice is nothing more specific, really, than > my subjective sense of where it is coming from, what motivates it, and its > level of sincerity and integrity. > > It is difficult both to defend such subjective assessments, and to back away > from them. > > When the stakes are as I imagine them to be - that is. There are plenty of > areas in which I am willing to be kind. Or at least silent. This area - > education, technology, and children - ain't one of them. I have second thoughts about Alice too (and not just because Pausch apparently rewrote it in Java :-). See for yourself about Pausch's IMO cocky, self-serving attitude: http://www.acm.org/ubiquity/interviews/v6i20_pausch.html -- --Guido van Rossum (home page: http://www.python.org/~guido/) From ajsiegel at optonline.net Tue Jun 28 01:54:22 2005 From: ajsiegel at optonline.net (Arthur) Date: Mon, 27 Jun 2005 19:54:22 -0400 Subject: [Edu-sig] Edu-sig Digest, Vol 22, Issue 26 In-Reply-To: Message-ID: <0IIR00APUP3DBX70@mta7.srv.hcvlny.cv.net> > -----Original Message----- > From: Guido van Rossum [mailto:gvanrossum at gmail.com] > See for yourself about Pausch's IMO cocky, self-serving attitude: > > http://www.acm.org/ubiquity/interviews/v6i20_pausch.html I am usually not much one for statistics, but one statistic it would be fun to see would be the funding per productive user of Python vs. Alice. My Alice guesstimate: >>> 2250000.00 /11 204545.45454545456 >>> I've sensed that the key to Pausch is exactly as he says: "I love the creation of illusion" Art From dr.addn at gmail.com Tue Jun 28 08:20:59 2005 From: dr.addn at gmail.com (adDoc's networker Phil) Date: Mon, 27 Jun 2005 23:20:59 -0700 Subject: [Edu-sig] Edu-sig Digest, Vol 22, Issue 26 In-Reply-To: References: <0IIR00MA817ZZS00@mta8.srv.hcvlny.cv.net> Message-ID: <8fd4a2fe05062723202b25dcef@mail.gmail.com> On 6/27/05, Guido van Rossum wrote: > > I have second thoughts about Alice too (and not just because Pausch > apparently rewrote it in Java :-). > > See for yourself about Pausch's IMO cocky, self-serving attitude: > > http://www.acm.org/ubiquity/interviews/v6i20_pausch.html > Carnegie Mellon University\ Entertainment Technology Center \ Design Director Randy Pausch: "( . The essence of a being a researcher is knowing the answer to a question that nobody else has even asked yet . It's really a kind of illusion, and I love the creation of illusion, which is why as a kid I was fascinated by theme parks, particularly the stuff that Imagineering has built, because they they're so much better at creating an illusion than almost anybody else ... I don't focus as much on entertainment as you might think . So, for example, ... . The longest-running research project I have is called Alice, ... that is able to provide a better, first exposure to computer programming ... . But this is much more advanced than Logo was, to the point where it can be used for a full semester course at the college level. ... We've demonstrated that with at-risk students we can both improve retention and grade point average . And so, when people say, well, how do you feel having a career doing all this frivolity, I hasten to point out that the number of computer science majors in America last year declined by 23 percent . { educators call Alice frivolous if students can't type Java by the end of the 14 weeks } But what I find fascinating is that, { if a business's profits were down 23 percent, that be all they could think about, wouldn't it ? } [ Alice is not so trivial ] )-Paush . it is obvious from that interview, that Paush is not telling us what he is really feeling critical toward; his concern about low enrollments in CS just doesnt make sense: . a field like computer science is not something one goes into for it's value as a liberal arts education: you get a technical skill for a particular vocation; thus, CS enrollment is naturally going to be a function of the market's perceived need for programmers and system analysts . indeed, it is a tribute to the RAD technologies such as Pausch's own Alice system -- serving the same cp4e spirit as van Rossum's Python language -- that programming is seen as something that all employees are expected to do; because, machines are getting intelligent enough to be treated like fellow employees ! . I imagine that part of Pausch's frustration has to do with the hurt feelings that were generated when he moved Alice's scripting language from Python to Java; ironically, this is just the niche that Alice needs to prove it's [/]unique value: while Python is the Basic language of the new age, and is so easy to write that Alice's enforced menu interface would only slow a student down Java, on the other hand, is that most-favored assembly language of the new age, having such a quarrelsome syntax, that Alice's menu interface can provide most of us with a much-needed relief from semicolon-itis ! . when I read that Pausch had trouble with Python's case-sensitivity; [@] http://www.alice.org/advancedtutorial/ConwayDissertation.PDF I wondered why he did not see this as a hint to complete his system: . the obvious goal of a menu system is to help you find the syntax by building the command string as you compose by pointing . after that, Alice should be inserting command strings into a normal text window thereby allowing us to use both keyboard-typing and menu-pointing at either the command line or the current project window . it could further assist us by throwing in the usual RAD perks: structuring our code with an outliner mode, and running a syntax checker in the background Pausch: "( . we had to wrap a textbook around it, because one of the things I learned painfully is that you can have the best software in the world, but if there isn't the educational infrastructure called the textbook, no one will start using the software . Once the textbook was in beta we were in 25 schools. )-Pausch . if Pausch wants respect for a system without a textbook, he should should put more effort into a robotic tutor that actually shows you how it would use the system to solve an example problem . a robotic system could have a cartoon's message bubble giving the robot's rationale for each activity, along with an overview window of the robot's plans . most importantly, the robot's tutorial should give me the same power as that provided by a book: the tutor's pace is controlled by a page-turning button; and I can stop a tutorial at any time, (use bookmarks to come back to it), and ask the robot with a table of contents [/][whatever questions I have, at the time I have them] . now, [/]that would be creating the illusion of zero gravity! on the hand, being dragged around by programmed intructing, is far worse than frivolous -- it.s a penmanship lesson in Sanskrit ! . it is my hope that the Alice system as I envision it, can teach all normal preschoolers to program in Python . -- American Dream Documents "(real opportunity starts with real documentation) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20050627/6fdbe710/attachment-0001.htm From ajsiegel at optonline.net Tue Jun 28 13:47:10 2005 From: ajsiegel at optonline.net (Arthur) Date: Tue, 28 Jun 2005 07:47:10 -0400 Subject: [Edu-sig] Edu-sig Digest, Vol 22, Issue 26 In-Reply-To: <8fd4a2fe05062723202b25dcef@mail.gmail.com> Message-ID: <0IIS00AGPM3DC0F0@mta7.srv.hcvlny.cv.net> _____ From: adDoc's networker Phil [mailto:dr.addn at gmail.com] Sent: Tuesday, June 28, 2005 2:21 AM To: guido at python.org Cc: Arthur; edu-sig at python.org; Torrance Art Subject: Re: [Edu-sig] Edu-sig Digest, Vol 22, Issue 26 >. it is my hope that the Alice system as I envision it, >can teach all normal preschoolers to program in Python . Why wait to preschool? A clear lack of Vision. Seems to me that the manual crib toy is an artifact of the past, and does not properly prepare the child for what will be expected of him at pre-school. Seems to be the Behaviorists had the right idea about early programming education. Let the infant learn how to push the right buttons in the right order when he/she expects to me fed. It's early training for the world they will inhabit, and therefore for their own good. Art. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20050628/56c13a23/attachment.htm From urnerk at qwest.net Tue Jun 28 13:53:09 2005 From: urnerk at qwest.net (urnerk@qwest.net) Date: Tue, 28 Jun 2005 07:53:09 -0400 Subject: [Edu-sig] Kirby calling Andre Message-ID: <246560-22005622811539138@M2W033.mail2web.com> Hey Andre, I'm feeling disconsolate because I missed your talk yesterday: http://www.python-in-business.org/ep2005/talk.chtml?talk=4345&track=774 I didn't recognize it from the title, was looking for the word RUR-PLE and when I didn't find it, stupidly came to the conclusion you'd changed your plans about speaking. I should have just gone by name (duh). Now I'm sitting here listening to two gents next to me recount talks they'd been to. I heard a fairly detailed recap of your presentation (for which I'm grateful -- alerted me to my error), but I'd much rather meet with you in person and maybe learn more of your approach directly from you. I don't know what you look like. I'll be scanning name tags in earnest. I'm slated to do my talk at 4 PM. My jet lag is pretty severe (I doubt I slept at all last night), but I'm sure I can hold it together until at least 5 PM. After that, I don't have to stay coherent. Kirby -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web.com/ . From rballard at pivot.net Tue Jun 28 19:05:37 2005 From: rballard at pivot.net (Richard Ballard) Date: Tue, 28 Jun 2005 13:05:37 -0400 Subject: [Edu-sig] Computer programming is fun retry Message-ID: <42C18361.8080007@pivot.net> Hi, Thought I'd try this again since I didn't send it in text, it didn't post correctly Rich Ballard Original message: I am the 8th grade teacher who has used David's Computer programming is fun book in class. I teach at MVU middle school in Swanton, Vermont. I want to add my voice to what a great book it is for beginning programming. I'm not a programmer but have dabbled in it a little here and there with BASIC and some college courses. This book made it quite simple for me to teach and for the kids to learn. As an introductory course, I believe it touched on a lot of topics that will help the kids in getting prepared to take more advanced courses. And for those who don't, it was helpful in their development of logical thinking skills, math skills, and just to help them to understand what computer programming is and what it entails to write a simple computer program. This can be taught as a self taught course if you had a young son or daughter you wanted to introduce to programming or as a class. As I said, I did the latter, I usually did some introductory information with the whole class then sent them to the computers to work through a chapter. The quizzes at the end of each chapter are great for keeping scores for the kids in a traditional classroom. David has also been great at helping if I ever got stuck or needed an idea either by phone or email. I highly recommend you give this book a try. I think it is a great resource for kids in the middle level or lower high school level or anyone who has never done any programming. If any one has any questions, please email me or see David's web site: http://www.handysoftware.com/cpif/ Sincerely, Rich Ballard rballard at pivot.net From urnerk at qwest.net Tue Jun 28 18:04:45 2005 From: urnerk at qwest.net (urnerk@qwest.net) Date: Tue, 28 Jun 2005 12:04:45 -0400 Subject: [Edu-sig] Mission accomplished Message-ID: <207760-22005622816445265@M2W099.mail2web.com> OK, my talk is behind me. I'll give myself a pat on the back for getting through all 30 slides, plus doing four demos, within the allotted hour, with time for questions (there was only one question). I forgot to visit Sloane's On-Line Encyclopedia of Integer Sequences though. I was going to enter 1,12,42,92,162 and show how the resulting page links back to one of mind. Oh well. Plus I've lost my fleece (the sweater I wore this morning, and shed in some room...). My demos: 1. POV-Ray animation of Maira kicking a soccer ball (generated from a spreadsheet sent me by a physicist at the University of Nebraska); 2. my rational number type doing a continued fraction ([1,1,1,1,1,1...]); 3. totatives of n generating multiplication and addition tables; 4. the VPython hypertoon. The audience was pretty small (15? more?), as they tend to be on a sunny day after two marathon days of talks. They guy from CERN was there. A Swedish student drew up alongside later, to say he really liked what I had to say. I severely jet lagged. I'm sitting in a big conference room waiting for a keynote address, just barely keeping my eyes open. The Zope stuff is really big here this year, gets the biggest audiences. Next year, Europython will be at CERN in Switzerland. Kirby -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web.com/ . From ajsiegel at optonline.net Wed Jun 29 16:40:53 2005 From: ajsiegel at optonline.net (Arthur) Date: Wed, 29 Jun 2005 10:40:53 -0400 Subject: [Edu-sig] Edu-sig Digest, Vol 22, Issue 26 Message-ID: <0IIU0046EOPK1E50@mta8.srv.hcvlny.cv.net> Not be beat a dead horse, but the truth is I don't think Alice is dead yet - the Prentice-Hall text book will probably rescue it a bit from obscurity, and maybe do more for it than that. Pausch always has a chance as long as he stays out of the way of an environment of a true meritocracy. In that sense I think he has found the correct arena to make his mark - after years of groping toward it. Carnegie Mellon University\ Entertainment Technology Center \ Design Director Randy Pausch: >>"I hasten to point out that >>the number of computer science majors in America last year >>declined by 23 percent" I am not surprised to see Pausch bring up this statistic in connection with his promotion of Alice. There is a fine line between promoting one's work and charlatanism. I have my own opinion on which side of the line Pausch is on in presenting Alice as an connected to and as an Antidote for this statistical reality. >>But this is much more advanced than Logo was, >>to the point where it can be used for a full semester course at the >>college level. Logo "was". Cute. Alice could in fact be used for a full semester course at the college level, as long as it imposed. But when given a choice between working with Alice (when it was promoting itself as a virtual world building tool) and Panda3d, exactly 100% of the students chose Panda3d. Perhaps has something to do with the fact that Alice is no longer promoting itself as a virtual world building tool. College level education, in general, still has too many merit forces at work. But where Pausch is headed with Alice, there is true difficulty in distinguishing between the illusion of learning and learning. Or the illusion is good enough for most purposes - when the goals of exposing children to technology remain as vague as they are being allowed to remain. I am sure that exposure to Alice in an enforced curricula *does* have a measurable impact. All there is left to do is to assert that whatever this impact is, it is the intended impact, and then that this impact fulfills some important learning mission. Illusion becomes reality, I was heartened to see that in a current thread on python-list in response to a poster's request for guidance about programming exposure for young folks, David Handy's book was mentioned, Logo mentioned a number of times, Squeak was mentioned - but Alice was not. But it ain't over until its over. And I don't believe we have heard the last of Alice yet. Art From ajsiegel at optonline.net Wed Jun 29 20:04:20 2005 From: ajsiegel at optonline.net (ajsiegel@optonline.net) Date: Wed, 29 Jun 2005 14:04:20 -0400 Subject: [Edu-sig] Edu-sig Digest, Vol 22, Issue 26 Message-ID: <5c3771e5c31bf6.5c31bf65c3771e@optonline.net> Everyone inclined to do so - please *do* ignore the following: I had written - > All there is left to do is to assert that whatever this >impact is, it is the intended impact, and then that this >impact fulfills some important learning mission. Illusion >becomes reality, I guess I need to ask for assistance from the resident philosophy scholar/scholars. In that I suspect what I am saying/ think I am observing is the oldest of stories. There is nothing in fact new under the sun, except the pace of things, and therefore the ability to observe these kinds of phenomena occurring, as they occur, and when one has enough worldliness under one's belt to understand the dynamics. Is this what the philosophical school of Deconstructionists was pointing to in terms of how "reality" comes to be defined? I suspect there is some connection. But sorry for going more than usually OT. Art