Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!panda!husc6!seismo!umcp-cs!eneevax!hsu From: hsu@eneevax.UUCP (Dave Hsu) Newsgroups: net.cse Subject: Re: CS vs. CE Message-ID: <171@eneevax.UUCP> Date: Mon, 15-Sep-86 22:13:21 EDT Article-I.D.: eneevax.171 Posted: Mon Sep 15 22:13:21 1986 Date-Received: Sat, 27-Sep-86 10:22:21 EDT References: <13500008@uiucdcsb> <916@usl.UUCP> Reply-To: hsu@eneevax.UUCP (Dave Hsu) Organization: Imperial Widget Research Center, Kingdom of Maryland Lines: 143 Keywords: CS, CE, curriculum, math, user interface, AI, other barbs. In article <916@usl.UUCP> elg@usl.UUCP (Eric Lee Green) writes: >In article <13500008@uiucdcsb> liberte@uiucdcsb.CS.UIUC.EDU writes: >>Since there is a field of computer engineering as distinct from >>computer science, we should take advantage of the fairly distinct >>boundary between these fields. > >Is there a distinct boundary? Or is there a boundary area that is sort >of fuzzy? Think about who programs the microprocessor inside your >printer. Should he be a programmer? Should he be an engineer? I would even venture to say "extremely violently fuzzy". Traditionally, one tries to abstract the problem into terms that have meaning in both disciplines; you draw a dividing line, as it were. For printers, you reduce them to raster devices and let the engineers have the guts down; the CS types get everything else on up. As technology marches on, the CS people are beginning to seriously infiltrate what was formerly EE domain. HP's font system (among others) in the Laserjet reflects old- school thinking. The PostScript/Interpress/whathaveyou engine reflects new-school thinking. > It is >obvious that there is a large middle area, and that this large middle >area is indeed a quite practical and profitable place to be. And it >appears to me as if most computer science curriculums are totally >ignoring this area of computer science. All too true. The typical CS program requires perhaps 2 semesters worth of glossing over systems design, and the typical CS major leaves school steeped in the lore of good database design, completely ignorant of the importance (and profitability :-) of controller-level design. >>By implication, my view is that computer science should confine >>itself to the abstractions of the computer world - software, theory, machine >>design; whereas computer engineering is concerned with the hardware, >>electronics, and peripherals. Should computer engineering be considered >>a subset of computer science or of electrical engineering or neither? Electrical Engineers need Computer Science much in the same way that Physicists need Mathematics; they view it mostly as a tool, and not necessarily as a discipline of itself. I believe that CE belongs in the middle ground; CS is not alone in its fundamental division. How many EE's do you know that entered that field hoping to do mountains of glorious digital design, only to sink into a sea of field theory and signal analysis? CE has become too digital for hardened EE's, and too electrical for hardened CS people. Although I am a CS major, I feel most at home here in engineering, because they seem more fit to cope with the middle ground. I am not by any stretch of the imagination qualified (anymore, anyway) to be an EE student. On the other hand, I think that what few CS professors we have who are venturing out into `CE' (we have no formal CE program) are grossly out of touch with the real world. Putting a CE program in with the EE's is an insult; putting it in with the CS's is a farce. >>I would like to see requirements that take into account the importance >>of user interfaces (graphics, psychology of programming) and >>application areas other than numerical analysis such as data bases >>and symbolic math. > >1) numerical analysis: Some math should be looked at, since the very >idea of a computer is an offshoot of the lamda calculas, Turing >machine, and other mathematical topics, but spending semesters >grinding through differential equations and linear algebra and other >stuff that a programmer would never use is a Big Lose. Right now I'm >working on a problem in regular expression evaluation that makes heavy >use of set theory in order to really understand the problem and its >execution, an argument that some higher math is indeed quite useful to >a programmer. I think you hit it on the head. Useful to many, but not all. There are a great many problems that require an extensive knowledge of higher mathematics, but (1) there are equally as many that don't, and (2) these problems tend to get solved when a mathematician learns to program what he wants, and not when a CS learns to program what a mathematician wants. I still think we need to impose a certain degree of linear algebra on CS majors though; it seems too closely tied into system performance to ignore. >2) user interfaces, AI, etc.: I see a growing tendency of researchers >in areas like AI/cognitive science to spend their time moping around >thinking about vague generalities, and totally ignoring any thoughts >about the implementation of their fanciful ideas... as for the >importance of user interfaces, yes, it is important that the user be >able to figure out how to use the software. Pictures are neat, but >they don't do anything except sit there, and some people seem to be >getting carried away figuring out fancy ways to put icons, pull-down >menus, etc. on their programs, without putting equal thought into what >their program is supposed to be doing. Again, what should Joe Shmoe care about the interface; he never sees beyond emacs? I disagree that people are getting too carried away with user interface design; in fact, all too few people are working on it. Most of the texts on user interface design (including Dr. Shneiderman's... sorry, Ben) that I've seen end up as surveys on the same handful of papers, simply because there aren't enough coherent, well designed experiments on the interface. Think for a minute: what would life be like if you were still using hardcopy? Life without detachable keyboards, with early burnout from excess eyestrain? Having become happily Unix-ized, tcshed and Suntooled, can you bring yourself to use the Univac 1100OS sitting off in the next room? Huh? On DECWRITERS? If I were adjusting UMd's program, I'd make the following changes. Your institution may or may not have similar courses: 1) move the data structures language survey into the programming languages course, in exchange for the section on storage allocation 2) compress the systems and computer architecture courses into one. even a CS major should be able to handle gates through latches in one semester. cripes. I aced both courses with a total of maybe 15 lectures out of 60, no formal training in digital logic, and limited practical experience. 3) make the operating systems design course optional. 4) make the software engineering course mandatory. nothing else we teach here is closer to reality (well, IBM team-oriented reality, anyway) than this course, and it forces you to learn something about project management, something about interface design, and something about your fellow hackers. this one alone would make a wonderful acid test to weed out incompetents. 5) find some money to move the parallel-processing, interface design, and microcomputer courses from intermittent status to permanent courses. they aren't any less important than, say, the image processing or computer graphics courses, are they? >>Dan LaLiberte >>ihnp4!uiucdcs!liberte >-- > > Eric Green {akgua,ut-sally}!usl!elg > (Snail Mail P.O. Box 92191, Lafayette, LA 70509) > > -- Tengo lo mismo que doy y solo sirve al presente. Babbling: it's not just a job, it's an adventure... -dave -- David Hsu (301) 454-1433 || -8798 || -8715 "I know no-thing!" -eneevax Communications & Signal Processing Laboratory / EE Systems Staff Systems Research Center, Bldg 093 / Engineering Computer Facility The University of Maryland -~- College Park, MD 20742 ARPA: hsu@eneevax.umd.edu UUCP: [seismo,allegra,rlgvax]!umcp-cs!eneevax!hsu "...so how come HIS eyebrows are connected?"