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

[David Reed]

On Feb 7, 2007, at 11:16 AM, 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.


For a CS0 course that is only spending a portion of the semester on 
Python, it probably makes little difference whether you use a 
procedural or object oriented approach, but I do agree with John that 
students learn what you show them first. I think the students can learn 
to use objects just as easily as they can learn to use procedures. My 
experience of students writing their own classes also matches  John's - 
the students find that much more difficult.


>
> 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?
>


If I were writing it, I would use strings as objects from the beginning 
and never introduce the string module - might as well get them doing it 
as they will eventually from the start. Other modules (such as the math 
module) show them how to use functions.

With regard to Peter's comments about decision statements - I cover 
sections 7.1-7.3 (if/eif/else) after chapter 4. As John points out, 
with his book you can easily cover them earlier and my students have 
had no problems with that (I've been using the book since the year 
before it was officially published).

Dave