To the 'Pfff, but python sucks. It's too simple' crowd, you can pretty much ignore them - that or get some code off code.activestate.com that does something gnarly to show off. I've even got a recipe on there, but it's probably not the best one for Java programmers (or python programmers, come to think of it :-) As for teaching programming, I recommend staying away from classes at the start, but introducing objects early. Students can easily understand the idea of objects and methods before learning about classes, because lists, strings, dicts, etc are objects with methods. Once they are familiar with built in classes/types, then you can introduce custom types (classes) to them. I've just had the first week of a semester teaching python to stage 1 Computer Science students, and that's how we're doing it (and have done it in the past) with reasonably good success. Cheers, Carl. On 15 July 2011 15:20, Corey Richardson <kb1pkl@aim.com> wrote:

I was discussing programing with some peers at an MIT summer program, and many of them came from the "JAVA AND OOP!" type of places to the point that, when the opportunity came up for them to learn the basics in a seminar, a few said "Pfff, but python sucks. It's too simple". Is it just me, or should simplicity be a Good Thing? </rant>

But, my real question to you educators is, which paradigm do you use when first teaching programming, and why? My peers cite OOP because, frankly, it's the only thing they've learned and have heard that e.g. procedural programming is bad. Personally, I like to use procedural (this is in Python, of course) for as long as possible. I don't even mention objects for a while, they aren't necessary or even desirable in many instances. I love using games as a project, and that's when I swoop in and bring up objects. My segue are usually the monsters of a text based game. I don't have them design an object for everything because it introduces complexity without benefit. Of course, it's not as flexible/correct a program as it could be, but it's a nice slow ease into OOP. But it certainly isn't the ONLY paradigm out there, and certainly not the most useful for everything.

Any other insights? -- Corey Richardson "Those who deny freedom to others, deserve it not for themselves" -- Abraham Lincoln

_______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig

On Thu, Jul 14, 2011 at 8:20 PM, Corey Richardson <kb1pkl@aim.com> wrote: << SNIP >>

But, my real question to you educators is, which paradigm do you use when first teaching programming, and why? My peers cite OOP because, frankly, it's the only thing they've learned and have heard that e.g. procedural programming is bad. Personally, I like to use procedural (this is in Python, of course) for as long as possible. I don't even mention objects for a while, they aren't necessary or even desirable in many instances. I love using games as a project, and that's when I swoop in and bring up objects. My segue are usually the monsters of a text based game. I don't have them design an object for everything because it introduces complexity without benefit. Of course, it's not as flexible/correct a program as it could be, but it's a nice slow ease into OOP. But it certainly isn't the ONLY paradigm out there, and certainly not the most useful for everything.

Any other insights? -- Corey Richardson "Those who deny freedom to others, deserve it not for themselves" -- Abraham Lincoln

I like the Lincoln quote. Many approaches have validity of course, especially in the hands of someone experienced who keeps it interesting. When I first splashed into programming, OOP had yet to hit, but it wasn't like there wasn't already a veritable menagerie of amazing languages -- even sans OOP. Like, we had SNOBOL and APL and PL/1 (just a few I got to mess around in). I transitioned to OOP along the xBase track, as many did: dBase II, dbase III, dBase IV, Clipper, FoxPro, FoxPro for Windows, and Visual FoxPro (VFP). Some of my peers along that track are just beginning to appreciate Python, now that Microsoft has signaled it's pulling the plug on VFP. http://fox.wikis.com/wc.dll?Wiki~VFPRoadMapDiscussion The J community (J being a successor to APL (or a mutant child of?)) uses a grammar-teaching approach to teaching programming, referring to verbs, nouns, adverbs, other parts of speech as parts of its language. http://www.cs.trinity.edu/~jhowland/math-talk/functional1/ Following that model, I sometimes teach OOP by writing things like: noun.verb(args) thing.adjective thing.verb() noun.property and so on, deliberately confusing "parts of speech" talk with the OOPy stuff. Then I teach looking at the world that way, not using a computer language. What are the properties and behaviors of a flower? A panda? Analyze an airport in terms of its objects and processes. Come back to computers when you're ready, take your time. But then when I can get away with it, my topic is not "programming" or "CS" but a more exotically named "digital math" or (last year) "martian math". In the more formal presentations, the latter is a topic area within the former: http://wikieducator.org/Digital_Math In this approach, you want to develop an awareness of types (types of things -- like types of biotum) and their respective namespaces. This dovetails with Carl's focus on objects before classes. A "list" is a convergence of many concepts, a "dict" is another, an "int" yet another and so on. A "type" is not just a simple thing. Knowing about types helps us learn about math, with its concentric N, Z, Q, R and C types. In treating computer languages as math notations, we're treading somewhat in the footsteps of Russell and Frege (etc.), except we're using Stallman type tools for building our machinery, more than the tools of the so-called analytic philosophers (Quine etc.) Kirby @ Pacific Lutheran University (PLU) (visiting)