TITLE: Comments on "A Program is an Idea" AUTHOR: Eugene Wallingford DATE: November 27, 2007 5:45 PM DESC: ----- BODY: Several folks have sent interesting comments on recent posts, especially A Program is an Idea. A couple of comments on that post, in particular, are worth following up on here. Bill Tozier wrote that learning to program -- just program -- is insufficient.
I'd argue that it's not enough to "learn" how to program, until you've learned a rigorous approach like test-driven development or behavior-driven development. Many academic and scientific colleagues seem to conflate software development with "programming", and as a result they live their lives in slapdash Dilbertesque pointy-haired boss territory.
This is a good point, and goes beyond software development. Many, many folks, and especially university students, conflate programming with computer science, which disturbs academic CS folks to no end, and for good reason. Whatever we teach scientists about programming, we must teach it in a broader context, as a new way of thinking about science. This should help ameliorate some of the issues with conflating programming and computer science. The need for this perspective is also one of the reasons that the typical CS1 course isn't suitable for teaching scientists, since its goals relative to programming and computer science are so different. I hadn't thought as much about Bill's point of conflating programming with software development. This creates yet another reason not to use CS1 as the primary vehicle for teaching scientists to ("program" | "develop software"), because even more so in this regard are the goals of CS1 for computer science majors very different from the goals of a course for scientists. Indeed, there is already a strong tension between the goals of academic computer science and the goals of professional software development that makes the introductory CS curriculum hard to design and implement. We don't want to drag that mess into the design of a programming course for scientists, or economists, or other non-majors. We need to think about how best to help the folks who will not be computer scientists learn to use computation as a tool for thinking about, and doing work in, their own discipline. And keep in mind that most of these folks will also not be professional software developers. I suspect that folks who are not professional software developers -- folks using programs to build models in their own discipline -- probably need to learn a different set of skills to get started using programming as a tool than professional software developers do. Should they ever want to graduate beyond a few dozen lines of code, they will need more and should then study more about developing larger and longer-lived programs. All that said, I think that that scientists as a group might well be more amenable than many others to learning test-driven development. It is quite scientific in spirit! Like the scientific method, it creates a framework for thinking and doing that can be molded to the circumstances at hand. The other comment that I must respond to came from Mike McMillan. He recalled having run across a video of Gerald Sussman giving a talk on the occasion of Daniel Friedman's 60th birthday, and hearing Sussman comment on expressing scientific ideas in in Scheme. This brought to his mind Minsky's classic paper "Why Programming Is a Good Medium for Expressing Poorly-Understood and Sloppily-Formulated Ideas", which is now available on-line in a slightly revised form. This paper is the source of the oft-quoted passage that appears in the preface of Structure and Interpretation of Computer Programs:
A computer is like a violin. You can imagine a novice trying first a phonograph and then a violin. The latter, he says, sounds terrible. That is the argument we have heard from our humanists and most of our computer scientists. Computer programs are good, they say, for particular purposes, but they aren't flexible. Neither is a violin, or a typewriter, until you learn how to use it.
(Perhaps Minsky's paper is where Alan Kay picked up his violin metaphor and some of his ideas on computation-as-medium.) Minsky's paper is a great one, worthy of its own essay sometime. I should certainly have mentioned it in my essay on scientists learning to program. Thanks to Mike for the reminder! I am glad to have had reason to track down links to the video and the PDF version of the paper, which until now I've only had in hardcopy. -----