rb@ccivax.UUCP (rex ballard) (03/21/86)
In article <1439@ames.UUCP> eugene@ames.UUCP (Eugene Miya) writes: >Since we have been discussing >the value of the degree, I thought it might be interesting to discuss >what that degree is about. > >One faction in the room asserted it was not a science at all, but a form >of engineering. In terms of *most* of what is done in the field today, this is probably true. Engineering is the Application of Scientific principles. Programming, design and implementation of both hardware and software products is simply engineering. Engineer once meant "designer of engines" and early computers were called computing engines. In the same way that engines are simply applied combinations of physical laws (combustion, leverage, inertia, aerodynamics, thermodynamics, electronics, electromagnetics,...), Computers are also combinations of physical laws. The computer is little more that a large array of switches organized into finite state-machines. Proper combinations and seqences of states fed into these state-machines (Instructions fed to CPU) can create the effect of anything from a fast calculator for computing trajectories to artificial intellegence. >>What distinguishes scientific reasoning from "non-"scientific reasoning? >[I assert one thing is experimentation and control, but this is a problem >for mathematics and astronomy.] For the sake of argument, (from articles in net.sci) let's define science as the organization of observations into a set of axioms, theories and principles. Certainly there are these properties, they are used in predicting the execution time of a specific algorythm, the response time, the amount of memory, even the cost of production and maintenance. One poster indicated that he often went weeks without writing a program, I believe him. Our computer science people analyse (sp?) the "product code" to determine how things can be done more profitably. For them, any code they write is simply a tool for doing this analysis. We don't need a lot of CS's, but we DO need them, and it's hard to hang to the GOOD ones. >Is computer science closer to psychology than either math or EE? In some ways, yes, particularly in terms of design issues, there is a great deal of psychology involved. It is important to be able to design in such a way as to be able to understand a system which cannot be percieved directly. To do this, it is necessary to determine what psychological barriers might prevent understanding. Certainly, the ability to be able to think in "Macros" (understanding different applications of the same algorythm or principles) is an important trait. Others, many as yet undiscovered, require CS people to corrolate them. (example: why are two 50 line subroutines easier to maintain than one 100 line subroutine, even though they are functionally identical?) >Knuth asserts CS IS different from math in a paper published a year ago. >One conference participant said we should perhaps take an artistic >approach [I disagreed, but I know a mathematician who thought perhaps >music was a good model, and passed this suggestion on]. Earth shattering news here, computers are just tools or a means of either doing something else, or simulating something else, usually to solve problems. The CS and Engineer can come up with a system that is so fast that it can compile Unix in 3 seconds, but what else can it do? For this, Artists, Creative Geniuses, Hackers, or whatever else you want to call them have opened up markets and applications that were undreamt of 20 or 30 years ago. In doing so, new properties and characteristics become relevant. Even design and evaluation methodology change dramatically. In the same way that a musician learns about chord progressions, languages (music notation), and rythms, then uses them to create new and different sounds and rythms to become a composer, the "Computer Artist" learns languages, design methodologies, subroutines, and other techniques, then uses them to create new and different applications, systems, and languages. (pardon the run-on sentence) Some creative types deliberately and flagrantly violate the "rules" in the arts. G.B. Shaw seldom used commas. Picasso's works, at the time were considered diliberate violations of the "Rules" of art. Beethovan shook the music world with unconventional perversions of the "Rules". On the other hand, few of the "physics" of music have changed since aristotle, only the aesthetics. Many computer types confuse aesthetics or "style" with the "physics" of software. Only a few years ago, CS proponants thought programmers should be rated based on "number of lines of code written", the result was some maintenance nightmeres that still haunt some companies. I remember a CS person having fit's because I used an electronics "schematic diagram" metephor instead of Yourdon-style DFDs and Structure Charts. Six months later, he was reccomending SDs (for another company) and I was using McDraft to do SD's for some very complex software. I've changed metaphores twice since then due to the availability of more efficient tools (Although I am still hoping to get a minimal electronics CAD/CAM program for the Mac). Each time, the result (almost instant understanding of 100,000 lines of source code) justifies the change. This is also characteristic of an Artists approach. If the CS determines which technique is best (so far), or the EE can automate any of my older techniques, I'll probably adopt them, and maybe adapt them :-) again. I'm adept at adopting then adapting :-). But that's the Artistic aspect. >>If we are a new science where we are laying ground as opposed to describing >"real" ground, how should we proceed? How will we know if we have overstepped >bounds? Are there bounds? As mentioned before, the primary function (in my view only) of the CS is to determine, by whatever means possible, what principles will lead to the most "profitable" product. Depending on the company, this may mean fastest, smallest (code size), easiest to enhance or maintain, most complex yet still managable, or shortest "first cut" developement time. Often, a mix of these properties is required. Often different archetectures and environments make different mixes more "optimal". The CS should be capable of determining what the trade-offs are and how to achieve the most important goals set by that company. He should also be able to go into a company, examine their product (hardware, software, whatever) and determine where their strengths and weaknesses are in terms of the Science used in relation to the Science available. >These are a few questions I've thought about and I know the others thought >about. These are questions and answers we should all be thinking about. (from my paragraph on state machines) I've been musing over a silly idea lately. Could the combinatorial characteristics of the data flow between finite state machines lead to the approximation of an infinite state machine (a living organism)? :-) Since I'm not a CS, I don't know. Told you it was silly! Kismet. (if you really want to talk about this paragraph, direct follow-ups to net.sci)