Xref: utzoo comp.edu:2746 comp.software-eng:2600
Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!rutgers!mephisto!mcnc!duke!romeo!crm
From: crm@romeo.cs.duke.edu (Charlie Martin)
Newsgroups: comp.edu,comp.software-eng
Subject: Re: CS education
Message-ID: <16322@duke.cs.duke.edu>
Date: 4 Dec 89 17:21:51 GMT
References: <16315@duke.cs.duke.edu> <7296@hubcap.clemson.edu>
Sender: news@duke.cs.duke.edu
Reply-To: crm@romeo.UUCP (Charlie Martin)
Organization: Duke University CS Dept.; Durham, NC
Lines: 64

In article <7296@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
>   Again, not exactly.  I prefer to apply information hiding, thus
>   excluding the details of implementation to the greatest possible 
>   extent.   Courses like "Operating Systems Implementation" fail to
>   do this.
>

And, now, given that the course you were objecting to is called
"operating systems implementation" I *might* agree with you; depends on
the content of the course.  A course on operating systems
implementations which turns out to be the internals of, say, VMS,
doesn't seem like a proper "core" course.  

On the other hand, the course title doesn't tell all that much.  (I once
took a course on programming methodology which turned out to be taught
more or less as a course on time-efficient implementation of algorithms
for OR problems.)

(I do love it when these discussions on the net begin to converge.  It
always makes me feel like I've learned something....)

>
>   Both; the former [teach to think] can be done within the context of 
>   the latter. [train to be effective code jock 'on delivery']
> 
>> I do think you're wildly wrong.  In any case, the program you describe
>> is like the Associate's Degree course I took years and years ago; taught
>> me to be a pretty good COBOL programmer, taught me to write OS/360 JCL.
>> Other than a couple of years of $14--$20 K jobs (this was some time ago,
>> not bad money then) it was damned little use.
>
>   No, it isn't.  Software engineering is a long way from COBOL & JCL,
>   which today remain of little use.   (Flames to /dev/null...)
> 

"The program you describe is *like* the...."  meaning similar in effect
or intent.  They didn't teach software engineering per se in this course
I was talking about becuase the course was about the same time as the
NATO Summer School; it wasn't a term yet, really, much less a field of
study.

My point is that a sequence which leads to IS programming in Ada under
UNIX is likely to be just as useless in 20 years as the one I took that
taught RPG II and COBOL under 360 DOS and OS.  At least I hope so.  A
sequence that teaches file system organization, concurrency and multiple
access, architectures and the tradeoffs among architectural choices, and
some kind of formal understanding of program and programming language
semantics is much more likely to be giving you tools that you'll use in
20 years.

Whether this stuff ought to be taught as it often is, in courses on
operating systems, data bases, etc, is another question.  You've about
got me convinced that it should not be.  (pace Tony Wassermann, but
maybe organizing "software engineering" sorts of computer science
kowledge around those courses is not as good an idea as it first
seems....)

One point that you seem to have in mind, that a student can be an
effective team member immediately upon graduation, seems idealistic at
best.  No other engineering discipline does so; back at GTE I was told
that it took about one year to become effective as an engineer, no
matter where you were from or what your background was.  There is that
much domain knowledge and "corporate culture" to be learned.
Charlie Martin (crm@cs.duke.edu,mcnc!duke!crm) 


Brought to you by Super Global Mega Corp .com