[Tutor] Teaching Objects

[Martijn Faassen]

John Kleinjans wrote:
> 
> Re: teaching programming (to people who don't know
> programming) (at all) using Python.
> 
> So let's say, just to set the scene, that someone who has
> *never programmed before at all* has now messed around
> with Python a bit in interactive mode; and then has written
> a couple short scripts to, maybe, solve quadratic equations
> or make a calculator, something like that.
> 
> We told this person about variables and assignments, about
> sequence and branching and loops... so this person is just
> *beginning* to get a feeling for (I can't think of the word
> now... imperative? Like a language like C, or QBasic does.)
> programming.

Yes, that's generally called 'imperative programming'. I think I've seen
'procedural programming' too in this context. Displined use of all these
facilities is called 'structured programming'; though in fact the time
when structured programming was the big methodology (the place object
oriented programming is in now) was before my time. :)

To compare, we have:

functional programming

Lisp, Scheme, Haskell, etc. Emphasis (I'm not overly familiar with
these) on making functions that call functions that call functions,
often with recursion thrown in. All this function calling finally gives
you the result. Rumored to be very pure, powerful and elegant. See
Python's 'map', 'filter' and 'reduce' functions for examples of this in
Python. Python, though it can be made to do just about anything, is
however not a natural language to do function programming.

logic programming

Prolog. I'm not very familiar with this either, but basically you write
up a lot of declarations (i.e. "if A is male and B is a parent of A,
then A is the son of B"). Then you ask the system a question and it
automagically gives you the answer. Shares a lot of the elegace, power
and recursion with functional programming. :)

object oriented programming

This is usually associated with imperative programming; though one hears
about people doing OOP with Lisp or Prolog too, this often does not seem
to be the most natural way to do things in these languages. The
procedures/functions of imperative programming are called methods or
member functions, and are bundled together with the data they manipulate
into classes. The classes can be put into a hierarchy where classes are
related to each other, but add or change functionality (additional data,
and additional/changed methods). The actual work in OOP programs is done
by objects, which are instantiations of the general class template
(Class Elephant, and Dumbo is an object of class Elephant..or perhaps of
derived class FlyingElephant, really :).

> I'd think that what this person needs is a sequence of some
> `packages' that introduce a tool (command, function) with
> an example short, simple application program, and a
> couple simple projects that use that tool; then another tool,
> another sample program, and a few more related projects;
> and so on.

Yes, this sounds like a good idea, and Python's modules are a natural
fit. 

Take for instance the 'string' module. It contains lots of powerful ways
to manipulate strings. What you could do is to make a learn_string.py
module, that imports string and demonstrates some of its capabilities
(in functions that can be called from within the Python interactive
mode, perhaps). Perhaps it also wraps up some of the more difficult to
understand functions into more easily understood ones, though perhaps
the 'string' module is easy enough to grasp by itself (function by
function, of course).

Take a look by the way at the 'turtle.py' module that is now distributed
with the new Python 1.5.2 distribution. It's not documented yet, but it
is based on the Logo method to teach children programming. I'm not
familiar with Logo at all, but basically you learn to program playfully
by programmatically instructing a turtle to move around in patterns on
the screen. The turtle draws a line wherever it goes, so you can make
simple drawings. Beginners get get good visual feedback on what you're
doing this way. In fact, unconsciously (I wanted to make games) I
applied the same visual feedback technique by using moving graphics a
lot when I learned to program. :)

> And along the way, when appropriate, include objects in the
> sample code. Explain *why* to make objects and *how* to
> do it, too; what they are and when to use them; and begin
> some discussion of programming style (start good habits now).

Good habits can't start early enough, of course. When you introduce
variables, tell them to use consistent variable names, and better long
names that are understandable than short ones, etc. Same for function
names.

Objects can be introduced when talking about 'file objects' in Python,
for instance. The file object in Python is relatively simple,  and
demonstrates methods and encapsulating data well. It is not too hard for
people to make their own file objects, for instance a memory based file
based on a Python list. You can then demonstrate how it's easy to
replace one file object type with the other in a program. Instead of
writing to a file, you write to the screen, or vice versa.

Ideas of objects are also introduced when discussing special methods of
the built-in sequence objects (dictionary.has_key("foo") for instance).
The problem here is that in the current Python implementation there is a
split between these built in 'types' objects, and Python class instance
objects; you can't directly inherit from a built-in type. This can get
confusing, though it's very well possible that I'm overestimating this
confusion right now. :)

> Anybody out there have some cool easy Python tricks?
> 
> Anybody want to explain Who What When Where Why How
> of objects in Python?

Okay, just gave you some pointers. Feel free to ask away!

Regards,

Martijn