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. To try going in with some "digital math" is just stacking the deck against one's own efforts, increasing the odds against success. Still, we need to call it something. Computer Math? Computational Math? Discrete Math?
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).

3.d OBJECTS FIRST?
====================
Sorry this is being so long. Let me just end with another take on the "objects first" approach. In order to make Python more accessible and the mathematics correspondingly easier, we begin with very simple classes based around animals (e.g. the Turtle class). We encourage thinking about animals, their attributes and behaviors. Only later on will we try our had at more generic "math objects" such as Rational Numbers. MFTDA actually includes a Rational number class, but doesn't give it much focus. It seems to be the only class definition in the entire text. I think this maybe mirrors an attitude among CS professors that classes and objects are an advanced 2nd year topic. My own view is somewhere in between: I think a full blown treatment of OO, including abstract classes, metaclasses, multiple inheritance, is indeed advanced and probably not suitable for a one year or half year high school math course. Or, if suitable, then mostly in the form a really primitive examples of the Foo and Bar class variety, more to communicate the generic design patterns and concepts than to develop full blown computer programs such as one might use in production environments. 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. 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.

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.

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.

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.

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--.

The idea, then, is to build some awareness of classes and objects using familiar analogies relating to every day life. A class definition is a blueprint (one needs to explain "blueprint" -- design, plan) whereas an instance of the class has it's own place in memory, its own "self" as it were (intro to Python "self" syntax). Do some animal classes. Then note how dot notation is what's used to access the attributes and behaviors of a user-defined object. Then note how Python's primitive objects are likewise instances of various classes (e.g. the List class). It's dot notation itself that we're hoping to make second nature (familiar, not too arcane). 3.e THE TIME DIMENSION
====================
That's the breakthrough in understanding we're seeking: brief anatomy lessons with user-defined classes provide enough background to anchor an understanding of built-in classes and objects. It's really "dot notation" itself that we're seeking to anchor here. noun.verb(args) and noun.adjective provide a primitive grammar or logic.

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.

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.

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.

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
_______________________________________________
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig

Reply via email to