Xref: utzoo comp.edu:2726 comp.software-eng:2572
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!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: <16283@duke.cs.duke.edu>
Date: 1 Dec 89 14:19:52 GMT
References: <16171@duke.cs.duke.edu> <7184@hubcap.clemson.edu>
Sender: news@duke.cs.duke.edu
Reply-To: crm@romeo.UUCP (Charlie Martin)
Organization: Duke University CS Dept.; Durham, NC
Lines: 126

In article <7184@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
>> I don't believe, and I've stated my reasons at length.  Okay, let's hve
>> some facts.  What are the parts of OS that are irrelevant unless you are
>> going to build OS-es?  
>
>   Everything about the internals of an OS which is hidden from its users.
>
>   The user interfaces to an OS may well require a bit of explanation as
>   to the definition of certain patterns of interface behavior; for example,
>   it may be necessary to give a scheduling model in order to explain to
>   the user the pattern of behavior which the operating system will present
>   at the user-scheduler interface, and it may be useful to convey to the
>   user the fact that all operating systems having the attribute "Uses The
>   Umptysquat Scheduling Algorithm" will present a similar pattern of 
>   behavior.  Enough to understand how to use the tool, and no more. 
>

Hmmm....  I think I am beginning to see something here.  Was the course
you took largely directed toward the internals of the blah operating
system?  (I can easily imagine one being done this way... in fact, now
that I think of it, the old old course I took ca. 1974 was built that
way.)  If so, or if it were heavily weighted that direction, then I
begin to understand your point.  I think.

I counld go into it at great length, but I think the point is that I
also agree that a course that heavily emphsizes internals of a
particular operating system is not a good choice, and might not be
useful.  In my opinion, all such courses (OS, lnguages, etc) ought to be
taught in an OS-independent manner.

I think I'll hold further comments until I know more about he sort of
course you've been arguing on the basis of.

>> How do you know that you won't be building OS-es?
>
>   I know that information systems is an extremely large employment
>   market (many, many times larger than the market for OS builders), 
>   and that my professional background is strong enough to permit me 
>   to decline any requests to do such a thing in the extremely unlikely 
>   event that such a request ever comes up.
> 

>   I also know that OS building is a complex and highly specialized field 
>   which requires long and specialized study, and that any employer who
>   tries to get a person who does not have the appropriate extensive
>   professional training and career committment to the field to do OS
>   design is destined for a rather spectacular failure.  I have absolutely
>   no plans to obtain such qualifications, and I am confident that natural 
>   economic selection will see to it that any such employers are rapidly 
>   driven into economic extinction and that I will never encounter such 
>   a brain-dead employer.
> 

I dunno, Bill.  Maybe the market is that way now, but if so, it doesn't
look like it from where I am sitting now.

You're absolutely right that the market for IS stuff is much broader
than OS, right now and likely in the future.  (One of my major
complaints about the program here at Duke is that students learn about
tree algorithms but not about master-file update programs.  These are of
course meant to be exemplar of classes of problems and solutions.)

I don't doubt that you can go to a bank or some such and do IS for the
next umpteen years, and if you like those programs then great.  But my
own experience has been this:

- I started doing purest MIS in 1969.
- I also got into formal methods in 1969 (with Dijkstra's book)

- I moved to another MIS shop in 1978
- they asked me to do graphics in FORTRAN
- I liked doing graphics in FORTRAN

- I moved to a defense contractor in 1979
- I built not one but two small operating systems
- I worked on an assembler
- I did hard real-time
- I did field maintenance and training, as well as hard real-time
- I did a reporting program for returning collected data
- I did human interfaces, and then human interface research.

- I came to grad school
- I did software engineering, formal stuff, programming languages
- I did lots of math, lots of EE, (for a computer person) lots of
  physiology
- I am picking up lots of formal systems work and trusted systems work

My point here is that every time I changed "fields" I did so because
there was an intersting problem to approach, I thought it would be fun,
and I had sufficient general background to work on it.

If I had been schooled as you suggest, many of these choices would have
been limited; the OS classes I took encoded much of the background I had
for reeal-time stuff, for the OSes, and also much of the file-system
understanding I needed for MIS programs.  

Even if you "know" you're going to go do IS immediately, and "know" you
won't stray, how do you "know" that conditions won't change?

>   that isn't what REALLY ticks me off.  What really kills me is that there
>   is so much wonderful software engineering material out there that I was
>   prevented from studying because I was R-E-Q-U-I-R-E-D to study so many
>   things which were irrelevant.  
I think our diffference here is what is or isn't relevant; there is the
other problem of how to fit it into 4 years, which may not be soluable.

>
>   But clearly economics do not permit us to study everything; we must
>   consider the marginal costs and marginal benefits of that which we
>   choose to study.  

Sure, sure.  My point was exactly that: that SE isn't EVERYTHING (it's
the ONLY thing.. ahem) but that there must be a collection of things
that characterize software engineering as a field or topic if it is
indeed a field or topic.

>
>   Oh, please, I'm exhausted!!  Can we discuss this in a week or three?
>
>   I think it is, but this is another long thread which I'd like to
>   put off until I recuperate from this one.  Probably around the time
>   I get through with all those turkey sandwiches!!!   :-)   :-)   :-)

Agreed.  I should be finishing this dissertation, anyway.

Charlie Martin (crm@cs.duke.edu,mcnc!duke!crm) 


Brought to you by Super Global Mega Corp .com