Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site cca.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!cca!g-rh
From: g-rh@cca.UUCP (Richard Harter)
Newsgroups: net.cse
Subject: Re:  CS degrees, are they useful?
Message-ID: <6570@cca.UUCP>
Date: Fri, 7-Mar-86 01:07:44 EST
Article-I.D.: cca.6570
Posted: Fri Mar  7 01:07:44 1986
Date-Received: Sat, 15-Mar-86 20:51:24 EST
References: <6350@cca.UUCP> <6420@cca.UUCP> <>
Reply-To: g-rh@cca.UUCP (Richard Harter)
Organization: Computer Corp. of America, Cambridge
Lines: 84
Summary: 

In article <> jdz@wucec2.UUCP (Jason D. Zions) writes:
>
>Not true. Any program doing any calculations more complex than pointer and
>subscript math and counters can use the skills of numerical analysis. Ever
>watch people sum a floating-point array starting with the largest elements?

	Oh yes indeedy, I have.  I have also seen them compute variances
	using the sum of square minus square of averages formula and
	coming up with negative variances.
>
>I agree that statistics might not be as useful, but probability certainly is.
>...

	The point of mathematical statistics (also taught as probability)
	is for understanding and dealing with scientific and engineering
	applications -- you have to be able to talk to the people you are		working with and understand their problems and help them.

>>
>> [Richard Harter] However I will contend
>>that for most applications mathematical logic is of no particular
>>value.  Almost every thing that you list is of importance or is
>>critical for pure computer science and is of no particular value
>>in end user applications except algebra.
>
>Which goes a long way to explaining why most applications are poorly written.
>(Yeah, I know, cheap shot - sleazy rhetoric - flames to /dev/null) With all
>these tools mentioned above, there should be no reason to have applications
>that need total rewrites for small additions, that run far longer than they
>should need to, that have strange bugs, that use inappropriate algorithms.
>
	Here's where we part company.  I contend that the reason that
	most programs are poorly written is that most programmers do
	not know much about writing good programs.  I further contend
	that the sort of theoretical tools that are provided in CS
	programs are not particularly relevant for writing good programs.
	I also contend that damn little real study has been made of real
	major programs, good and bad.

	This is a real gripe on my part.  I have read numerous papers
	where some experimenter gathered 20-30 students, ran them through
	a controlled experiment where some of the students did things one
	way, and the others did it another way.  These studies are almost
	uniformly worthless.  If you want to understand how programming
	works and fails, get out in the field and look at real programs.

	I would like to see someone go out and look at a number of large
	programs (and their environment) and come back and say things
	like:  The following overall program structures had these problems;
	these issues lead to great problems if they are not properly taken
	into account (notorious example -- storage allocation and deallocation
	in languages not supporting automatic garbage collection); the
	following default assumptions lead to severe maintenance problems
	under the following conditions; the following practices will have
	the following problems under these conditions (example - all too
	many operating systems have hardwired table sizes that bite you
	unexpectedly); etc.

	You don't need the lambda calculus to write good programs.  You
	do need to know what it means to time out a program.  You need
	to know what it means to write modular code.  You need to know
	how not to write programs that have default assumptions about data
	structures and algorithms embedded in them so that they cannot
	be easily modified.

>>On the other hand, if you are going to work in scientific and
>>engineering applications you should have a working knowledge of
>>numerical analysis.  At a guess I would say that 60% of all
>>programming is commercial applications, 30% is scientific/
>>engineering applications, and 10% is systems.
>
>What about the 60% - if you sum your accounts receivable in floating point, you
>deserve to lose; if you use a bubble sort instead of heapsort or quicksort or
>any other nlogn sort, you deserve to lose. If you don't know enough about other
>programming paradigms to know how to use the one you have effectively, you may
>very well end up losing.
>
	Since I have never worked in commercial applications I can't
	comment intelligently [the obvious wisecrack may be taken as
	having been made].  However, I doubt that many people working
	in commercial applications write sorts -- you use canned
	packages.  My jaundiced observation is that COBOL exists
	to protect commercial applications programmers from themselves.

	Richard Harter, SMDS Inc.