Re: What is computer science good for?

In article <d825oi$4od$1@xxxxxxxxxxxx>, Randy <joe@xxxxxxxxxxxxxxx> wrote:
>spinoza1111@xxxxxxxxx wrote:
>> Randy wrote:
>>>Gregory L. Hansen wrote:
>>>Computer science (as it's taught and researched in academia) has
>>>almost nothing to do with the development of software solutions. CS
>> This is simply incorrect. Most workable solutions are based on some
>> form of cs.
>Yes, and most unworkable solutions are based on some form of CS. Most
>software runs, does something, and terminates. Thus the principles of
>CS are served (the halting problem is avoided).
>The problems with most software are that it arrives late; it doesn't
>serve the purpose for which it was intended; its source code is
>incomprehensible to outsiders; the solution space's abstraction does not
>match up well with the problem space's abstraction (or the
>implementation); it's fault intolerant, etc, etc.

Oh, boy, a fight! I need a beverage for this one.

>> Universities have long emphasized integration and much of cs is about
>> that form of "integration" that results naturally from factoring and
>> analysis.
>Are you aware of any college CS courses in refactoring? I am not.

Programs must vary. A CSci degree at the University of Minnesota
includes these required courses:

CSCI 1901 - Structure of Computer Programming I
Principles of programming. Different programming paradigms
(message-passing, data-driven, event-driven). Students develop
algorithms/data types using language such as Scheme and techniques such as
abstraction, procedures, recursion, iteration.

CSCI 1902 - Structure of Computer Programming II
Object-oriented programming using language such as C++ or Java. Builds on
1901, presenting additional data structures/algorithms. Object-oriented
approach to implement data structures/operations as abstract data types.

CSCI 3081W - Program Design and Development (WI)
Principles of programming design/analysis. Concepts in software
development. Uses C/C++ language to illustrate key ideas in program
design/development, data structures, debugging, files, I/O, state
machines, testing, and coding standards.

At least the student can't graduate without doing some coding. There are
other courses that cover pattern recognition, data mining, natural
language processing, and robotics, and I've seen all of those skills
requested in one job listing or another.

The U of MN also has these courses. They're apparantly not required, but
their existence is heartening.

CSCI 5801 - Software Engineering I
Advanced introduction to software engineering. Software life cycle,
development models, software requirements analysis, software design,
coding, maintenance.

CSCI 5802 - Software Engineering II
Introduction to software testing, software maturity models, cost
specification models, bug estimation, software reliability models,
software complexity, quality control, and experience report. Student
groups specify, design, implement, and test partial software systems.
Application of general software development methods and principles from

>> Well, human beings as such already know how to extract surplus value
>> from each other. If the university got into the business of teaching
>> how to pimp other people who want to pay you as little as possible,
>> then for it to succeed, simple microeconomic reasoning would tell us
>> that nobody would make any money. All actors would have full
>> information and the game would be zero sum.
>Formal system theory like this assumes a lot: that everyone behaves
>predictably and never loses information and plays by the same rules.
>They don't of course. Nor do customers know what they want, what's
>possible, nor what will work best within their business model. Often
>they don't even know what's wrong with their current business model. If
>CS professionals do only what they're told by customers, they'll fail
>nine times out of ten.

I'd almost think the computer science student should select a few courses
from business management.

>> Software engineering has to "teach" in this irresponsible manner, by
>> means of the case study.
>> The problem with the case study is that it is post facto, and NO
>> generalizations can be scientifically made from it, because its base
>> entities are chaotic and complex systems (people and companies).

Oh, case studies are a wonderful addition to an education. They give a
concrete example of abstract principles. You get something out of a case
study when you ask "Why?" Why was Peoplesoft a bad choice, how could the
State of Virginia have anticipated that, how can that be generalized to an
arbitrary entity determining the suitability of an arbitrary product for
an arbitrary task?

>> Nothing can be really learned from this narrative, for the failure may
>> have taught Peoplesoft to pay more attention to nonprofits in such a
>> way that it does a markedly better job in meeting their needs. Nor does
>> it mean that Java is intrinsically faster.
>Dammit, NO. What *can* be learned is that a given approach failed. If

Somewhere there was an insufficient requirements analysis, or vendor
negotiation, or a problem was allowed to continue far longer than it
should have been, or something of the sort. There are lessons to be
learned if it's analyzed and generalized.

"The polhode rolls without slipping on the herpolhode lying in the
invariable plane." -- Goldstein, Classical Mechanics 2nd. ed., p207.