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

Peter Chase pchase at sulross.edu
Wed Feb 7 17:45:49 CET 2007


John Zelle wrote:
> 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
>
>   
Good thing.  I use Python as a way of introducing concepts without a lot 
of Java-style overhead.  Presumably once they get the ideas (including 
OOP) we can tackle the monstrous edifices of the official languages.
-- Peter



More information about the Edu-sig mailing list