Just to elaborate a bit, I do get around to telling longer stories,
sharing "geek lore" as I call it, and the story I tell goes something
like this:
In the early days of assembly language, it was all about conditional
jumping to get choices or forks in the road, which led to a first
generation of higher level coder to write "spaghetti code" even when
infrastructure for subprocedures was provided.
Djikstra went on the war path to rationalize coding around a main call
sequence with branching to subprocedures in a tree pattern, reusing
library utilities, but with much less reliance on global variables,
context, side effects, other subtle stuff (all that
"anti-encapsulation" infrastructure). "Never use GOTO" was his advice
and many languages took it out.
*That* was the hallmark of the 'procedural programming' era (might've
been called 'subprocedural' but that's picking nits), to never use
GOTO, or at least not gratuitously (which is almost always is), to
always do a kind of top-down style with a main call sequence.
The OO revolution built on top of the procedural programming
resolution, by giving us encapsulation and inheritance infrastructure
that would more closely model the guts of a knowledge domain, i.e.
your job is to think in terms of cells, DNA, airports, train yards or
whatever but *not* in terms of some CPU with access to memory (way too
low level and irrelevant to the problems in scope).
OO was also of key importance given the evolution of GUIs and
non-menu-driven modes of interactivity, where users could (and still
do) fire off events from a mouse, keyboard, any number of screen
widgets, and the code had to be "ready" (i.e. "listening") -- much
more like interrupt-driven operating system design, with event queues
and so forth.
This is still a challenging kind of programming, goes into threading
and the rest of it, but we get our feet wet with such curricula as
John Zelle's, which relies on the cross-platform Tk widget set.
I prefer doing more with SQL first, introduce "multi-user" as an ACID
challenge (thinking about airline reservations systems), then turn to
the Web for widget programming, skip the whole "thick client" business
until a later course. The old LAMP infrastructure really doesn't
require any specialized widget programming, just XHTML forms, buttons
and so on.
Python is a clean implementation of the OO style of thinking, and if
your knowledge domain is amendable to decomposition in terms of
objects, then chances are there'll be a way to express it in OO terms.
Instances are a lot like subprocedures in some ways, in promoting
encapsulation, not willy-nilly sharing of globals, plus we still don't
need GOTO if we ever did (we did with assembler, still do).
I've notice high schoolers are able to follow all this, a kind of
storytime interlude, like when a teacher reads a story to the group,
although here I ad lib, might project a comic strip sometime.
I could also see doing this history in a more cartoon form, have been
urging O'Reilly to branch into the cartoon business more concertedly,
but that's a difficult transition for a wood pulp publishing giant
('Head First' a good first step).
There's lots more to this lore (some of which I get to, a lot of which
I'm still learning), but the mode is one of standing back, overview,
altitude viewing. That's very important in introductory classes, in
literature, philosophy, art or mathematics. We neglect it at our
significant peril in my view. Leave out the historical dimension only
if you wish to consign your curriculum to the ash heap of history is
my motto.
These days, I'm less likely to work directly with high school aged
students, am more peddling my Python Briefing to their teachers, so
they're the ones getting this lore, perhaps to pass it back to their
math classes, along with a syllabus of optional viewing DVDs etc.,
plus Neal Stephenson's 'In the beginnning...' is still a classic.
Kirby
On Mon, Sep 8, 2008 at 9:41 AM, kirby urner <[EMAIL PROTECTED]> wrote:
> Thanks for the clarifications, good to know both options (receiver and
> receiverless) are both in the mix.
>
> Our use of 'procedural' may confuse some students as OO syntax is
> eminently step-by-step with flow of control and all the rest of it,
> very recognizably procedural the way I learned the term, with or
> without the explicit dot notation (which is difficult to hide in real
> Python).
>
> I'm inclined to *not* see 'procedural' and 'object oriented' as
> orthogonal concepts i.e. they mix together. Where I do see a big
> dichotomy is in whether one is expected to define new classes oneself,
> or simply use the ones provided.
>
> Apparently early versions of Visual Basic were "read only" in terms of
> not having a class defining infrastructure, merely giving developers
> access to canned OCX objects (instances) with canned APIs, but I could
> be wrong, that's not a track I've ever followed, even to this very
> day.
>
> As I mention in my Chicago talk, I tell my students "I've never heard
> of procedural programming, it gives me the creeps" but that's just a
> rhetorical device to get the ball rolling, as I start with dot
> notation immediately, within the first 10 minutes. But that's because
> I'm teaching core Python, not another language *implemented* in core
> Python. These aren't little children.
>
> They may have done Logo or other 3rd person avatar controlling (ala
> Sims) well before taking my class, so I presume this as background,
> allude to Sims as "objects" and so on, project a YouTube or two if
> they seem unclear what I'm talking about.
>
> Kirby
>
_______________________________________________
Edu-sig mailing list
[email protected]
http://mail.python.org/mailman/listinfo/edu-sig
