lepine@istg.dec.com.UUCP (09/23/86)
In recent discussions in this newsgroup about computer science and computer
programming and the appropriate curriculum for the two a pet peeve of mine has
surfaced. The argument between Tom and Frank illustrates the lack of
understanding of the difference between computer science and computer
programming and of the many different kinds of programming that exist. I
believe that Tom understands the difference very well but that Frank is guilty
of a very common failure to make these differentiations.
There appears to be a tacit belief among universities that students clearly
understand these distinctions and are able to choose the correct programs. My
experience has been that a great many students who enroll in computer science
programs are really looking for a good programming curriculum. Their
interests are in application programming of whatever type, not in research,
advanced development, etc. For this type of student the computer science
curriculum is patently wrong.
I disagree with Tom that "Bob's Programming School" is the correct choice for
all of these students. If their interest is in commercial programming (e.g
order entry/processing, inventory, payroll and the like) this may well be an
appropriate choice. Even the commercial programming schools need to
strengthen their curricula to provide a better understanding of some topics
(e.g. "correct" programming of floating point math, etc.) and not be content
to just get students coding COBOL and BAL. However there are a large number
of other application areas where the computer science curriculum is overkill
for some topics and lacking in other topics. Examples such as systems for
geophysical processing, defense systems (e.g C3I, radar, etc.), communications
and networking all require many of the CS subjects but also require strong
grounding in the principles of the application field. I reject the argument
that "good programmers" can learn what they need to know about the application
area to become proficient in whatever application they are currently involved
in. They can perhaps become "competent" but not proficient. For these poor
students the choice is CS with a sprinkling of their chosen application field,
a program in their chosen application field with a sprinkling of CS, or a
double major in their chosen application field and CS (ouch!).
I would like to suggest that universities leave the commercial programming
field to the business programming schools (and that employers exert pressure
on these schools to beef up their curricula). Further, CS departments must
begin to work with other departments to provide a good choice for students who
do not wish to be computer scientists but wish to become good programmers in a
specific application field. CS departments should provide a track for serious
computer science students that is heavily flavored with the theoretical. This
BSCS curriculum would be directed toward developing researchers, etc. Another
track in the CS department would be offered to provide good understanding of
programming (e.g. data structures, software engineering, etc.) but would not
be a major as such. Rather it would provide the second half of the BS degree
in the <pick one> department's major in "Computer Applications in <pick one>".
These students would have a strong programming background with understanding
of the underlying theory without having to study all of CS as well as a strong
background in the application field in which they are interested. A final
option would be a track in the CS department similar to the application
programming track but granting a BS in "Computer Applications" (BSCA) without a
seperate departmental major. These students might take a number of courses in
other departments to provide a broad background in the basic sciences and
engineering when a specific application field has not been defined by the
student. In all cases, a prerequisite for any CS course would be a seminar in
the difference between computer science and computer programming with an intro
to the various application fields and their requirements.
Feedback?
Norm Lepine
Disclaimer: These views are those of the author and in no way represent
Digital Equipment Corporation.eugene@ames.UUCP (Eugene Miya) (09/24/86)
Be careful when you separate computer science and programming.
As I have said, too many times before:
It's going to be important for new computer science ideas to reach
programmers out "in the trenches." There are too many older programmers
who are just COBOL and FORTRAN pushers who know nothing of modern
data structures, nothing about algorithms, networks?, UNIX?
workstations? Interactive programming (? "Wasteful of cycles....")
It's an incomplete argument to say that these "old timers" have to die off.
You have to be careful that the people in `Bob's Programming School'
get some exposure to these ideas because our technology changes so
quickly. It's like a physics class I had in the public school system
taught by a guy who knew nothing of modern physics.
Don't make computer science an elite ivory tower, you will create
ideas which don't propagate until guys like marketeers (Osbornes
rather than Kays) come along.
From the Rock of Ages Home for Retired Hackers:
--eugene miya
NASA Ames Research Center
com'on do you trust Reply commands with all these different mailers?
{hplabs,ihnp4,dual,hao,decwrl,tektronix,allegra}!ames!aurora!eugene
eugene@ames-aurora.ARPA
Software isn't soft, if it outlasts the hardware.beth@umcp-cs.UUCP (Beth Katz) (09/25/86)
Eugene Miya writes (in addition to other useful things): >Be careful when you separate computer science and programming. >As I have said, too many times before: >It's going to be important for new computer science ideas to reach >programmers out "in the trenches." .... And on the other side, even in 'computer science', you should at least know how to program so that you can test out the theories before you send them into the trenches. What is called 'technology transfer' includes testing out the theories, showing that they are applicable and useful, teaching and incorporating them into production environments, and evaluating and possibly modifying them within those environments. But you need to understand the problem 'out there'. Pure computer science theory doesn't necessarily address that. And a lot of software engineering research doesn't address the 'real world' either. I'm not saying that it must, but the researchers should at least be aware of the real problems. Knowing how to program and design non-trivial systems would help. Beth Katz Univ. of Maryland CS Dept. "The more I learn, the more there is to know."