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

[kirby urner]

From: kirby urner <kirby.urner at gmail.com>
Date: Tue, Jan 26, 2010 at 3:20 PM
Subject: Re: [Edu-sig] Math + Python: reviewing some themes (long)
To: edu-sig at python.org


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