larry@jc3b21.UUCP (Lawrence F. Strickland) (02/20/86)
><3422@nsc.UUCP> <1405@gitpyr.UUCP> >A comment from a person without a completed CS degree (I've math degrees) >formerly working toward a phd who's gone to bat for CS degrees. Well, I really didn't want to step into this one, having several of the aformentioned problems (my degrees are in Math and Education, we are a two-bit state school [that one really hurt], and our program is out of Engineering Technology [close as you'll ever get to EE here]), but this thing could easily get out of hand without focusing on the main point. What everyone is really saying (in my biased opinion) is that a lot of CS degree programs are not worth the paper needed to print the course descriptions. TRUE. Both IEEE and ACM have realized this and are now in the process of (slowly) accrediting schools for CS programs and any- thing else that even vaguely looks like a CS program. GREAT. All the comments that were made simply say that a good Computer Scientist (I DID NOT SAY PROGRAMMER) has to know things other than how to locate the computer room when its raining outside. A sprinkling of math, a bit of business, some accounting, a little chemistry, some physics, etc. etc. ad nauseum are all important. You can be a good programmer without knowing these, but eventually you will be tripped up by an algorithm you don't know or a piece of 'general knowledge' that you somehow missed. Maybe it will take the form of using Bubble sort to sort 1,000,000 floating point numbers directly on disk, or maybe it will be spending 80 hours doing a three- dimensional plotting program only to discover the molecules it was supposed to graph are all planar! Instead of this, how about coming up with a good CS program. I asked for this a couple of months ago and got exactly two responses one of which had to do with a course NOT to include, but no courses TO include. Great, huh! Those people were helpful, but where was everyone else????????????????????? What do we need and what don't we need to make a superior program?????????? -----Larry Strickland St. Petersburg Junior College St. Petersburg, FL 33542 ...akgua!akguc!codas!peora!ucf-cs!usfvax2!3b2bame!jc3b21!larry (or something like that)
g-rh@cca.UUCP (Richard Harter) (02/23/86)
In article <> larry@jc3b21.UUCP (Lawrence F. Strickland) writes: > >Instead of this, how about coming up with a good CS program. I asked for >this a couple of months ago and got exactly two responses one of which had >to do with a course NOT to include, but no courses TO include. Great, huh! >Those people were helpful, but where was everyone else????????????????????? >What do we need and what don't we need to make a superior program?????????? > This is a fun kind of query. Here are some suggestions for an SE degree; I don't know if that counts: English: The usual year, plus either a course in writing poetry or one act plays. A technical writing course would be optional. Sciences: One year of chemistry and one year of physics. The physics courses should be from the Engineering track. EE/MATH: Statistical theory of communication and linear systems. Math: Calculus, advanced calculus for engineers, linear algebra, mathematical statistics (the hard core stuff, not "statistics for grade school teachers"), and numerical analysis. Software Engineering: (a) A course on the literature and how to use it. This course would familiarize the student with all of the major journals, the major collections of algorithms, and the major collected packages (proprietary and public domain) of utility programs. The student will be given the task of searching the literature for a desired algorithm and responding with a list of choices and a recommendation. (b) Class project: The class is given a large program (100,000+ lines of code) and the associated documentation and must make a specified enhancement. The documentation should be updated to reflect the enchancement. At least one third of the project should be a detailed critique of the errors made in designing and implementing the enchancement. (c) Design Methodologies Review: Review of the major current design methodologies with cross comparisons. (d) Surviving operating systems: A course in how to get on board a new operating system. Course emphasizes knowing what things you need to be able to do when you use a computer and determining with a minimum of fuss how to find out how to do them in a strange operating system. Course should cover the major operating systems from the viewpoint of the professional SE not yet familiar with the operating system in question. Computer Science: (a) Data structures: This is essential! (b) General Methods for Constructing Algorithms: Greedy, divide and conquer, et al. I could go on, but I won't. This will have to do as a starting point. Richard Harter, SMDS Inc.
ladkin@kestrel.ARPA (Peter Ladkin) (02/25/86)
In article <166@jc3b21.UUCP>, larry@jc3b21.UUCP (Lawrence F. Strickland) writes > [...] how about coming up with a good CS program. > [......] > What do we need and what don't we need to make a superior program?????????? The ACM publishes curricula for CS courses, obtainable from them, and their accreditation requirements should help. Peter Ladkin
ladkin@kestrel.ARPA (Peter Ladkin) (02/25/86)
In article <6350@cca.UUCP>, g-rh@cca.UUCP (Richard Harter) writes: > [curriculum for a CS degree] > EE/MATH: Statistical theory of communication and linear systems. > Math: Calculus, advanced calculus for engineers, linear algebra, > mathematical statistics (the hard core stuff, not "statistics for > grade school teachers"), and numerical analysis. This would be almost entirely useless to anyone but a numerical analyst. What about propositional and predicate calculus, complexity theory (concrete and asymptotic), graph theory, combinatorics, some universal algebra (plus a bit of groups, rings and fields for concreteness), Boolean algebra, relational algebra, model theory, theory of computation, theory of formal languages, recursion theory (Turing machines, recursive functions), lambda calculus and denotational semantics? Or did you forget these? Peter Ladkin
g-rh@cca.UUCP (Richard Harter) (02/27/86)
In article <> ladkin@kestrel.ARPA (Peter Ladkin) writes: >In article <6350@cca.UUCP>, g-rh@cca.UUCP (Richard Harter) writes: >> [curriculum for a CS degree] >> EE/MATH: Statistical theory of communication and linear systems. >> Math: Calculus, advanced calculus for engineers, linear algebra, >> mathematical statistics (the hard core stuff, not "statistics for >> grade school teachers"), and numerical analysis. > >This would be almost entirely useless to anyone but a numerical >analyst. >What about propositional and predicate calculus, complexity >theory (concrete and asymptotic), graph theory, combinatorics, >some universal algebra (plus a bit of groups, rings and fields >for concreteness), Boolean algebra, relational algebra, model >theory, theory of computation, theory of formal languages, >recursion theory (Turing machines, recursive functions), >lambda calculus and denotational semantics? >Or did you forget these? Mostly forgot -- I trained as a mathematician/physicist and worked for a while on a PhD in mathematical logic so I tend to forget that people actually have to learn math. 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. 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. If you are not in commercial applications you will, more likely than not, be working with engineers. That's where the jobs are and that is what most people should be training for. Mind you, this is just my opinion, but it backed by experience and observation. Richard Harter, SMDS Inc.
g-rh@cca.UUCP (Richard Harter) (02/27/86)
Followup note: My last note and previous posting addresses the issue of what kind of training is relevant for a career as a computer professional. This in not the same thing as asking what kind of training is relevant for a degree in computer science. My feeling is that the CS degree is not the right degree for most people who will be working in industry. This is is not to put down the value of CS which I follow with great interest. It is simply that applications and computer science are different animals. Richard Harter, SMDS Inc.
ladkin@kestrel.ARPA (Peter Ladkin) (02/28/86)
(ladkin - non-numerical curriculum) > >Propositional and predicate calculus, complexity > >theory (concrete and asymptotic), graph theory, combinatorics, > >some universal algebra (plus a bit of groups, rings and fields > >for concreteness), Boolean algebra, relational algebra, model > >theory, theory of computation, theory of formal languages, > >recursion theory (Turing machines, recursive functions), > >lambda calculus and denotational semantics. (harter) > [....] 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. I'm glad you asked........I claim that all of the above topics are needed to a greater or lesser extent by *applications*. (That filtered my choice of examples). It really is true that yesterday's theory is today's application. It's also true that an undergraduate doesn't need *much* of these, but then an ug doesn't need *much* of any one thing. I'll include the list in a separate posting. > On the other hand, if you are going to work in scientific and > engineering applications you should have a working knowledge of > numerical analysis. I agree wholeheartedly. Many computer scientists believe that numerics isn't computer science, but that e.g. data-base handling is. I have never understood this view. I taught numerics as a TA at UCBerkeley, to ugs and grads. The ugCS majors dropped the ug course, almost without exception. (There were non in the graduate course to begin with). This despite the presence of eminent numerical mathematicians in the CS Dept, as well as in the Math Dept. Peter Ladkin
g-rh@cca.UUCP (Richard Harter) (03/01/86)
In article <> ladkin@kestrel.ARPA (Peter Ladkin) writes: > >(ladkin - non-numerical curriculum) >> >Propositional and predicate calculus, complexity >> >theory (concrete and asymptotic), graph theory, combinatorics, >> >some universal algebra (plus a bit of groups, rings and fields >> >for concreteness), Boolean algebra, relational algebra, model >> >theory, theory of computation, theory of formal languages, >> >recursion theory (Turing machines, recursive functions), >> >lambda calculus and denotational semantics. > >(harter) >> [.... expressions of doubt of value .....] > >I'm glad you asked........I claim that all of the above topics >are needed to a greater or lesser extent by *applications*. >(That filtered my choice of examples). >It really is true that yesterday's theory is today's application. >It's also true that an undergraduate doesn't need *much* >of these, but then an ug doesn't need *much* of any one thing. >I'll include the list in a separate posting. > You're probably right. I have a bias because all of my work has been done in procedural languages -- FORTRAN, PL/I, ALGOL, C, JOVIAL, and sundry assembly languages. I have never worked in Lisp or Prolog. The problem with procedural languages as a class is that they put blinkers on your thinking. One's view of how to do things is filtered through the types of things that can be easily done in the language being used. There are applications (AI, par exemplar) where procedural languages are the wrong choice because the fundamental paradigm of the language does not fit the application. It is probably also true that the undergraduate in either CS or SE should get some understanding of the nature of computers and of computation in general. Actually this is more of a matter of culture rather than career preparation. If your knowledge of the field you are working in is narrow and technical you are at the mercy of changes in the nature of the field. It is advisable to also to have the broad background so that changes in paradigms can be put in perspective. Richard Harter, SMDS Inc.
doug@terak.UUCP (Doug Pardee) (03/04/86)
Wanna know what's missing in the usual curricula for a CS degree? They usually leave the CS grad with the belief that he understands programming. Wrong; he understands Computer Science. There is no "science" in most applied computing. Professional programmers seldom spend any time on CS concerns. The applications that need to be programmed aren't exotic; they just need to be written. In most cases, the algorithm is blatantly obvious. All that needs to be done is to select a reasonably appropriate data structure, then crank out the code to do the job. Look at this list of CS topics suggested so far: > Statistical theory of communication and linear systems, > calculus, > advanced calculus for engineers, > linear algebra, > mathematical statistics > numerical analysis, > propositional and predicate calculus, > complexity theory (concrete and asymptotic), > graph theory, > combinatorics, > universal algebra, > Boolean algebra, > relational algebra, > model theory, > theory of computation, > theory of formal languages, > recursion theory, > lambda calculus, > denotational semantics. Is there anything on this list that will help you port UNIX(tm) to a new system? What about implementing an FFT? What about when your assignment is to write a windowing system for a bit-mapped display? Does it provide any guidance for writing a CICS Command Level transaction which allows funds to be transferred between accounts? Will it simplify the job of writing an electronic spreadsheet program? Or maybe it will help you write an SNA or SCSI interface? I'm not saying that a CS curriculum should teach programming. What I'm saying is that the students should be kept aware that CS and programming are two different things. (Oh, by the way, this implies that I believe that a CS degree is not particularly useful for a programmer.) -- Doug Pardee -- CalComp -- {hardy,savax,seismo,decvax,ihnp4}!terak!doug
jdz@wucec2.UUCP (03/04/86)
In article <6420@cca.UUCP> g-rh@cca.UUCP (Richard Harter) writes: >In article <> ladkin@kestrel.ARPA (Peter Ladkin) writes: >>In article <6350@cca.UUCP>, g-rh@cca.UUCP (Richard Harter) writes: >>> [curriculum for a CS degree] >>> EE/MATH: Statistical theory of communication and linear systems. >>> Math: Calculus, advanced calculus for engineers, linear algebra, >>> mathematical statistics (the hard core stuff, not "statistics for >>> grade school teachers"), and numerical analysis. >> >>This would be almost entirely useless to anyone but a numerical >>analyst. 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? I agree that statistics might not be as useful, but probability certainly is. Simulation software is a big part of what's out there. Linear algebra helps also. Many of these tools are used before the program is written, during design, to help make decisions about data structures and algorithms to be used. Could be they are never included in the program. >>What about propositional and predicate calculus, complexity >>theory (concrete and asymptotic), graph theory, combinatorics, >>some universal algebra (plus a bit of groups, rings and fields >>for concreteness), Boolean algebra, relational algebra, model >>theory, theory of computation, theory of formal languages, >>recursion theory (Turing machines, recursive functions), >>lambda calculus and denotational semantics? Again, more tools. Some are more useful during design, some have great bearing on actual code produced. (I am not too sure about the universal algebra, though). The lambda calculus is a very powerful abstraction tool; denotational semantics has great use in early design; combinatorics and complexity theory let you know if you're kidding yourself about a solution to your problem. > 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. >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. -- Jason D. Zions ...!{seismo,cbosgd,ihnp4}!wucs!wucec2!jdz Box 1045 Washington University St. Louis MO 63130 USA (314) 889-6160 Nope, I didn't say nothing. Just random noise.
g-rh@cca.UUCP (Richard Harter) (03/07/86)
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.
rb@ccivax.UUCP (rex ballard) (03/07/86)
Premise: Scientist - One who observes, identifies, and classifies patterns and defines the principles, laws and rules to describe his observations. Engineer - One who applies these rules, laws, and principles to solve problems. He also standardizes the practices. Artist - one who perverts these rules, laws, and principles to solve problems. (which the Scientist new material to describe). There is no such thing a "Pure Scientist" or a "Pure Engineer" or a "Pure Artist". CS has an important role, to identify which patterns may be most cost effective and define them in terms that will be useful to engineers and artists. K&R were "artists" when they used some (at that time) unconventional design and programming techniques, in addition to the conventional ones, to produce UNIX and C. Later, Computer Scientists defined terms and principles which described these innovations. Engineers then had a terminology and principles which could be applied to new applications. When a company has a product that incorporates new principles, it is valuable to have a computer scientist describe "why" it works. Example: Joe writes a multi-processor system that works very efficiently, he used several unconventional techniques to design the system and keep processors co-ordinated, it is fast but very complicated to write for. Later, someone wants to simplify the interface to Joe's system by putting UNIX on the multiprocessors. Unfortunately, because UNIX does not have the "inherant" ability to coordinate multiple processors, the UNIX version ends up slower. Joe's implementation is added to the UNIX version and is now not only slower, but also unmanagable. Here is a situation where a CS can look at why Joe's implementation works so well on the original and figure out what properties need to be implemented in UNIX to make the new version both fast and easy to use, or what UNIX properties could be put into the original to make it fast and easy to use. Without the Scientist, the engineer will get "religeous", saying "that's the way it has to be done", just try discussing high level language implementations based on FORTH with a FORTH fanatic. SmallTalk, FORTH, and Chip-8 (for those who remember the COSMAC chip), have very similar characteristics, but scientific comparisons are required to identify the strengths and weaknesses in order to created new and better languages. Without the Scientist, the "artist" will "innovate" in ways that will be wasteful. UNIX was originally written in assembler, the original FORTH could only load source code, wasted code space for "headers", and used an inefficient "inner loop interpreter". Without the engineer's standards, the artist will waste time on "proprietary" implementations which could be more effectively be done by following standards. Ideally, we (computer professionals) should have all three characteristics as part of our training. One area may be dominant, but it is necessary to be able to "switch hats" occaisionally. An artist has to be able to read a "man page" and write documentation that describes the principles behind his innovation. An engineer has to be able to separate the "wheat from the chaff" when looking at or writing a standard and he needs to be able to "improvise" solutions to unconventional problems. A scientist has to be able to recognize unusual expression of a "standard" and be able to "improvise" new examination techniques. We should also be willing and able to recognize our weaknesses and when to consult with others who have different strengths. A business major is not taught "Law", but "when to see the lawyer". A management major is taught "when to see the accountant" rather than every possible accounting practice.