On Wednesday 07 February 2007 8:32 am, Vern Ceder wrote: > Brian Blais wrote: > > Peter Drake wrote: > >> Is anyone else using Python procedurally in an intro course, or is what > >> I'm doing here perverse? > > ... > > > this one, *for the audience you are dealing with*. I've taught > > programming for a number of years, both OO and procedural, and I find > > that if someone has math phobia, *and* you only have a limited time (like > > a semester), then OO is way more powerful than you need to get into, and > > is thus unduly confusing for the students. For those who have had a > > little programming, OO can make some things very nice.
I think it's important here to differentiate between doing OOP, that is, doing design with classes vs. just using objects. Unlike Kirby, I personally see nothing wrong with going the procedural route with these students, but I don't think that using some objects in this context is particularly confusing to students. I can only make sense of the statement "OO is way more powerful than you need to get into" in the context of teaching OO design (encapsulation, polymorphism, inheritance). Using pre-existing object types requires no more conceptual machinery than function calls, and is really just more procedural programming. Until I point out the distinction (which I do, very early on), the vast majority of students are not the least bit bothered by the "inconsistency" of mixing method calls using dot notation with regular function calls. In my experience, beginning students tend to use whatever operations they're shown in the way that they are shown. To take a concrete example, they see that they can find the length of a list by doing len(someList) and that they can reverse a list by doing someList.reverse(). When they later want to find the length they use len(mylist), and when they want to reverse it, they use mylist.reverse(). It doesn't even occur to them that it "should" be reverse(mylist), because that's not how they were shown the operation. It's only the advanced students who will generalize and wonder about the difference. And when they do, then you can explain that it's really just syntactic sugaring: len(someList) is another way of writing someList.__len__(). As Peter pointed out earlier, you can do pure procedural programming in Python, but restricting yourself to methodless programming quickly limits the interesting (and easy) projects that can be tackled with the rich existing libraries, because the programmers of those libraries have taken advantage of the true power of OO alluded to earlier. The motivation of tackling projects that, say, mine data from the web or manipulate images is more than sufficient payback for whatever (in my experience, very small) challenge is introduced by using (not designing) objects. I'm wondering what others on the list think about this subject. As I look to revising my textbook, one of the things I'm carefully considering is the fact that use of the string library is, if not deprecated, greatly discouraged. In the first edition, I move from functions with numbers to functions with strings as a way of building on students previous experience with "computing" in the context of mathematics. Objects are introduced slightly later through computer graphics examples. If I switch to using string methods, then the object notation will be introduced even sooner. In your opinions, is that a good thing, a bad thing, or doesn't it matter? --John -- John M. Zelle, Ph.D. Wartburg College Professor of Computer Science Waverly, IA [EMAIL PROTECTED] (319) 352-8360 _______________________________________________ Edu-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/edu-sig
