Having come from APL, later Logo, I'm used to interactive REPL (direct
interaction with an interpreter), gradually building up a "namespace"
i.e. as you define turtle-drawing functions, these get remembered.
You save to disk for persistence, but the primary experience is of
being in a "session" and having a "workbench" of tools you've defined
(more like in bash -- not afraid to compare Linux shell with Python
shell).
Tim Peters reminded me of ISETL awhile back, another attempt to
harness an interpreter for math learning.
There's a proud history here, ongoing of course.
Where I think the idea of "a program" misleads is it may get you
thinking about a full blown application, menu driven or GUI, where
everything is tied together in some main loop, lots of infrastructure
in that case.
In that sense, very few .py files in Standard Library are "programs",
probably why we refer to them as "modules" instead.
We might say one "authors" or "writes" a module; I'm not sure the verb
"to program" deserves such a central position here.
We're writing and saving algorithms for our math library, making use
of stuff we've proved on the white board, or accepted as proven from
reliable sources (or maybe we're experimenting with conjectures, who's
to say...).
Python starts us in "calculator mode" (or can, if you've got IDLE set
up right), and that's all REPL (read, evaluate, print, loop), all
session-based thinking. Modules are more like "frozen sessions" i.e.
all those classes and functions you defined (all objects) are now
ready for reuse, for importing ("thawing") in other modules etc.
But there's no implication of some "glue" holding all the classes and
functions together, besides the running interpreter itself.
When you import a module, it's like typing it really fast into your
current session, giving your interpreter (our snake) more stuff for
its memory. We can talk about pickling and marshalling too. Go ahead
an say "persistence layer" why not? But the older idea of "library"
is probably what most will hook onto.
For example, one of the first namespaces we'd import in math class
would be... (drum roll, suspense), the math module.
But 'import math' gets you a grab bag, a fish tank, an aquarium, a
zoo, a namespace... all these images are way better and more accurate
the "program".
What you get is a bunch of balloons (objects on strings), and when you
go a = b, you're assigning another string to the same balloon. At
least in Python that's the model, not saying all languages share the
same model, which is why you shouldn't teach a language without also
teaching its core concepts.
Let's not pretend there's some pie in the sky generic model and write
pseudo-code for it, or we'll just end up with yet another language
with the disadvantage of not running (call it CTL for short -- always
just around the corner, at the end of the rainbow, nothing at hand is
ever quite good enough because...).
Anyway, we all know Python is "good enough" and in that mental model,
a module is like a "bunch of balloons" (good flying circus imagery,
maybe a clown holding the strings).
Another bias the "programmers" bring to our math class, which we don't
necessarily share, is this tendency to use raw_input or input to
"prompt" for data, e.g. "Please enter today's date: _ ".
The psychology here is inherited from "programming for a user" i.e.
I'm the behind the scenes puppet master programmer, and who I'm
writing for is someone out there in the audience who doesn't get to
see backstage.
There's this dichotomy between "end user" and "coder" that's very
strong, such that "programming" is a kind of "performance art", with
CS the "back stage science".
In contrast, since FOSS and the invention of interpreter-based math
curricula (on .NET/Mono, on C, using whatever REPL or language, maybe
Scheme **), we're happy to swap code around, share, but we're all back
stage coders, are peers in the sense of knowing how to create modules.
There's no "clueless audience" that "doesn't know FORTRAN". This is
math class, and we all know how to write math notation (including the
executable kind, which we prefer -- marketing: "ours runs, theirs
walks or just sits there").
We simply assume the source code is available, along with a test
suite, so go ahead in check out the documentation and go crazy, import
our resources and mix 'em in with your own. That's the liberal arts
culture.
But raw_input? That's a throwback to the days of BASIC, gimme a break!
Kirby
** please feel free to refer to Python's lambda as 'little lambda' (as
in 'Mary had a...'), and suggest to your department that one reason
Python is such a good entry point is that it has the seeds of these
other languages, e.g. in the LISP/Scheme family, lambda is all grown
up, is something huge, and people worship it, name their calculus
after it etc.
_______________________________________________
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig
