[Edu-sig] Using objects early was Procedural front end for Zelle's graphics.py

John Zelle john.zelle at wartburg.edu
Wed Feb 7 17:16:42 CET 2007


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     
john.zelle at wartburg.edu          (319) 352-8360  


More information about the Edu-sig mailing list