[Edu-sig] Hello from a CS Teacher

Steve Morris smorris@nexen.com
Fri, 11 Feb 2000 18:24:36 -0500 (EST)


Kirby Urner writes:
 > My approach has been to look at Python as one more useful
 > tool when it comes to teaching mathematics.  Computers, not 
 > just calculators, deserve a place in our average math class.  
 > Students need better graphing capability and more exposure 
 > to symbolic operations than today's calculators provide.
 > 
 > It's a mark of serious over-specialization that we draw 
 > such an artificial line between "numeracy" and "computer 
 > literacy".  
 > 
 > Just because I want to program a computer, doesn't mean I 
 > want to be a computer programmer (speaking generally --
 > in actual fact I pay some of my bills by writing Xbase). 
 > For me, CP4E means using Python in a non-CS context.

I strongly agree. CS curricula work is important and probably will
give the most benefit in the shortest time but the long term goal
articulated by Guido in his CP4E proposal was to enable the routine
use of programming as a tool for people who would otherwise be non
programmers. The "Everyone" in CP4E doesn't mean that everyone should
go into programming as a career. Instead Guido was suggesting that
programming should be a basic tool like language and math available to
most people.

Here is my cut on a possibly worthwhile project:

Math and science curricula are obvious starting points and several
people here have talked about existing efforts.

Simulation models are probably the most fruitful area to consider for
basic physics and give a good example of the kind of thing I am
suggesting.  By this I mean the students define initial conditions of
objects and watch what happens to them. They then change initial
conditions and try again, observing the differences. I have seen
static programs which simulate a predetermined set of behaviors over a
small set of parameters selected with sliders and the like. Adding a
programming language to expand the range of experimentation would
increase the learning opportunities by allowing more arbitrary
specification of time varying parameters or parameters that change
based on various conditions. In an ideal world the student would be
able to set up conditions and conduct experiments that the teacher
never though of.

In case I am be too abstract let me describe an explicit example:
Consider a programming simulation world that follows simple newtonion
laws of motion. Include gravity as an option for interest. Throw in
elastic and inelastic collisions for good measure. This world would
allow simulation of air table experiments, simple parabolic motion and
orbital dynamics. Throw in the Bernoulli principal and kids could
simulate the behavior of various pitching techniques (sliders etc.)
and perhaps even simulate an airplane wing.

The initial package would be a general computer simulation environment
with basic behaviors built in and various output techniques (3D
displays, tables of coordinates for further processing etc.)  On top
of the basic simulation model (which is written once) would be various
predefined worlds aimed at specific lesson plans. These world would be
defined by python programs and packages. Once the simulator is written
(that's the hard part) the process of generating a specific set of
interesting objects (in python) would be relatively simple. Basic sets
would be packaged with the system. Others would develop and share
interesting packages and advanced students would create their own. The
point is to do the hard part (simulation and 3D representation) once
and let the users (students AND educators) experiment and play.

Now I could just as well have specified a similar system for
investigating wave dynamics or simple machines or optics. This
suggests to my thrifty programming soul that there might be another
more basic layer, i.e. a generalized simulation engine packaged with a
3D viewer.

The first 4 layers of implementation would look something like:

python + simulation engine + mechanics + orbital dynamics
       + 3D representation |           |
                           |           + air table
                           |           |
                           |           + parabolic motion of projectiles
                           |
                           + optics + refraction
                           |        |
                           |        + reflection
                           |
                           + other simulation worlds

The 5th layer is the code written by the student.

In my diagram each layer is built on top of and uses the facilities of
the one to the left.  Python would be the implementation language of
choice at each layer (including the student layer) unless performance
issues drive a different choice.

The point is to factor the problem space of things wanting to be
taught using software to reduce duplication of effort. It is easier to
recruit help to create a simulation engine if many people stand to
gain for many end uses. It is then easier to solve a particular
curriculum problem if most of the basic compunents already exist.

It is the sharability that I am trying to suggest.  Maybe it should be
broken down differently.  Lots of people have solved parts of this
problem for specific classroom applications. I think it is time to
generate common tools that are easier to port/steal for other
problems.

I know I am talking about a moderately big project (although not as
big as you might think, and much of it might already be available)
with a longer payback cycle and will likely get snide comments about
vaporware, however I think it is worth some thought. It will certainly
never happen if it doesn't get discussed. If it gets beyond discussion
into some specific proposals I am willing to help.