python vs processing for introducing programming?

Hello, I've been using Python for about 7 or 8 years now to introduce my 10th graders to programming, and I've been quite happy with it. We start out with a week of Scratch and a week of RUR-PLE (which I love) before moving on to about 3 weeks of Python. Obviously they don't become experts in that time frame, my goal is to just give them a taste of programming. I've tried various Python environments and graphics libraries over the years -- IDLE with livewires, IDLE with the cs1graphics package, JES, vpython -- and they all have their virtues and pitfalls, at least for my application. I've recently become aware of Processing and am really intrigued. Here are some advantages I see: * some fun lessons on khanacademy to get started (a processing library for javascript, actually) * very easy installation, nice simple IDE * graphical from day 1, very easy interaction with mouse * there's a great book on using processing with Kinect (Making Things See, from O'Reilly) and I think I can demo and talk about some cool stuff from that The obvious downsides to me are: * no RUR-PLE * overall, Processing just isn't as real-world useful as Python I'd be interested in hearing from anyone with experience in teaching Processing to this age group, and anyone with any thoughts on the topic. Thanks, Andy Judkis Academy of Allied Health and Science Neptune, NJ

I'd be interested in hearing from anyone with experience in teaching Processing to this age group, and anyone with any thoughts on the topic.
Thanks, Andy Judkis Academy of Allied Health and Science Neptune, NJ
I probably shouldn't be answering this as I don't have the Processing experience, though would gladly attend a work shop at one of those "cultural literacy for STEM teachers" events in the planning. I've always advocating a mix of languages and it sounds like you get that with Scratch, its own language. I usually think of JavaScript as the other language, in conjunction with learning about the DOM. But then I also think of J from jsoftware.com, in part because it's so exotic and different from Python, the one I teach the most. I wouldn't see replacing Python at this point. The fact that it's so used in everyday science and industry makes it more than ready for prime time, both as a gateway (door opening) language and as an end in itself. My colleagues and I believe in more fusion among the STEM tracks and topics to where the lines between "mathematics" and "computer science" and "engineering" and "chemistry" and "physics" have all been blurred. One brings all one's knowledge to bear when solving problems. Individuals may specialize in their skills and haunt some workshops more than others, but the curriculum itself is more meandering. Students are encouraged to wander (the liberal arts ideal). What used to be called "vocational education" (where you use equipment, tools) has not disappeared. 3D printers are just starting to revamp that area. CAD is a bridge, and for that you need geometry / trig. GIS / GPS is likewise a core area where Python gets used (thinking of Esri products in particular). Against this backdrop, I'm sure Processing has a brilliant role to play, along with other classics. Kirby

On Wed, Sep 26, 2012 at 9:48 AM, kirby urner <kirby.urner@gmail.com> wrote:
I'd be interested in hearing from anyone with experience in teaching Processing to this age group, and anyone with any thoughts on the topic.
Thanks, Andy Judkis Academy of Allied Health and Science Neptune, NJ
I probably shouldn't be answering this as I don't have the Processing experience, though would gladly attend a work shop at one of those "cultural literacy for STEM teachers" events in the planning.
When I wrote the above, I was all wound up from writing this essay, kinda long, so just a link, but a good overview of my outlook, oft re-stated. http://mathforum.org/kb/message.jspa?messageID=7896983 I would expect these views to be unpopular on math-thinking-l, another list I've haunted, as it's so colored by the "object oriented outlook" (OOO or O3). :-) Kirby

Hi, have you noticed a recent post about http://interactivepython.org/courselib/static/thinkcspy/PythonTurtle/hellotu... based on http://www.skulpt.org/ and Coursera starts a course on 15th of September with the same tool https://www.coursera.org/#course/interactivepython On Wed, Sep 26, 2012 at 2:06 AM, Andy Judkis <ajudkis@verizon.net> wrote:
Hello,
I've been using Python for about 7 or 8 years now to introduce my 10th graders to programming, and I've been quite happy with it. We start out with a week of Scratch and a week of RUR-PLE (which I love) before moving on to about 3 weeks of Python. Obviously they don't become experts in that time frame, my goal is to just give them a taste of programming.
I've tried various Python environments and graphics libraries over the years -- IDLE with livewires, IDLE with the cs1graphics package, JES, vpython -- and they all have their virtues and pitfalls, at least for my application. I've recently become aware of Processing and am really intrigued. Here are some advantages I see:
some fun lessons on khanacademy to get started (a processing library for javascript, actually) very easy installation, nice simple IDE graphical from day 1, very easy interaction with mouse there's a great book on using processing with Kinect (Making Things See, from O'Reilly) and I think I can demo and talk about some cool stuff from that
The obvious downsides to me are:
no RUR-PLE overall, Processing just isn't as real-world useful as Python
I'd be interested in hearing from anyone with experience in teaching Processing to this age group, and anyone with any thoughts on the topic.
Thanks, Andy Judkis Academy of Allied Health and Science Neptune, NJ
_______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
-- Jurgis Pralgauskis tel: 8-616 77613; Don't worry, be happy and make things better ;) http://galvosukykla.lt

Hi, I'm just becoming a teacher, but I've seen a collegue teaching processing and observed a few things that I don't like about it: - Processing comes with it's own IDE and the files you're writing are embedded in the real programming. The pupils don't have any change to get an overview of the "program". With a small python script OTOH, there's just the script and that's it. - Adding external (image) files to a processing program has puzzled the pubils and me too. You can't just download to your home folder and refer to a file with the filesystem path. Processing bundles your project to a java jar and so the downloaded files need to be added through the IDE. - Processing has some very ugly, global state and procedural idioms that I'd prefer not to teach to my students, like: textFont(letterGothic, 32); // sets the global text style text("word", 10, 50); // outputs text a more object oriented way would look something like style = new TextStyle(WHATEVER); style.print(WHATEVER); - Processing confronts the students with functions from day one, because all code must be embedded in one of two functions (setup and draw, IIRC). Regards, Thomas Koch, http://www.koch.ro

I hope you stick around Thomas. I'm one of the old timers here but not a list owner or moderator. My initial recruitment into Python was through my search for ways to do 3D (spatial) geometry in cool ways + Guido's on-line CP4E essay. The web was just getting going and there was a paucity of polyhedrons out there in jpeg or gif format. I used to count how many. Later when it looked like I was using the term "CP4E" in new ways I changed it to "P4E" (dropping C) to distinguish it from Guido's, and "HP4E" which is kinda technical (hexapent is a way of dividing the surface of a sphere, new book called Divided Spheres, a primer to Ed Popko, has me in the biblio). As far as Processing goes, my ears perked up at a party recently, some young and cool dudes chatting, one of them raving about Processing. I wanted to but in but wasn't sure how, so I just listened. I've admired how Ruby may be used to program Google Sketchup. "What might Processing do *for me*" I wonder, greedily rubbing my hands. My general sense is we don't need to shield students from nasty aspects of whatever languages as they'll initially / naturally want to try many, and we should encourage that adventuresome impulse that says "I'll trying anything once". They'll inevitably encounter VBA, old (even new) FoxPro code, lots of Java in the course of bouncing around in our worlds. We hope also Scheme, maybe even some J who knows. I've got Haskell running on my Mac finally, and find lots of similarities with Python, even though they're across the "static typing" divide from one another (their both typed, just Python's type system is more open to duck types). New languages are coming along. At the latest OSCON, it was all about Go for me (the new language). I'm mostly just dabbling, as my training has encouraged me to do. Python brings some gravitas to the classroom in that we already see it as "world dominating" in the sense of having lots of real jobs doing important stuff in many walks of life. Python is a masterful invention, used with appreciation by code wranglers around the world. There's an analogy with English: would as many people attempt this difficult language if it was only the great poetry and Shakespeare at the end of the tunnel. No. It's worthwhile to learn because it's so widely used for everyday communications. Otherwise why put up with all that crazy spelling with idioms galore. English is like the Perl of human languages, concise to the point of cryptic mixed with verbose and out of control (the skill of the coder matters so much -- in Java they tried to make the boilerplate stronger). My own freshman course in programming (engineering department) was a wild ride through a whole bunch of languages: FORTRAN, APL (my favorite of the bunch), PL/1, SNOBOL, LISP, Assembler (simulated). Not much OO because this was 1970s and Smalltalk was not running on our IBM 360/370 I don't think. I had to pay visits to PDPs and other labs to try other tools, such as Tektronix graphics terminals (with and extended version of APL as I recall), really rad. However this was just me being "well rounded" as a liberal arts kinda guy. I was anchoring in the philo department (Princeton had a good one, but the engineering was good too). Anyway, to make a long story short, POV-Ray was the free renderer of choice, available on CompuServ with its own kind of Open License. To write scripts for it, though, was tedious, so the job was to use scripting languages to spew out "scene description language" (plugging values in to boilerplate). That became a back end for VRML output as well. The kind of coding I was doing anticipated a way more mature project called AntiPrism by Adrian Rossiter, which I believe was used for many of the pictures in the Popko book cited above. Kirby
participants (4)
-
Andy Judkis
-
Jurgis Pralgauskis
-
kirby urner
-
Thomas Koch