TITLE: Science and Engineering in CS
AUTHOR: Eugene Wallingford
DATE: February 03, 2011  3:30 PM
DESC: 
-----
BODY:
A long discussion on the  SIGCSE members listserv about
math requirements for CS degrees has drifted, as most
curricular discussions seem to do, to "What is computer
science?"  Somewhere along the way, someone said,
"Computer Science *is* a science, by name, and should
therefore be one by definition".
<A HREF="http://www.cs.berkeley.edu/~bh/">
   Brian Harvey</A>
responded:

<BLOCKQUOTE><EM>
The first thing I tell my intro CS students is "Computer
Science isn't a science, and it isn't about computers."
(It should be called "information engineering.")
</EM></BLOCKQUOTE>

I think that this assertion is wrong, at least without
a couple of "only"s thrown in,  but it is a great way to
start a conversation with students.

I've been seeing the dichotomy between CS as science and
CS as system-building again this semester in my
Intelligent course.  The textbook my students used in
their AI course last semester is, like nearly every
undergrad AI text, primarily an introduction to the
science of AI: a taxonomy of concepts, results of
research that help to define and delimit the important
ideas.  It contains essentially no pragmatic results for
building intelligent systems.  Sure, students learn about
state-space search, logic as a knowledge representation,
planning, and learning, along with algorithms for the
basic methods of the field.  But they are not prepared
for the fact that, when they try to implement search or
logical inference for a given problem, they still have a
huge amount of work to do, with little guidance from the
text.

In class today, we discussed this gap in two contexts:
the gap one sees between low-level programming and
high-level programming languages, and the difference
between general-purpose languages and domain-specific
languages.

My students seemed to understand my point of view, but I
am not sure they really grok it.  That happens best after
they gain experience writing code and feel the gap while
making real systems run.  This is one of the reasons I'm
such a believer in
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2007-10.html#e2007-10-18T08_40_16.htm">
   projects</A>,
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2005-03.html#e2005-03-14T14_47_54.htm">
   real problems</A>,
and
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2008-02.html#e2008-02-04T06_51_51.htm">
   writing code</A>.
We don't always understand ideas until we see them in a
concrete.

I don't imagine that intro CS students have any of the
experience they need to understand the subtleties academics
debate about what computer science is or what computer
scientists.  We are almost surely better off asking them to
do something that matters them, whether a small problem or
a larger project.  In these problems and projects, students
can learn from us and from their own work what CS is and
how computer scientists think.

Eventually, I hope that the students writing large-ish AI
programs in my course this semester learn just how much
more there is to writing an intelligent system than just
implementing a general-purpose algorithm from their text.
The teams that are using pre-existing packages as part of
they system might even learn that integrating software
systems is "more like performing a heart transplant than
snapping together LEGO blocks".  (Thanks to John Cook for
<A HREF="http://www.johndcook.com/blog/2011/02/03/lego-blocks-and-organ-transplants/">
   that analogy</A>.)
-----