[Edu-sig] Math + Python: reviewing some themes (long)

[kirby urner]

On Tue, Jan 26, 2010 at 2:53 AM, David MacQuigg <macquigg at ece.arizona.edu>
wrote:
> kirby urner wrote:
>>
>> I've been hyping "digital mathematics" as a kind of niche marketing term,
>> as distinct from "discrete" but is this wise?   Per math-thinking-l
(another
>> list), I'd say I'm in the distinct minority in thinking "digital math" is
a
>> good term.  It's unexplored, not conservative, whereas discrete math is
>> already accepted and entrenched.

...

>
> I would call it "Computational Thinking".  There have been a series of
> articles on revising CS curricula in recent issues of Communications of
the
> ACM.  I recommend the articles by Chris Stephenson and Peter Denning
> (December 2009).
>

Thx for the pointer!

INTERNATIONALIZATION
===================

Singapore Math, popular among home schoolers / scholars, has been explicitly
IT-friendly for a long time and I'm wondering if something more like MFTDA
will be issuing forth from that corner.  Wouldn't surprise me.

A Japanese equivalent might base itself around Ruby for coding but otherwise
seem somewhat similar.

Phillips Academy is a pace-setter, not unlike West Point, so I'm sure this
curriculum is getting eyeballed by education experts overseas (if they're
doing their jobs).

I've been sharing it around the Portland for sure, and we're quite the
cosmopolitan hub, news spreads...

I just think "digital math" (whatever we call it) is hovering in the global
Zeitgeist these days, MFTDA another harbinger, a positive sign on the
horizon.

Over on math-teach today, we're getting links like this one:

http://www.dougengelbart.org/home-page/welcome-to-the-bootstrap-alliance.html

It's not like Seymour Papert or Doug Engelbart wree born yesterday or
anything.  It's just that NCTM is finally taking more interest in Web 2.0
and such topics.

http://nctmconference.blogspot.com/2009/04/blogs-tweets-and-web-20.html

http://www.slideshare.net/mcleme4419/eclips-nctm-boston-secondary

etc.

>> 3.d OBJECTS FIRST?
>> ====================

....

>>  What examples do teachers wish to contribute?  What would be a good
>> introductory example of multiple inheritance I wonder?  I recall David
>> MacQuigg sharing some examples where __mro__ (method resolution order)
made
>> an appearance.
>
> MRO was an advanced topic in an advanced chapter on OOP, not anything I
> would include in an introductory course.  In fact, I wouldn't even make
OOP
> a special topic.  It's just the most natural way to solve a lot of
problems.

In my view, the promise of OO, starting with Smalltalk, was to mirror a way
we already think.

The word "object" does not belong to computer science originally, but to
ordinary language.

Dot notation is supposed to be expressive because we're *not* trying to
inculcate some inner circle knowledge of computer internals, memory
management, garbage collection.

We're just leveraging what's already a feature of ordinary thought patterns.

Lesson plan:

===

Student A comes to the front of the room, writes a few commands on the white
board she is willing to obey....

>>> carla.walk(10)

>>> carla.say("Hello")

>>> carla.dance_move(1)

Student B holds a pointer, and in response to requests (raise hands,
polling), points to a requested action.  Student A carries out the requested
behavior.

Kids who've played Sims already know the drill.  We're talking about
puppets.  There's no computer anywhere in this picture, just dot notation
and a way of triggering behaviors.

Followup:

Get volunteers A, B, C in front of the room and have a wadded up piece of
paper as an argument.  Call that a "message object" and have commands for
passing it:

>>> carla.has_message
True

>>> carla.pass_message(jim)

>>> carla.has_message
False

>>> jim.has_message
True

etc.
===

BIOLOGY FIRST
================

>  Students should be *using* objects (lists, etc.) from day 1.  Then, if
> there is time later in the course, I would show how to *design* objects.
>  Even then, you really don't have to say much about inheritance,
> polymorphism, abstract classes, MRO, and all the stuff that professional
> programmers will get in later courses.
>

My preferred technique, described over the years as "cave painting" involves
putting something rather simple on the screen.  Walk through a Dog and
Monkey class, then show how you might move the digestive tract methods, eat
and poop (stomach a list) to the Mammal class and inherit.

This is just a language game and doesn't have to be that intimidating.
Biology is already cram packed with this inheritance metaphor, is where I'd
argue CS got it in the first place.

If the objective is to teach STEM subjects (the buzz word), then we might as
well appeal directly to the biology teachers at this point, suggest they
leverage the Python knowledge students are getting down the hall, in their
math classes, to reinforce the idea of genetic inheritance and species
differentiation.

In sum, I think the best way to teach OO is not make it *not* a strictly
computer science topic, but just a science topic more generally.

Something like full blown UML would be overkill, but if your job is to
design an airport, or manage one, it makes perfect sense to ask "what are
the objects I need to be dealing with, and what are their attributes and
behaviors."

Runways, airplanes, control tower, concourse, baggage carousels, parking
garage, fuel tanks, snack and gift shops.... we don't have to spend a lot of
time on any one institution, and we don't have to write even a single line
of code if that's not what we're into.

The idea is to have students look at a knowledge domain and start analyzing
it in terms of objects, as a prelude to problem solving.  Don't need a
computer.


> The thing you want to avoid is having students think "What is this crap?"
>  That's sometimes necessary in math.  You can't appreciate the utility of
> eigenvectors until you understand them.  It's totally unnecessary in
> programming.   Let real-world examples lead the way.  If you can't start
> with a simple example where multiple inheritance is needed, don't even
> introduce the topic.

Yes, let real-world examples lead the way, I fully agree.

Back to "cave paintings" -- you get something simple projected, like 20
lines of Python to implement Dog and Monkey as inheriting from Mammal, and
then you talk in a more story-like mode about how today's programming
languages come pre-equipped with these "foundation classes" or "libraries"
that mirror biological ecosystems.  They're huge and offer vast resources,
if you know how to tap them.

You have all these lineages, tree structures, where objects inherit the
capabilities of ancestor objects, sometimes more than one.

AROUND THE CAMPFIRE MATH
=========================

Why story-like mode hardly happens in math class today is students get all
fidgety if they think this will be on the test.  And if it's not going to be
on the test, then why listen?

This idea of "around the campfire" storytelling, where you're simply
explaining how things work, giving as spell-binding an account as possible,
maybe showing a movie (like 'Warriors of the Net' re tcp/ip) is just not a
feature of most math classes today.

That's part of what's broken about our K-12 pipeline.  The dry
technicalities have taken over at the cost of not teaching anything much
about the real world.

The "stories", insofar as we have any, feature in "story problems" and are
typically empty of real content by design. This was one of my topics at
us.pycon 2009, co-presented with Steve Holden (PSF chairmain).

In the vocabulary of mathematics, a "cave painting" is a homomorphism more
than an isomorphism (a fancy way of saying it's a structure-preserving
analogy that drops a lotta details, but suggests them)

>
>> http://wikieducator.org/User:Macquigg  (I recommend reading Dr.
Macquigg's
>> excellent testimonial here, with a link to his PyWhip).
>
> PyWhip is the tool that is needed by math and science teachers who want to
> use computation in their classes, but feel uncomfortable trying to teach
> programming.  It will include problems in chemistry, physics, calculus,
> whatever someone wants to contribute.  All a teacher has to do is stay one
> step ahead of the students.  Anyone capable of teaching science or math
can
> do that.

This is a grand vision, grander than I'd realized.

Crunchy is in the same genre perhaps?

A lot depends on what's in the repository.  Some projects separate framework
from content, so you could get help with the framework as open source, yet
still have content behind a course-related repository that requires student
login?

PyWhip installations could spread all over the place, but we'd only see the
public ones unless we enrolled in the right courses (same model as Python
itself -- a lot of it we just don't hear about, because it's too busy making
a profitable contribution to some secret government project or some
Hollywood movie).

>
> Unfortunately, our grand plans have been stalled for lack of a volunteer
web
> programmer who can finish the hardest part of the job - the last 10%.  We
> are considering applying for a grant, so we can hire a professional.  I
wish
> I had more time.  Google App Engine, Django, Web2py... it all looks very
> interesting.

You've considered making it an open source project?  Or is it already?

>
>> So yes, the CS professors are right.  A full blown intro to classes is
too
>> much to start off with.
>
> Actually, CS professors, as a group, are more likely to want "full blown"
> tailored to the needs of future programmers.  Us industry types are more
> likely to say "Screw this.  I can write all the programs I need in BASIC
and
> C."  That was my attitude from when I first learned about OOP (1992) until
> discovering Python (2002).  This was not for lack of trying.  I read a
book
> on C++, and concluded that a better name would have been C--.

MORE AUTOBIO
==============

Yeah.  My trajectory was as an xBase programmer, writing code for a
multi-warehouse food bank, keeping various membership-based nonprofits happy
(my specialty was nonprofits and local government).

Then Microsoft bought FoxPro to compete with Borland, which bought dBase.
MSFT migrated xBase to Windows, then converted it to an object-oriented
language, quite a bit better than Visual Basic IMO.  I ended up in the
cardiac operating room about then, coding for heart surgeons.

Some "object oriented" languages give you dot notation and ways to use
objects, but precious little syntax for rolling your own.

xBase, in the form of Visual FoxPro, had inheritance and all the rest of
it.

When I got to Python by way of Java, I was already an experienced OO guy in
a practical sense, though Java / Python helped catch me up on the theory (I
read a lot of Bruce Eckel's stuff).

> I would use built-in objects first, then user-defined.  Students should be
> very comfortable with dot notation before we even suggest that you can do
> more than just use the built in objects in Python.  To introduce dot
> notation, I would just show examples.  It's kind of like learning to have
a
> simple conversation in Spanish ("Hola, Isabel.  Como esta!!) before
studying
> the grammar, or even learning the vocabulary.

TEACHER-DEVELOPED CURRICULA
===============================

Yes, back to my demo in front of the room.

Hard to think of a much better intro to dot notation that simply using a
turtle.

In the original Logo, you didn't have a receiver i.e. FORWARD 10 was about
"the turtle" and there was only one.  In fact, the very first turtle was an
actual robot, more like Lego Mindstorms CRX brick, or whatever they're
calling it today.

Today though, our turtles are explicit, easy to have more than one.  OO
includes the concepts of birth and death i.e. an object has a life span.
Temporality is important.

In the brainstorming I'm doing, we actually attempt to avoid dictating the
best pedagogy.

Our attitude is teachers know their own students best, and plus won't want
to teach what they don't comprehend.  So the teacher trainers run through
all these techniques, including Objects First, but then they don't say "you
must do this".  It's more like "here's a practice, a style, which some are
using, up to you if you wanna."  Teachers actually appreciate getting to
make a final judgment for themselves.

Maria Droujkova and Anna Roys have helped me become more attuned to the
emerging subcultures of collaboration among teachers.  Once you get
cyberspace into the picture, it changes not only course content, but how
teachers want to develop that content.

They chafe and complain if you insist they use just these or those
resources.

Innovating new content becomes part of their responsibility, in
collaboration with peers, including internationally.  Like I'm working with
this guy in Indonesia...

>
> See the section "Elegant Python" in
> http://pywhip.appspot.com/static/help/Using_Python.htm.  A student's first
> encounter with dot notation will be the line:
>
>   workset.append(n)    # append n to the workset
>
> Other than that comment, and a prior statement:  "... see if you can
> understand how this function works.  Practice using the dir() and help()
> functions on list objects and their methods.", there is no explanation of
> this grammar.  It's just a convenient way to say something  Later, in
> http://pywhip.appspot.com/static/help/Strings.txt we talk a little more
> about the grammar, and the equivalence of two different notations:
>
>    >>> len('abcde')     # same as 'abcde'.__len__()
>
> Putting too much emphasis on a topic can actually make it harder to
> understand.  I remember struggling with lambda functions for quite a
while,
> even wasting time in a discussion of lambda calculus, then realizing it
was
> nothing but a trivial bit of syntax, and I really wasn't missing something
> important.

Yes, good point.

We want OO to be intuitive, non-intimidating.

Starting with some "unplugged" approach (per New Zealand), doing OO and dot
notation externally to any computer language, might be the way to go in some
lesson plans (per above examples, many others we could brainstorm).

Exercise:  script out your day so far, since getting up, in terms of dot
notation:

Example:

>>> alarm_clock.ring()
>>> carla.awake
True
>>> carla.needs_coffee
True
>>> coffee_maker.add("grounds")
>>> coffee_maker.add("water")
>>> coffee_maker.start()
>>> coffee_maker.done
False
>>> carla.brush_teeth()
>>> carla.get_dressed()
>>> coffee_maker.done
True
>>> carla.drink("coffee")
....

OK to be loose with the syntax, just getting ideas across.  Looks like
Python but there's no computer turned on.

>
> Gary has a good point that we may be still putting too much emphasis on
> "objects first".  It's got me thinking whether I need to rewrite that
> section in Using_Python where I show that 2 is an object.  The fundamental
> point of this section is Python's unique relationship between variables
and
> objects.  The rest is anecdotal.  Anecdotal information can distract from
> the main point.
>

My attitude in presenting an "objects first" option (note *option*) would be
to emphasize how we already know how to think in terms of objects, including
the inheritance part, and we don't want any silly computer language to get
in our way, obscuring what we already know.

Computer languages should be expressive in helping us think more like we do
already.  They're here to serve us, not the other way around.

Back to storytelling mode:  no problemo talking about these "different
paradigms" and how computer languages have evolved.  If students think
they're allowed to just listen to stories, like on Discovery Channel,
they'll relax and do so.

But the climate today (in many schools) is too high anxiety because either

(a) what the teacher is saying is going to be on the next test, or

(b) there's no point listening.

That's a killer.  Subcultures that box themselves in this way are not likely
to have much of a half life.

Without shared lore, shared stories, there's no glue and no culture.

When I start teaching Python to a new group, I start talking about PEPs,
about how the language evolves, about the subculture.  I want them to have
this notion of geeks around the world all collaborating, working together.

Like I go to that Wiki page Carl has been working on and show how we're
starting to see code that's very "not Latin-1" in appearance.

There's a cosmopolitan flavor, right from the start.

If they haven't seen one Chinese character by the end of the first week,
I've done something wrong (by my own lights -- YMMV).

> PyWhip will have the ability for a teacher customize everything - problem
> sets, help files, whatever is needed for a particular group of students.
>  When a student logs in, he will see exactly what his teacher intends him
to
> see.  The help files referenced above may be too brief for high school
> students.  My target audience is technical professionals who already know
> how to write a program, perhaps in BASIC.  I encourage others to submit
> alternatives better suited to whatever background your students may have.
>
> -- Dave
>

Noted.

I hope we don't get too hung up on Objects First versus Objects Later, as I
think the situation on the ground is always going to be somewhat diverse.

For example, it's easy for me to imagine MFTDA getting used as a 2nd year
course on our Oregon DM track (discrete math track), once we've successfully
piloted a course that has no AP objectives, isn't considered early college.
Prep for the new math course might use MFTDA in teacher trainings though,
i.e. as the math teacher, you want that on your shelf (along with Zelle's, a
few others).

We have many high caliber schools that could go the MFTDA right away, too
(it's not either/or).  Just saying:  if DM is about bridging the digital
divide, then it has to meet student needs at various levels.

That's the challenge in a nutshell.  We want to rescue something broken.

Math content in Oregon is 10-20 years behind the times and we need to
administer "future shock therapy" in ways that don't simply exacerbate the
currently untenable situation.

That's a focus around here, even as we're talking Python for a language.
We're catering to "math refugees" who are seriously considering dropping out
of high school completely.

My work with the Hillsboro Police Department, which had Linux labs for
immigrant children, was along these lines.

According to one scenario, students taking the next course in sequence and
using the Litvins' text, will already have at least of semester of Python
behind them, maybe more.

This will change the character of the presentation, but not that
drastically, as we're already used to a lot of repetition in mathematics
i.e. each successive year goes back over some of the fundamentals.

So we might do more with operator overloading then?

MFTDA is purposely light on that topic, whereas I'm into __ribs__ galore (a
veritable snake BBQ seems like).

I like to rush into operator overloading because I want students to start
generalizing about addition and multiplication, and what better way than to
have these different objects doing those things in their own special ways --
but with commonalities.

You get a more "abstract algebra" sensibility that way.  We do more with
group, ring and field, simply because Python makes everything so concrete,
so hands-on.

"Group theory for children" was a movement in the 1960s I think it was.
Perhaps it's time to resurrect that?  We shall see.

One of Maria's from last year:
http://www.mail-archive.com/edu-sig@python.org/msg05186.html

Kirby
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20100126/21e0db92/attachment-0001.html>