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

[kirby urner]

On 2/7/07, Dethe Elza <delza at livingcode.org> wrote:
>
> > Stick to FORTRAN maybe?
>
> Ad hominem attacks aren't going to convince anyone.


And which hominem was that I wonder?

I think going out of one's way to shield students even from dot notation,
let alone simple class definitions, is the kind of bastardization of the
Python language we don't want to see, for the sake of Python.

Could be the kiss of death for an intelligently designed language, to
have it used in such circumstances.

It's ugly, it's not what Python is about.

Why teach rotted out Python under the CS banner or vice versa?

In Python "everything is an object".  If you're not going to explain that,
I don't think you're really teaching Python and shouldn't represent that
you are.


> > Your analogies of OO with advanced mathematics, thereby suggesting
> > that OO should be seen as beyond the reach of CS0 is precisely the
> > attitude I disagree with.
>
> I don't see anyone arguing that OO is "beyond the reach" of CS0.  I
> see them arguing that it's only one semester to introduce a *lot* of
> new concepts, only some of them having to do specifically with
> programming and computer language notation.  Decisions have to be
> made about what to cover.  Sometimes, for some teachers, OO makes the
> cut in some form or another.  But OO is not some magic bullet that
> *must* be taught in order to learn about computers.  Remember what
> Djikstra (I think) said, "computer science is as much about computers
> as astronomy is about telescopes."


It only takes a few minutes to talk about how Djikstra revolutionized
procedural programming by moving us from the spaghetti code era to
structured programming.  That was a paradigm shift as well and part
of a longer story that, in my experience, students enjoy hearing, find
edifying.

"Object oriented" is such a buzz word, plus is so pervasive in commerce
and industry.  What does it really mean?  Aren't we even going to answer
that question?  It's a part of the story (not the whole story, but a vital
part).

I'd have a hard time taking any CS0 seriously that saw fit to cut out *any*
mention of OOP.

> It's woven into our everyday patterns of thought, OO is, including
> > ideas
> > of inheritance, even polymorphism.
>
> This is where I disagree most strongly.  When OO was introduced it
> was often taught like this, which resulted in a huge amount of
> confusion, because what we model with OO has *very little* to do with
> objects as we normally think of them in the real world.  Making that
> assertion to students can be very misleading.


Yeah, we definitely disagree on this.  Notation like doorbell.ring(),
car.filltank() and dog.bark() is still the way to get the ball rolling with
beginners I think.

Imagine ordinary things, think of what they might do, what attributes they
might have.  thing.verb() and thing.property -- the essence of dot notation.

It's still taught this way for openers.  I don't know when you think that's

changed.


> And even if we wanted to make a case for Python objects being in some
> way similar to real world objects that we're all familiar with: the
> real world is parallelism: things don't happen in a given order,
> they're all happening at once.  But that doesn't mean we should teach
> threading or other forms of parallelism in CS0 (unless we're teaching
> Erlang rather than Python).


I definitely think CS0 should include the *concept* of multiple processes
and/or threads, with the job of the operating system to divide its attention
among them.  The idea of a clock, tasks, and priorities -- all very real
world (people multi-task), all very accessible.

You can talk about threads without actually coding threads, just like you
can talk about how GUI programming is more "event driven" than the older
style of "menu trees".

So much of a good CS0 course (like I had at Princeton) involves
storytelling.

Get stuff across with examples, with war stories drawn from real life.

Not everything mentioned or elucidated has to be front and center in the
lab.


> Actually, Lynn Andrea Stein does propose introducing threads early on
> in CS101 (http://faculty.olin.edu/~las/2001/07/www.ai.mit.edu/people/
> las/papers/cs101-proposal.html), but that's in a CS-majors class at
> MIT (and in Java).
>
> > What a great opportunity to connect ordinary patterns of thought with
> > a formal, machine-executabe language.  What a waste to ignore this
> > opportunity.
>
> It seems to me that "connecting ordinary patterns of thought with a
> formal, machine-executable language" is exactly most of this thread
> has been about, and what draws each of us to Python.  Whether that
> involves dot notation or "ribs" from day one is a rather trivial
> matter of syntax, IMHO.


Yeah, if it's just about whether "from day one" that's pretty trivial.

Day one might be showing 'Warriors of the Net' (cartoon).

But if it's about whether you can say you're "teaching Python" when you
never mention __init__ (constructor) *at all* during the entire course, then

I'd have to say no, you've not really taught Python, just used it as a means

to some end.

You've avoided the language more than you've bothered to teach it, really.

And that's maybe OK (maybe the course really uses other languages more,
like Scheme or Ruby), as long as you don't advertise you're "teaching
Python"
in the course description (that'd be a kind of white lie).

>> I feel sorry for students who get suckered into taking such CS0s and
>> wish they wouldn't get their first impressions of Python from such
>> courses.

> This just comes across as sour grapes and more ad hominems.  The

And your pompous opining comes across how?

> important thing is to teach the *concepts*, not whether they are
> strictly OO or even whether they are Python.  The syntax is just a
> means to an end.  Python has a rather elegant syntax, which helps to
> keep it out of the way of the actual material, as opposed to Java
> where you have to struggle through layers of syntax and mechanisms in
> order to get even simple things done.  And Java's insistence on
> enforcing all objects all the time just gets in the way when objects
> aren't what you need.
>
> --Dethe

Yeah, but *which* concepts?  I think a CS0 that *features* Python as an
interesting specimen (a language) but avoids all talk of classes and
subclasses, is probably lame.

Is it possible for a CS0 to be lame in your book?  You don't believe in
any ranking or ordering among the CS0s or this world?

Personally, I'd prefer as CS course steer clear of Python if the plan is
to simply force it to play dumb.  Better no Python at all than Python in a
bad light.

Kirby
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/edu-sig/attachments/20070207/95a33f7b/attachment.html