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