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 HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2007-11.html#e2007-11-24T05_43_00.htm">
   A Program is an Idea</A>.
A couple of comments on that post, in particular, are
worth following up on here.

<A HREF="http://williamtozier.com/slurry/">
   Bill Tozier</A>
wrote that learning to program -- just program -- is insufficient.

<BLOCKQUOTE><EM>
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.
</EM></BLOCKQUOTE>

This is a good point, and goes beyond software development.
Many, many folks, and especially university students, conflate
programming with <EM>computer science</EM>, 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 <EM>not</EM>
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
<A HREF="http://video.google.com/videoplay?docid=-2726904509434151616">
   talk</A>
on the occasion of
<A HREF="http://www.cs.indiana.edu/dfried_celebration.html">
   Daniel Friedman's 60th birthday</A>,
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
<A HREF="http://rafael_es_son.typepad.com/metainformaciones/files/minsky_essay_1967.pdf">
   available on-line</A>
in a slightly revised form.

This paper is the source of the oft-quoted passage that appears
in the
<A HREF="http://mitpress.mit.edu/sicp/front/node3.html">
   preface</A>
of <EM>Structure and Interpretation of Computer Programs</EM>:

<BLOCKQUOTE><EM>
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.
</EM></BLOCKQUOTE>

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