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.