[comp.ai.digest] Is Computer Science Science? Or is it Art?

cdfk@hplb.CSNET.UUCP (09/18/87)

Randy Martens says:-
"There is, however, Computer Engineering. (and Software Engineering,
and Systems Engineering etc.).  Science is the discovery of the new.
Engineering takes what the scientists have found, and finds ways
to do useful things with it."

If this is so, my first question is

Who are the relevant scientists and what have they discovered?

                            -*-

As an AI researcher I'm always discovering new things - although
possibly not interesting in the same way as Newton's laws of motion or
Einstein's theory of general relativity - they are still potentially
new knowledge. (Most people must be content to play with grains of
sand not pebbles!)

However I would defend an engineer's creativity and ability to
experiment - they too discover new things but with a different aim in
mind and a different form of reporting than the scientist.

However I believe that in software there is a better analogy with art
and illustration than engineering or science. I have noticed that this
is not welcomed by many people in computing but this might be because
they know so little of the thought processes and planning that go on
behind the development of, say, a still life or an advertising poster.

Like software art is frequently pliable and reworkable; like software
there are many different methods and philosophies (many not employed
explicitly by experts although there are procedures for producing
certain types of work), rules of thumb and conventions; there are
great practioners and many more humble industrious ones; there are
different schools of thought and also ferverent arguments about such
low level things as Acrylics or Oils, sable brushes or manmade fibre
(here ethical issues also creep in), the "rightness" of working from a
photograph, etc. In illustration and advertising the artist might be
given a very wide but constrained brief or a very tightly specified
mock-up to work from. A work of art or an ad are often the results of
a carefully executed plan (although the results are not always quite
was expected).

I have also watched both good artists and good software makers at work
and several similarities struck me: the light sketch with more work
put into some of the trickier areas, experimentation with different
compositions, throwing out or completely removing bits, putting
finisihing touches which change the whole although are little enough
in themselves.

What is useful that can come of this analogy? Here are some
suggetions:-

Training: An artist will frequently learn their own style through
meticulous study of previous greats (whose great software is there for
us to emmulate?).

At first working from nature is important although more freedom and
greater abstraction will come later. An artist must learn to see and
understand - this is something which many software workers could do
with applying.

Aids: An artist has sketch pads for roughs or capture of structure or
examples of detail. The organisation of these is often less than
perfect - in software we have a better chance of providing this
although currently our best attempts such as Lisp machines and
environments like POPLOG are still very much less than perfect too.

Aids for producing mockups - for instance cartoonists use sheets of
shading which can be cut to fit the required area - in software we
need some such things to allow us to prototype with hints at detail
without putting it all in.

Aids for throwing stuff away! How many novices or less than expert
programmers cling to the stuff they've written when it needs throwing
out and redesigning from scratch! This is like the advice given in
school not to use an eraser - of course eventually the artist knows
when it is worth using one but at first it is better to concentrate on
developing the ability to create smoothly and without fiddling.

Well I guess I've gone on long enough - I'd be pleased to reply to
anyone interested in this point of view - thanks for reading this
far!

Caroline Knight         cdfk@lb.hp.co.uk
                        cdfk@hplb.csnet

Tel: (0272) 799910 x4040      Telex: (0270) 449206
Fax: (0272) 790076

HPLabs, Hewlett Packard Ltd, Filton Rd, Stoke Gifford, BRISTOL
BS16 1NY

Everything I write is from me personally and does not represent
Hewlett Packard in any way.
----------------------------------------------------------------

shf@SOLAR.STANFORD.EDU (Stuart Ferguson) (09/24/87)

+-- cdfk@hplb.CSNET (Caroline Knight) writes:
| ... I believe that in software there is a better analogy with art
| and illustration than engineering or science. I have noticed that this
| is not welcomed by many people in computing but this might be because
| they know so little of the thought processes and planning that go on
| behind the development of, say, a still life or an advertising poster.

This line of thinking appeals to me alot (and I'm a "person in computing,"
having 10+ years programming experience).  I can apreciate this article
because my own thinking has led me to somewhat the same place regarding
"Computer Science."

My own favorite art form that parallels programming is literature (and all
forms of writing or word-smithy).  Like programming, writing has a
tremendous number of practical uses in our society, and only a handful of
writers call themselves "artists."  Yet the person who writes as an artist
has a power of expression that a "hack" writer lacks.  

| What is useful that can come of this analogy? Here are some
| suggetions:-
| Training: An artist will frequently learn their own style through
| meticulous study of previous greats (whose great software is there for
| us to emmulate?).

Computer Science educators could certainly learn to "cultivate the artistic
temperment."  There are techniques and information to learn and study in
both art and programming, but no art teacher would ever think that learning
the techniques will make the student a great artist.  The same is true for
programmers.

| At first working from nature is important although more freedom and
| greater abstraction will come later. ...

Excellent analogy.  The first programs I wrote were simulations of physical
systems (lunar lander games, spacewar games, billiard ball atom simulations
and 3D graphics rendering of simulated worlds) or real-world problems (like
tic-tac-toe or the traveling salesman problem).  Only after mastering these
did I move on to writing parsers, text editors and compilers -- the more
abstract end of the scale.

| Aids for producing mockups - for instance cartoonists use sheets of
| shading which can be cut to fit the required area - in software we
| need some such things to allow us to prototype with hints at detail
| without putting it all in.

Yes, and here is where programming diverges from the analogy of illustration.
Projects in illustration are typically small scale (although I'm not involved
in the art so I can't really say!) whereas programming projects can be
enormous requiring man-years of work and huge volumes of code and are often
created by teams rather than individual artists.  I think the analogy of
an epic novel or some other writing effort is more appropriate.

| Aids for throwing stuff away! How many novices or less than expert
| programmers cling to the stuff they've written when it needs throwing
| out and redesigning from scratch! This is like the advice given in
| school not to use an eraser - of course eventually the artist knows
| when it is worth using one but at first it is better to concentrate on
| developing the ability to create smoothly and without fiddling.

Amen!  Here again I think the writing analogy works well.  Can you imagine
what a novel would sound like if the author never did any re-writing?  Or
if the author had a few scenes that he had written and tried to work
them into one large story without re-writing any of the smaller scenes?

Rapid prototyping in programming is akin to a first draft in writing.  It
allows the programmer to get ideas out on paper (so to speak) where he can
evaluate them objectivly and see what needs changing or re-thinking.  
My writing improved immeasurably when I discovered that I could actaully
throw something that I had writen away and re-write it, and the lesson
was not lost on my programming.  Often people don't have the courage to
throw something away that works, and it requires a certain ammount of
mastery of one's art to do the same thing and do it better.

| Caroline Knight         cdfk@lb.hp.co.uk
|                         cdfk@hplb.csnet