Mailman 3 February 2000 - Edu-sig

Is a SIG the right type of forum for Python-in-education discussions?
by Skip Montanaro Feb. 7, 2000

Feb. 7, 2000

I don't want to start a meta discussion that will quickly be deemed off-topic, but the thought has occurred to me that perhaps a SIG is not the correct sort of mailing list for this topic. In general, my understanding is that a Python-oriented SIG should try and identify a set of specific tasks fairly quickly, then work toward fulfilling those tasks, and go out of existence when either the tasks are complete or the group becomes inactive. I sense that there will be lots of interesting discussion about education- related topics that won't directly affect the Python distribution. If you are unfamiliar with what a Python SIG is supposed to look like, check out the Python SIGs page at http://www.python.org/sigs/ I'm not suggesting that an education-related mailing list for Python is a bad idea. I expect there is a place in the community for such a beast. I suggest we create a charter for the group and see what it looks like. If it looks like a SIG, fine, we march off with our charter and conquer the world. If not, perhaps another email-based forum (edu-list(a)python.org?) would be worthwhile to support ongoing interest in the use of Python in an educational setting. Skip Montanaro | http://www.mojam.com/ skip(a)mojam.com | http://www.musi-cal.com/ 847-971-7098 "Languages that change by catering to the tastes of non-users tend not to do so well." - Doug Landauer

2 1

Re: [Edu-sig] a modest proposal II
by Jason L. Asbahr Feb. 6, 2000

Feb. 6, 2000

At 06:03 PM 2/4/00 -0500, Paul Fernhout wrote: >A Smalltalk teaching product called LearningWorks >http://learningworks.neometron.com/ includes specially designed starter >browsers (and even limited debuggers!) where for example a student >learns programming by sending Smalltalk messages to a square in a window >connected to the browser. Please look at the pictures here for some >ideas: <snip> That's the subject of the video I mentioned in a previous post, LearningWorks. Thanks for posting that, Paul! The CP4E goal of enabling people to get under the hood and hack is very exciting. That is the attraction of Python for a lot of developers, the "glue" aspect. But calling it glue doesn't give Python enough credit -- Python is an elegant tool which allows one to focus more on the problem domain, on the ends rather than on the means. And since there is a constantly expanding set of subsystems harnessed by Python (sockets, OpenGL, XML, Numerical, CORBA, databases), Python becomes a natural and common facility for building and customizing solutions which combine and utilize other functional systems. [1] I find myself running into limitations on the systems I use every day (Eudora, Palm Pilot, Visual Studio, my alarm clock, my stereo) and thinking, "if this system was exposed to me in Python, *I could fix it*". In addition to being an elegant language, Python is a very practical language, which extremely valuable for a project like CP4E. I hope to see Python evolve to be a better language over time (P3k), but certainly for our purposes, it's pretty much there. Assuming the ultimate point of CP4E is to empower individuals in an increasingly technological society, any discussion of the educational aspects of teaching programming should keep in mind that value is that the young programmers can actual *do something* with what they are learning. Hence the value of the virtual world approach, the numeracy approach, the 3D graphics approach. IMHO, anything else is secondary. So, anyway, the forum here is new, but very dynamic, lots of signal, relatively little noise. It may be necessary to split the discussion eventually into more focused email groups, but if it happens, I for one expect to subscribe to all of them. :-) Cheers, Jason Asbahr Origin Systems, Inc. jasbahr(a)origin.ea.com [1] The open source nature of Python and the Python community also has significant value. It's not just free (as in beer), but it's all open. The community creates a network effect, each new system developed or harnessed becomes available to the general group, which finds new ways to use, extend, and combine. This is extremely powerful, and (again IMHO) the driving force behind Python and, potentially, CP4E.

1 0

Programming for everybody for non-CS purposes
by Bruce Sherwood Feb. 6, 2000

Feb. 6, 2000

I really liked what Dave Scherer said about computing for everybody, which is the flavor of CP4E that interests me. I have nothing against improving CS education, it's just not all there is in the world, and apparently there's no shortage of people interested in working on that. The CP4E issue goes beyond issues of teaching programming and computer science. One of Dave's examples was "if educators could write educational software..." In the history of educational software at the college level, many theorists claimed that the ideal development model was for faculty to feed pedagogical ideas to programmers to implement. This was supposed to provide the efficiency and quality of the industrial production line, with useful division of labor. But mostly it led to mediocre materials, produced at very high cost (due to the inefficiencies of communication between educators who didn't understand the medium and programmers who didn't understand education). Where possible, it is much better for the people most concerned to be able to do the programming themselves, with the programmers providing the tools to make that feasible. Years ago the theorists pooh-poohed having faculty themselves write educational software with the sarcastic analogy, "You obviously wouldn't want to waste a professor's time on typesetting a textbook." This sarcasm was tool-conditioned: now the tools permit professors to typeset their own textbooks. It's a lot of work, but having total control of the production process is terrific and can lead to higher quality. (Actually, it used to be a lot of work anyway dealing with editors and illustrators and typewritten drafts and secretaries and...) Bruce Sherwood

1 0

Case sensitivity
by Bruce Sherwood Feb. 6, 2000

Feb. 6, 2000

I was intrigued by the comments of my colleague Dave Scherer on treating with caution how well proved is the assertion that case sensitivity is a problem for novices. Let me offer some context to provide another view on the issue of case sensitivity. CONTEXT Ruth Chabay and I have been teaching an unusual introductory university freshman physics course at Carnegie Mellon University taken by science students, in which computer modeling plays a central role: http://cil.andrew.cmu.edu/mi.html We spend just two 50-minute periods teaching a subset of the cT programming language developed in our Center for Innovation in Learning, after which the students write programs with 2D graphic output including a spacecraft coasting to the Moon, a planet in an elliptical orbit, the motion of a mass on a spring with or without friction or air resistance, the scattering of an alpha particle off a gold nucleus (the Rutherford experiment that discovered the nucleus), and statistical mechanics calculations of the entropy and specific heat of a solid modeled as quantized harmonic oscillators. A sizable minority of our students have not previously written a computer program, but they are able to do serious computer modeling with little instruction, and they are able to do this on Windows, Mac, or Linux, with no installation or environment difficulties. A group of us at Carnegie Mellon including David Andersen, Ruth Chabay, Ari Heitner, Ian Peters, Dave Scherer, and I are investigating the possibility of having our physics students use Python instead, with 3D graphics implemented through an innovative package being developed by Dave Scherer that talks to Open GL. The challenge is to make a package installable and usable by novices, with 3D graphics, that works on Windows, Mac, and Linux. (We don't see it to be feasible to build 3D graphics onto cT.) Note that we have chosen a very narrow focus: Making it possible for science students in a university physics course to learn quickly and use productively Python plus 3D graphics in order to do computer modeling of physical systems. This is a different focus from that of many contributors to this SIG, whose main interest is in using Python as the language of instruction in computer science or programming courses. One possible overlap of interests is this: We believe that those just beginning to write programs want in the year 2000 to write graphics-oriented programs, not programs that just calculate mathematical quantities. Graphics is a huge motivator and of the highest interest in the public at large. We define "computer programming for everybody" as starting with graphics, not in getting Joe Public to write Python code to control his web server, at least not at first! It is possible that what we may be able to do in making 3D graphics available to the masses would find use in introducing programming to newcomers. CASE SENSITIVITY In our physics teaching we have not seen any hint of a problem with case sensitivity, even though cT is case sensitive. There are confounds, however, so I don't want to claim too much. In cT one is required to declare all variables, so it seems plausible that the student will use the name that the student defined. Also, system-defined commands that might be problematic don't cause trouble because these commands are at the beginning of a line, followed by TAB, so there is no problem if the student declares a variable named "disk" and also uses the "disk" command. System-defined names that can collide with user-defined names, such as "zred" for the color red, all start with a z to help avoid collisions. It is possible that these special considerations are the reason why we have seen no hint of an issue with case sensitivity. But there may also be significant contextual differences between our physics environment and that of an English student trying to command a bunny to hop in Alice. The algebra-savvy science student is used to making distinctions between t (time) and T (temperature), between a (acceleration) and A (area), etc. A particularly nice pair is e (charge on an electron) and E (electric field operating on that electron), so that the force on the electron is represented by e*E. (Of course there may also be a collision with the natural-log base e!) The reason for these letter pairs in physics is a shortage of letters in the Roman alphabet coupled with a historical style that mandated single-letter names for algebraic quantities. We are now accustomed to using multiletter names in computer programs, so we could write Qelectron instead of e and Efield instead of E. But I would be cautious in throwing out case sensitivity on the basis of usage problems in one particular community. Perhaps it could be optional on a per module, based on a directive found at the start of the module, in order to accommodate the needs of different communities? FLOATING-POINT DIVISION I have a very different view of the other problem that was reported, the problem with division indicated by "/". Here I VERY much want a change so that "/" means floating-point division, even if both operands are integer. I VERY much want 1/4 to be 0.25, not 0. There are a variety of possible solutions to provide backward compatibility. At worst, a conversion could change all occurences of a/b into "olddivision(a,b)" which would mimic the current behavior. And of course there would be a new syntax such as "a div b" to do integer division. The current convention causes trouble even for expert programmers when they're in a mathematical frame of mind. OTHER ISSUES ARE BIGGER The division issue is important. The case sensitivity issue may be important. But both of these issues pale into utter insignificance compared to the huge barriers currently facing novices with respect to installation, running (search path issues, IDE issues), graphics, and cross-platform issues. Bruce Sherwood Center for Innovation in Learning and Department of Physics Carnegie Mellon University

2 2

pedagogy, programming environments, and readings
by Matthias Felleisen Feb. 6, 2000

Feb. 6, 2000

Dear Python CP4E-ers: I follow your discussions with great interest as an outsider and would like to comment/suggest a few things. It surprises (and saddens) me that so much enthusiasm is spent on discussions with so little background information. Our discipline is a science with a large body of research (not educational) literature. Other communities have gone through the discussions on how implementations of IDEs relate to pedagogy and vice versa. For example, 1. Your community is not the first one to discuss case-sensitivity and case-insensitivity. Why not check how they dealt with the issue? 2. You're not the first to discuss the merits of tail-call optimizations in a pedagogic context. Study some of the recent pattern literature on OO design and then consider why tail-call optimizations are essential. Don't shoot from the hip with lots of <winks> and <grins> and <G:->. Unless, of course, you have too much time at your hands. 3. The same applies to GC. 4. The connection between IDE design and beginners, at all levels, is important and has been recognized as such. We have published a paper on this, among others. 5. Nobody (as far as I can tell) has raised the question how you want to differ from the rest of the world. What value do you add? Playing with worlds? Yes, Pappert has suggested it. Has anyone checked whether he and his team have done anything about it? (They did.) What is new about Pythin's pedagogy vs the prevailing, argh, C++ pedagogy? Etcetc. My goal is not to be negative. I am only suggesting that you study what exists, clarify where you want to go, and advertise why your ideas and (future) curriculum is better than what's out there. While we, the outsiders, discuss, the rest of the world gets entrenched into the next fashion wave and we will have to battle it. -- Matthias Matthias Felleisen Professor of Computer Science Rice University For a new way to look at the world of high school computing, see http://www.cs.rice.edu/CS/PLT/Teaching/Workshops/ "Computer Science is no more about computers than astronomy is about telescopes." -- E. W. Dijsktra

4 3

Re: [Edu-sig] pedagogy, programming environments, and readings
by Kirby Urner Feb. 6, 2000

Feb. 6, 2000

I am becoming increasingly aware of the two schools of thought that Dave Scherer posted about recently: (1) lets use Python now, how? and (2) we need more/better tools too. Jim accurately point out (at the end a recent post) that both schools find a footing in the actual text of the CP4E, a sort of "founding document" for this group. I don't think it's either/or. I'm quite in agreement that teaching Python requires background development -- at the very least the public sharing of a lot of .py files (I liked the PythonForge.com suggestion). Websites with template lesson plans and integrated Python, made known to teachers, is a goal I'd very much like to see realized. And I see no barriers to providing such content immediately (I'm already a provider, and found Python very suitable in its present form). Personally, what I want to see along the lines of (2), are pointers to web sites and possibly other listservs where developers are actually developing/implementing. I'd like to lurk, in many cases, or at least check out the approach. For example, it sounds like this Alice stuff could take up a lot of bandwidth (usefully, with good reason). What I personally don't particularly want to read a lot of is "good ideas" by people who are not actually doing anything to implement them. Developers who (a) have an idea and (b) are publicly committing to testing/implementing it themselves have credibility. But people who just want to dream of a bright tomorrow, and hope others will do all the work, have little to say that I want to read. That's just my own bias. I can apply my own filters and don't pretend these are "moderator remarks" -- many people posting here may never read these words, or care what my biases are. It's very common when a topic is as rich as this one for the flood of business to at times become overwhelming. The standard response is to delegate big chunks to "committees" (don't have to call 'em that) and get summary reports back from time to time. Maybe it's harder to organize such infra- structure on-line, among spontaneously posting individuals, but I've seen it work in other cyberspace contexts. It's very easy to create listservs these days, and web sites. So I remain optimistic that after this initial period of flailing around, we'll continue on an even keel with a strong sense of direction and purpose. Kirby

2 1

Re: [Edu-sig] Creating worlds.
by John Maxwell Feb. 6, 2000

Feb. 6, 2000

Stephen Figgins writes: > On the subject of providing worlds, not providing worlds, etc. Don't > we already live in a world with interesting problems to solve? I > would rather see something grounded in the real world - or at least, > the real internet world. Maybe there are some sections of the > internet that are more easily manipulated than others. Well, the Web itself seems like pretty good fodder, and if we are indeed likely to see a shift to XML as the main language of web-based data (producing, in other words, an actual parse-able web) then Python with an XML module becomes an extremely powerful tool for churning through massive amounts of the world. One of the things I'm interested in developing is a heavily-scaffolded framework (for younger kids) to create bots or agents (or whatever you want to call them) to dig through web-based content... to build little, specialized crawlers, or to post-process the results of search engines out there. As I say, the more we start seeing an XML-based Web, the more possible this becomes for (young) casual hackers. > scripting some MUD out there - building objects online would be better > than some isolated world you are trying to problem solve. The more > others can see it, comment on it, be impressed by it, the better. And > the less it is something contrived to teach a lesson, the more likely > it is that a lesson will be learned. The work and writings of Amy Bruckman (www.cc.gatech.edu/fac/Amy.Bruckman) are instructive here... she had kids as young as 9 and 10 programming, sharing code, and teaching one another how to do it. The key wasn't the technological superiority of the system (she built an IDE and a Logo-like layer on top of Pavel Curtis' MOO language), but rather that the whole thing was set up to be a collaborative working environment, where the kids were sharing stuff, rather than just solo hacking. The environment (I mean the conceptual and social environment, not the IDE) also provided the reasons WHY they were motivated to do it. - John Maxwell jmax(a)portal.ca ------------------------------------------------ Multimedia Ethnographic Research Lab (MERLin) University of British Columbia, Canada

3 5

On case sensitivity
by Skip Montanaro Feb. 5, 2000

Feb. 5, 2000

I'm just trying to catch up on this list. Sorry if I'm late beating a dead horse... A couple things come to mind. 1. Perhaps the language doesn't need to be changed. Guido talked about putting case-desensitization magic in the programming environment, not in the language. If that can be done well enough, then that can be the default there (with perhaps a flag to disable it). Most of us old-line programmer types will probably continue to use Emacs, vi, Joe, BBEdit or something else to edit our files anyway. 2. Dave Scherer wrote: eNGLISH IS NOT cAse SenSitiVe, although there are certainly strong conventions! But certain dialects are getting more so. As more and more people grow up with computers, the dialect of (written) English they use will more and more be the Internet dialect with its SHOUTING, *emphasis*, smileys/emoticons, and curious acronyms like ROTFL and RTFM. The upshot of this is that people will gradually get more comfortable with the idea and "SHOUT", "Shout" "*shout*", and "shout" mean subtly different things depending on context. 3. Dave also wrote: Cockroaches are much more numerous than humans, but I prefer humans to cockroaches in all respects. To which I respond: s/[cC]ockroaches/Windows/ s/humans/Unix/ <wink> 4. And later in the same message, there is an apparent contradiction with the cockroach statement: The needs of the (10M?) programmers in the world are vastly outweighed by the needs of the six billion normal people. They are always right and we are always wrong. Randy and Guido are 110% right about that. So we should stop cleaning our tables and countertops after dinner, right? <wink> The more serious point is that majority rule accepted blindly can have substantial negative consequences for minority members of the population. It frustrates me to no end to see people release software that *only* runs on Windows, even though I know that "majority rules" or "the VCs have never heard of Unix". I'm not suggesting that moves toward making Python case-insensitive are being undertaken blindly, just that the needs of the minority shouldn't be ignored. Skip Montanaro | http://www.mojam.com/ skip(a)mojam.com | http://www.musi-cal.com/ 847-971-7098 "Languages that change by catering to the tastes of non-users tend not to do so well." - Doug Landauer

2 2

Re: [Edu-sig] On case sensitivity
by Jason L. Asbahr Feb. 5, 2000

Feb. 5, 2000

Guido wrote: >Actually, I want to create an IDE that is sufficiently aware of the >syntax that it can tell assignment from use in most cases. Would it be reasonable to conceive of these IDE enhancements as middleware -- and make them part of the standard Python distro? The idea would be to allow third party IDE developers to hook into these extremely useful functionality sets... Cheers, Jason Asbahr Origin Systems, Inc. jasbahr(a)origin.ea.com

1 0

Re: [Edu-sig] Common Graphical Framework for Python Tutorials?
by Jason L. Asbahr Feb. 5, 2000

Feb. 5, 2000

Greetings, Quick intro: My name is Jason Asbahr, I've been using Python since 1.3, and it's now my favorite language. I presented a paper on using Python in interactive 3D environments at the 1998 conference in Houston, and I'm currently developing massively multiplayer persistent virtual world games at Origin Systems (http://www.origin.ea.com) -- using Python, of course. :-) I have a strong personal interest in technology education, both the teaching of technology and how technology can be used to improve education as a whole. Paul Fernhout presented some good points about the strengths of the Squeak Smalltalk environment. I suspect that merging Python and Squeak would be difficult, but building a Python learning environment using Squeak as a model is a great idea. To quote myself (ahem) in an old email to Guido: >There's a great video of Adele Goldberg's presentation at OOPSLA 1995 >called "What Should We Learn? What Should We Teach?" that might have >some application for the project. She presents some terrific ideas >for teaching fundamental OOP concepts (in Smalltalk) using interactive >2D graphical systems. I immediately thought how cool it would be to >port/rebuild such a system in Python for Python. It wasn't Squeak, exactly, but it looked like a good way to teach OOP without getting hung up in syntax issues. I need to review this tape again and post more specifics. :-) Cheers, Jason Asbahr Origin Systems, Inc. jasbahr(a)origin.ea.com

1 0