[Edu-sig] K-16 CS/math hybrid

[John Zelle]

Kirby Urner wrote:
<snip>
> Plus we're not always interested in "programming curricula" (for the sake of
> programming).  If the goal is to get physics majors to ramp up in some
> VPython context, to where they can explore mechanics/kinetics interactively,
> within a day or two, who cares if they're not using classes/objects to their
> maximum advantage, and don't write the tightest imperative code.  That's not
> the point.  The point is to learn physics.  Python is good for that too.  
> 
> It's unfair to criticize quick and dirty code that pretends to be nothing
> more.  There's room in this world for one-off scripts that get the job done.
> We all write "code to throw away" or should.  Making everything you write
> read like some CS text book example is a waste of precious time.
> 

This is an issue I've been thinking quite a bit about recently. In my 
own mind, I make a distinction between "programming to learn" vs. 
"learning to program." A lot of the discussion of programming on this 
forum involves using programs to investigate other topics (physics, 
statistics, geometry, etc.) This is pure "programming to learn." The 
point here is not necessarily to write industrial strength code, but to 
learn more effectively and deeply through the programming process.

Certainly, a good deal of the CS curriculum is aimed at the latter goal 
of "learning to program." That is teaching students how to create 
well-designed, properly documented, elegant, efficient, extendable, and 
maintainable software. However, I think that too much emphasis on this 
can be a bad thing, even in CS programs. In the introductory classes, we 
should try to foster a spirit of inquiry and encourage our students to 
experiment and learn through doing. That hacker's spirit can be drowned 
out if it's all about the "mechanics" of "proper" programming.

Programming is a critical foundation of CS, but CS is much more than 
(just?) learning to program. The "much more" is amenable to, and IMHO 
should be investigated through "programming to learn."

> What I'm wondering is how many CS curricula emphasize team approaches, e.g.
> teach extreme programming techniques, other ways to manage largish, scalable
> projects.  This should come earlier rather than later, so some appreciation
> for the conventions of teamwork start tickling in (e.g. why should I waste
> time documenting, writing a lot of test? -- because *you* aren't the only
> reader of this code, duh).

I think virtually all curricula are now doing this at some point. Again, 
I'm not sure it's something one wants to dwell on too much in the very 
first classes. You really can't appreciate many of the techniques for 
dealing with larger projects, things like design by contract and design 
patterns until you are working on projects where those techniques 
actually have payoff. Otherwise, it's just extra burden up front and it 
stifles student productivity and excitement. One exception I would 
definitely make to this observation is test-driven development. I think 
this is a technique that can be addressed early-on and actually helps 
students contruct even fairly simple programs.

> I think Python has the potential to give us *better* CS curricula than we've
> had before, and these better curricula will do more to counter solipsistic
> programming habits.

Obviously, I agree that Python has a lot to offer. I see two main 
contributions. By making it easier to write programs, we can get a lot 
more programming to learn both in the CS curriculum and elsewhere. The 
more students program, the better they become at it. The second real 
advantage is that Python allows students to create much more 
sophisticated programs in a given amount of time. That provides CS 
educators with a much better platform for introducing the techniques 
needed for programming in the large.

--John

-- 
John M. Zelle, Ph.D.             Wartburg College
Professor of Computer Science    Waverly, IA
john.zelle at wartburg.edu          (319) 352-8360