Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site opus.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!hao!cires!nbires!opus!rcd
From: rcd@opus.UUCP (Dick Dunn)
Newsgroups: net.lang
Subject: Re: Teaching programming - aaack
Message-ID: <568@opus.UUCP>
Date: Tue, 26-Jun-84 01:24:59 EDT
Article-I.D.: opus.568
Posted: Tue Jun 26 01:24:59 1984
Date-Received: Sat, 30-Jun-84 01:02:50 EDT
References: <678@abnjh.UUCP> <554@opus.UUCP> <195@imsvax.UUCP>
Organization: NBI, Boulder
Lines: 48

>>>Beginning CS students should not only be taught simply how to program,
>>>but how to reason a programming solution and to convert it into concrete
>>>terms...freshman CS students should undergo a course
>>>discipline that teaches them how to think like computer scientists.
>
>>Aaack.  No, PLEASE!  If you do that we're never going to get enough
>>programmers to go around.  Teach them to think like programmers, not like
>>computer scientists!
>
>Maybe, but would you trust anything more complicated than a bubble
>sort (yuck, use insertion sort) to a programmer who didn't think like
>a computer scientist?

Perhaps I'd better explain the particular pejorative sense in which I (>>)
was using "computer scientist".  There's a particular type of computer
scientist (not all, by any means) who enjoys the challenge of a problem
more than getting the job done; who's more interested in producing research
papers than in producing software; who's only interested in a real problem
until it is sullied by the imperfections and inelegance of a real solution.

I agree that students need to know how to reason the solution (first) and
convert it to concrete terms (after reasoning it out).  To me, this is part
of programming (as opposed to coding).

I don't mean to split semantic hairs, nor to dish out insults to
programmers or computer scientists (I've been accused of being both).  I
was just being fitfully grumpy about all the poorly written theoretical
nitpicking, elegant solutions to nonexistent problems, useless formal
"software management techniques", and general irrelevant abstraction that
I've seen passed off as computer science - some of it in highly respected
refereed journals - in the past few years.

There's one particular conversation that I overheard a few years back that
sticks in my mind.  A fairly theoretically-oriented computer scientist was
bemoaning the generally low level of technical knowledge of many
programmers, and commented that most "wouldn't recognize an Np-complete
problem if they saw it".  The other fellow, much more practically oriented,
shot back that many programmers would just go ahead and solve the problem
anyway, Np-completeness be damned.  His point, of course, is that if
there's a problem to be solved, the theory may help tell you that the
general case is intractable.  (So may intuition!)  But that doesn't make
the problem go away, and a real programmer (sorry:-) will have the
pragmatism to look for a usable solution to a useful subset of the problem,
or a way to recast it to tractable form, or a way to get more/different
information.  He won't get hung up in the theoretical grandeur/horror.
-- 
Dick Dunn	{hao,ucbvax,allegra}!nbires!rcd		(303)444-5710 x3086
	...Relax...don't worry...have a homebrew.