Xref: utzoo misc.jobs.contract:360 comp.edu:3401
Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!rpi!bu.edu!xylogics!world!bzs
From: bzs@world.std.com (Barry Shein)
Newsgroups: misc.jobs.contract,comp.edu
Subject: Re: Qualified? or Dreaming?
Message-ID: <BZS.90Jul23214608@world.std.com>
Date: 24 Jul 90 01:46:08 GMT
References: <1990Jul8.063302.4076@xavax.com> <2616@igloo.scum.com>
	<1990Jul11.233006.17884@nmt.edu>
	<1990Jul23.060010.20406@grian.cps.altadena.ca.us>
Sender: bzs@world.std.com (Barry Shein)
Organization: The World
Lines: 54
In-Reply-To: steve@grian.cps.altadena.ca.us's message of 23 Jul 90 06:00:10 GMT


From: steve@grian.cps.altadena.ca.us (Steve Mitchell)
>_VERY_FEW_ programming jobs in industry involve
>writing compilers or operating systems: most (at least in my
>experience) involve using computers to solve various real-world
>problems.  It would be much more useful if CS departments turned out
>grads with general problem solving and programming skills, rather than
>aiming them at jobs developing system software at computer companies.

The issues of compilers and operating systems are directly relateable
to many other problems.

Every time you sit down and try to put a little interpreter front-end
on your program you're facing a lexical analysis and parsing problem.
Some of the more interesting graphics programs (e.g. those used to
inexpensively, but realistically, generate foliage) are generated by
grammars expressed in BNF's (a compiler topic.)

Go ahead, write a little program that verifies and classifies a typed
in number as correct integer or float or e-notation etc. It's a
parsing problem, or at least very simply solved once you understand
such things. Is that really out of the realm of "reality"?

As a matter of fact, any time you sit down to do a transformation of
F(INPUT)->OUTPUT (kinda rare, huh?) where INPUT can be bounded by a
function and the transformation must be rigorous you're basically
writing a compiler. Who cares if it's a textual program being input or
a signal stream (didja know that some of the better work on automatic
EKG analysis used parsing approaches to the problem?) or whatever is
generating the input.

And finite state automatas show up everywhere, not just compilers.
Any network protocol is written down as a DFA, no real difference,
nothing unique about compilers.

Operating systems courses generally teach about concurrency problems
(among other things), something that comes up constantly in data
bases.

There's no difference, at a conceptual level, between OS ideas like
critical sections and atomic writes, concurrency control, multi-stage
commits etc. And deadly embrace is a critical issue in any shared
resource, nothing special about OS's other than that they are careful
to bring the issue up. Avoidance, detection, correction, recovery,
much more than just OS issues.

I think you're very wrong. That you ran into an individual that wasn't
very good at what you needed hardly proves the point. You singled out
some of the most useful courses in a CS program.
-- 
        -Barry Shein

Software Tool & Die    | {xylogics,uunet}!world!bzs | bzs@world.std.com
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD