Path: utzoo!attcan!uunet!decwrl!sgi!karsh@trifolium.esd.sgi.com
From: karsh@trifolium.esd.sgi.com (Bruce Karsh)
Newsgroups: comp.arch
Subject: Re: It looks like he's at it again!
Message-ID: <64044@sgi.sgi.com>
Date: 13 Jul 90 05:26:27 GMT
References: <1990Jul12.012730.4248@Stardent.COM>
Sender: karsh@trifolium.esd.sgi.com
Reply-To: karsh@trifolium.sgi.com (Bruce Karsh)
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 157

>Oh, stick it in your ear, Karsh.

Wow, first I get flamed, then I get a whole bunch of comments which agree
with my posting.

>What is it with you and computer science, anyway?

Well, I wouldn't have mentioned it, but you asked...

I love the science part of computer science, but I am dissapointed with
some of the religious-sounding beliefs that have attached themselves to
the field.  When I was an undergraduate in CS, I became very frustrated
with what we were taught.  We were bombarded with information about how
programs "should be" structured, but usually the end-result of all this
structuring was slow, user-unfriendly, huge programs.  Much of what we
did was completely unconcerned with what the program did for the user.
Instead it was concerned with a lot of cosmetic aspects of program
designs.  I left the field and switched to mathematics where
correctness was considered more important than cosmetics.

Portability, modularity, programming style, and extensibility are
religious issues,  Their general necessity has never been proven, but
it's been taken as an axiom or a dogma of the field.  In some
instances, they may indeed be necessary, but the massive faith in these
techniques as a panacea is widespread and harmful to the field and it
has driven otherwise promissing people out of the field.

I still hope for a day when programming professionals will evaluate
programs by how well they perform their intended function, not by how the
souce code is indented and commented, or how portably they were
written.  (This is, by the way, how people who purchase software
usually evaluate it).

>  Sure, there are plenty of dingbat undergrads who come out with a
>CS degree and think they know it all, but that's true of any field.

I agree that there are a lot of dingbat undergrads who come out with a
CS degree.  But...

In other technical fields, I have not found the stridency of belief in
unproven cosmetic practices as I have found in computer science.  If
electrical engineering were taught like computer science, all the
schematics would be drawn perfectly symetrically, would all use the
very same circuits, would be governed by standards which would add a
fortune to their costs.  TV's would display maybe 5 frames per second,
and would have no audio.  You'd have to use a soldering iron to change
the channel.  They'd only have one channel, but they'd all be
networked.  You'd have to have a system administrator to install one.

There seems to be little interest inside the CS field in issues of how
well the end program works for its intended purpose.  Issues like
portability, programming style, extensibility, and modularity are given
way more emphasis than they deserve.  Is it correct to sacrifice
modularity to improve the refresh rate of a graphics display?  I think
it is, but there are too many programs out there where the religion of
modularity superceeded the necessity of fast performance.

Just what is the common base of knowledge that is basic to computer
science?  Any graduate from a major US university in, for example,
physics, will know how to solve spring-mass systems and orbit problems,
apply Maxwell's equations (in a variety of ways) to electrical charge
distribution problems, set up and solve differential equations for
motion of bodies in fields, solve gas-law problems, ... etc.  In
contrast, the undergraduate computer science grad will assuredly know
how to indent code, how to decompose a problem into way too many
subroutines, how to criticize the way a program is commented, and how
to avoid learning about any particular computer's machine language and
peripherals.

So, yes there are dingbat undergrads in all fields, but in CS, there's
an intellectual attitude against learning new and difficult things.  In
CS, they are too machine-specific, or too unstructured, or too
unportable, or too mathematical, or too application-specific, or not
adequately object- oriented, or too hard to maintain.  Coupled with the
anti-intellectual attitude, there is an emphasis on style over
substance.  By this I mean that ideas are evaluated not on their
correctness, but on their conformance to a set of unsubstatiated
beliefs about proper program style.  I think that these bad attitudes
are diminishing in CS, but they have not gone away yet.  Let's help get
rid of them.

My favorite example of the anti-intellectual current in CS is a paper by
a very famous computer scientist in which he states that the teaching of
certain computer languages should be treated as a criminal act.  Learning
and teaching should not be denigrated, but should instead be encouraged.
Do we find that kind of anti-intellectual bias in other technological
fields.  What if mechanical engineers just decided that bending moments
in beams were a bad thing and should not be taught or allowed to be used?
Flatbed trucks would be too heavy to run on our highways.  If we arbitrarily
choose to consider correct techniques as "bad", then our computer systems
will become slow, bloated, and unreasonably expensive.

I think a lot of this is a result of the rapid growth of the field.
Other disciplines have had a much longer time to mature and to really
figure out what is basic and what isn't.  As CS matures, the situation
will certainly improve.  In the mean-time, when I watch someone with
good but unpopular ideas about CS get blasted on the net, I think we
should look for what's right in these ideas and add them to our base of
knowledge about CS.

>None
>of the really good computer scientists I've met were arguing that there
>was no place for assembly language in writing computer systems.  I've got
>a PhD in CS, and I use assembler when and where necessary.  So do the other
>PhDs I know.

Exactly right.  Really good computer scientists don't often argue that
there's no place for assembly language.  But many typical one do.  In
my opinion assembly language is an underused technique with real power
to make smaller, faster, cheaper systems.  It's one of many techniques
for doing this and the negative attitudes about it are completely
unwarranted.

>Herman Rubin shows up on the net with his usual tunnel vision about what
>he needs to solve his problems, so Chris Shaw writes an equally intemperate
>rebuttal, and here you are blazing away at the "Computer Science religion."
>Take it to alt.flame, will you?

I've done a fair amount of work with numerical methods over very large
amounts of data and I don't think Herman Rubin's problems are unique to
him.  What he writes about may not be completely mainstream, but it's
not fringe work and it's not unimportant.  Our attitudes about what is
important in software are a major factor in the architecture of modern
computer systems.  I think that it's proper to discuss these issues in
a reasoned manner, free from biases about "how things should be done".

If you want to stop the flames, then let's not refer to someone else's
ideas as "tunnel vision".

>IF we're talking a few days, sure, it makes sense, and that's where you're
>going to get the most bang for the buck anyway -- the hot spots are easy 
>to find and you do them first.  But there are plenty of people who get so
>hypnotized by the speed improvements that pretty soon they're ready to go
>out and write the whole damn application in assembler and it's goodbye to
>portability.

>As usual, the sensible approach is somewhere between the extremes.

Sometimes the sensible approach is to operate at the boundaries, not in
the middle.  Doesn't it really depend on what the program is supposed
to do when it's done?  If a major application of assembly programming
is required to meet the needs, then the sensible approach is to just do
it.  There's no point in being hypnotized by speed, but if speed is
what's important and portability isn't, then approaches which sacrifice
portability for speed are sensible.

>>Often I think many programmers don't care at all how long things take.
>>If you don't believe this, just watch a Unix workstation boot.  Ten
>>million instructions per second, and it still takes minutes to boot.

>Amen to this, at least.  Even some O/S programmers, who spend a lot of
>time in the lab waiting for computers to boot up, are guilty here.

Yeah, isn't this a ripe area for a significant improvement in usablity?

			Bruce Karsh
			karsh@sgi.com