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

[Kirby Urner]

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

This is a valid and memorable distinction:  learning to program vs.
programming to learn.  CS is tilted more toward the former, but shouldn't
shy away from investing in the latter.  

If you're actually going to go out there as a contract programmer or some
such, you'll be spending a lot of time trying to master new knowledge
domains, even though you're already pretty good as a programmer.

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

Indeed, the fun I've had as a programmer over the years stems from popping
up inside myriad disparate organizations and getting to wrap my brain around
these various systems:  registration for summer camp, membership/donors,
clinical data from heart operations and so on and on.  

That last challenge got me into operating rooms, complete with mask, smock,
hair and shoe covers (and even a patient on the table a couple of times,
though my code had nothing directly to do with real time life-support praise
Allah).

> 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 mostly agree.  However I think early exposure to "war stories" is good,
i.e. disasters or complications that arose from *not* managing collaboration
issues well.  Students absorb some of the culture and ethics, some of the
history.  In broad brush strokes, why was the "goto" a bad idea?  What
problems did "structured programming" solve?  Why is object oriented
programming considered a positive development (except by a few dissidents)?
Per my "math through storytelling" thread, I'm a big fan of teaching through
narratives relaying real world experience.

My friend Ron tells about the time some coders brought him several pages of
MUMPS code, mostly punctuation marks (each one a command), with white space
significant.  It was all one line of code, wrapped.  Something like that.
The coders wanted him to help find a bug.  It was at that moment Ron
realized he needed another job.  Some languages don't scale well.

What's exciting to me about computers is it's an area where humans,
notorious for not getting along, especially politically and religiously,
have co-created some awesomely complicated yet working technology.  It's a
metaphor for civilization itself.  And it didn't get this sophisticated
without people skills (geeks aren't without people skills, they're just very
good at communicating technology to other geeks).

Kirby