liberte@uiucdcsb.CS.UIUC.EDU (09/06/86)
Regarding an earlier note on electrical engineering: The question of how much electrical engineering is relevant to computer science study depends on how you define the fields. 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. It is clear to me that the closest one needs to get to electrical engineering to understand how computers execute software is the level of combining NANDs and NORs in a logic design course. Below that, the particular technology is irrelevant to computer science since the logic is supposed to do the same thing no matter what the technology is. Logic circuits may even be simulated on computers - so who needs hardware anyway? :-). 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? Of course it helps to know about your neighboring fields to understand how your own field fits in. And it is necessary to have generalists who understand more than two fields in order to integrate the neighborhoods. But there is enough to learn within each of these fields such that we need not divert study time for mostly irrelevant, tangential fields. However, if there is a personal desire to explore other fields, this should be encouraged rather than discouraged in favor of specialization. For proficiency requirements, I would like to see less focus on digital electronics as well as numerical analysis. These two cross disciplinary topics are required often times because there are teachers to teach it and a large body of knowledge to teach, not because they will be useful to the student. An interesting question is what "computer scientists" are doing day and what they will be doing in the future. Some give an historical argument for why numerical analysis and digital electronics are relevant. Some computer science departments evolved out of math, some out of electrical engineering, but computer science should be out on its own by now. Imagine if your computer science department evolved out of business or psychology or physics. Would you want to be required to take business, psychology, or physics courses? How about art or music or any other field in which computers are used? 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. Alot more research is needed in these other areas and computer science will eventually be filled out to the extent that the old war-horses of numerical analysis and electronics will become less important. I'm just getting a little impatient. Dan LaLiberte liberte@b.cs.uiuc.edu liberte@uiuc.csnet ihnp4!uiucdcs!liberte
cdshaw@alberta.UUCP (Chris Shaw) (09/09/86)
In article liberte@uiucdcsb.CS.UIUC.EDU writes: >Regarding an earlier note on electrical engineering: > >The question of how much electrical engineering is relevant to >computer science study depends on how you define the fields. >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. This is silly. There is barely enough material to cover a hardball 4-year honours undergraduate degree as it is, without chopping the field into two totally different disciplines. Imagine if you were to do the same with chemistry. Would you have 4 chem departments ? Physical, organic, inorganic, and theory ? (whatever) Not likely. As one person said, most CS programs have only 1 trivial course per term in first and second year, whose purpose is to get everyone up to speed by the time the real stuff comes around. This business about trivial programming courses is a crock. To go back to the chem example, programming is analogous to chem labs. If you can't do labs, you are not a chemist. If you can't program, you are not a computer scientist. There is simply no point in wasting 2 solid years on programming alone, just as there is no point in simply doing lab technique for a long time before theory is applied. >It is clear to me that the closest one needs to get to electrical >engineering to understand how computers execute software is the >level of combining NANDs and NORs in a logic design course. >Below that, the particular technology is irrelevant to computer science >since the logic is supposed to do the same thing no matter what the >technology is. Logic circuits may even be simulated on computers - so >who needs hardware anyway? :-). To some extent, this is true, although I would get more detailed about what a gate is, etc. However, my comment about CS programs being lax in the first 2 years still holds here: Frosh are doing nothing else, so they might as well learn electricity and a glossing over of transistors & what they do. CompEng is really the engineering school trying to offer CS. It shouldn't exist, simply because CS is too hardware-shy to begin with. >Of course it helps to know about your neighboring fields to understand >how your own field fits in. And it is necessary to have generalists who >understand more than two fields in order to integrate the neighborhoods. Specialization should be in 4th year. No earlier. >For proficiency requirements, I would like to see less focus on digital >electronics as well as numerical analysis. One hears this a lot from undergraduates, simply because they don't like numer- ical. I don't like it either (in general), but not teaching numerical is like not teaching quantum theory to a chemist. You may draw your own conclusions. >...but computer science should be out on its own by now. Numerical IS the cornerstone of CS. It (as Cleve Moler says) "is what God intended computers for". Live with it, it's fundamental. >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 This is plainly idiotic. It is inane to claim that enough is known about "soft" topics such as user interfaces to teach a 4-month undergraduate course on it. For CS to make it as a true academic discipline, it must have academic merit. In other words, it must be hard, and above all an undergraduate degree must cover "all" the bases after (say) third year. Currently the way it works is that programs cover all the good stuff in third year alone, while second year is left blank. In other disciplines, second year covers the general groundwork and the "history" of the field. Stuff like user interfaces are very much research topics and are hardly year 2 or 3 material. Certainly not cornerstones by any means. >Dan LaLiberte
cdshaw@alberta.UUCP (Chris Shaw) (09/09/86)
I forgot to sign that pervious article Chris Shaw .... University of Alberta cdshaw@alberta Bogus as HELL !
brinsmead@calgary.UUCP (Mark Brinsmead) (09/10/86)
In article <65@alberta.UUCP>, cdshaw@alberta.UUCP (Chris Shaw) writes: > ... For CS to make it as a true academic discipline, it must have academic > merit. In other words, it must be hard, ... Are you trying to say that CS is not hard? Are you trying to tell me that when I was consistently putting in hours of 8AM to 1AM (7 days a week, for an 6 month period) *THIS* was not hard? CS is very much a *TRUE* academic discipline, although perhaps it may not be treated as such in *SOME* schools. But of course, if one looks, one can always find a school of engineering, law, or medicine that would grant a degree to a bar of soap if it could meet the tuition. Perhaps this indicates that engineering, law and medicine are also of dubious academic quality. The only difference between these and CS, is that CS is a much younger discipline, and so does not always get the full recognition it deserves. (Sometimes I get *SO* annoyed by people's unthinking comments.) M. Brinsmead @ University of Calgary.
jec@iuvax.UUCP (09/12/86)
> /* Written 9:30 am Sep 10, 1986 by patrick@mcc-pp.UUCP in iuvax:net.cse */ > I suggest that a 4 yr program should cover a large variety of topics > so that when the student later specializes he/she is aware of the > range of the subject matter (i.e. knows how to start learning more) > > I would suggest the following plan for a curriculm: [Goes on to suggest a large list of CS/CE class descriptions] > There should a common core in the above with room for electives to > provide a variety of skills from new graduates. > I leave it to others to discuss the fine details of the advanced topics. > - Patrick McGehearty I disagree. You are solving the problem of having CS and CE in the same curriculum by removing the liberal arts. While this is fine if all you plan on doing in life is work. I think the solution is to get a well rounded education as a under- graduate in your first four years and if you feel you need to know more, get a masters degree. Fortunately, for myself anyway, this is the way it works right now. If you don't want to take French, Philosophy, Physics, Math, Political Science, Astronomy, History, Music, etc. then don't go to a university-- go to a trade school where you can concentrate on just engineering. III Usenet: {ihnp4,pur-ee,purdue}!iuvax!jec UUU I UUU Phone: (812) 335-5561 U I U U I U U.S. Mail: Indiana University U I U Dept. of Computer Science UUUUUUU 021-C Lindley Hall I Bloomington, IN. 47405 III
thomas@utah-gr.UUCP (09/13/86)
Well, reading all these articles makes me feel pretty good about our
curriculum. We recently redesigned our 10-year old curriculum to bring
it up to date, and to make it more rigorous. In the freshman year,
students are busy taking general engineering prerequisites (we are in
the Engineering College, so this is required) such as calculus, physics,
etc. They must also take a Pascal programming course (we expect this to
phase out as more students come from high school with programming
experience) and an "Introduction to CS" course. This course gives an
overview of CS hardware and software techniques, but is not primarily a
programming course (it has programming labs, though). The last couple
of years, we have used Lisp as the language base for this course (using
the Abelman and Sussman book).
After this first "year" (may take longer for some students), students
are admitted to the CS program (by GPA, unfortunately, this is a
University mandated cutoff rule, to try to avoid discrimination cases).
The second year really gets into the nitty-gritty. All second-year
students take two thre-quarter sequences, one in hardware and one in
software. The hardware sequence covers topics from general digital
logic design to microcomputer assembly programming. In the lab, the
students must build and test a number of complex circuits. The software
sequence covers algorithms & data structures, programming linguistics
(the "how" of a computer language, covering, for example, the actions
taken by a language interpreter or the code generation phase of a
compiler), syntax analysis (the other half of compilation), "software
engineering," and other topics. They must also take a one-quarter
course on "discrete mathematics", covering set theory, Boolean algebra,
Markov processes and other (un)related topics.
If they make it through this greuling process, they are then
full-fledged computer science majors (there is a second cut point for
those who are just not suited to the life). They are then required to
take, in the next two years, 4 "core" courses:
Theoretical CS
Operating Systems
Data Communication
Compiler Construction
The question as to whether these courses are really "core" of CS can be
directed elsewhere; these are areas in which we have had strengths, or
which we perceived to by important in and of themselves. There is, for
example, no "Data Bases" course in this list (although I have heard
arguments that data bases and operating systems share many topics in
common (allocation of resources, scheduling of transactions, etc.) so
that one might consider offering a course in "OS & DB", strange as it
seems. But this wouldn't fit well into 1 quarter, that's for sure.)
They must also take 5 electives, of which up to 3 may be in one area
(e.g., a 3-quarter computer graphics, AI, robotics, or VLSI sequence),
and a "senior lab", which is a 3-quarter lab course in either hardware
or software, in which the students are required to design, implement,
test, and document a major project.
In addition to all this, they must complete all the university
graduation requirements, several Math courses (numerical analysis,
probability & statistics), some more physics, a technical writing
course, and maybe some others I've forgotten.
All in all, I think it's a pretty good curriculum (not up to, say, MIT
standards, but what do you want?) and one that should turn out computer
scientists knowledgable in a broad spectrum of topics in CS.
--
=Spencer ({ihnp4,decvax}!utah-cs!thomas, thomas@utah-cs.ARPA)elg@usl.UUCP (Eric Lee Green) (09/14/86)
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? If he is a programmer, how can he know enough about how the hardware works to do it? If he is an engineer, he may make some programming decisions which are disasterous in performance terms, or simply be incapable of programming some of the complicated printer commands now common. 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. >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? The computer world is not totally abstract. Certainly it deals with abstract data such as the fields and records of a database, programs written in a programming language, etc., however, there are physical objects out there like disk drives and terminals too. >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. Alot more research is needed in these other >areas and computer science will eventually be filled out to the >extent that the old war-horses of numerical analysis and electronics >will become less important. I'm just getting a little impatient. 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. 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. I think focusing too heavily on the user interface is perhaps being snooty, assuming that the user is a total brainless slug, and needs his complexity dripped with sugar to make it palatable. Let's face it, computer programs are complex things, and it will always take quite a bit of doing to operate anything that is complex. >Dan LaLiberte >ihnp4!uiucdcs!liberte One final argument about the importance of low-level programming: we have a microvax running VMS sitting around barely being used (who'd want to use VMS when they can use Unix?). My guru asks his guru, "Gee, we have that nice machine just sitting there, why don't we write a simple operating system for it in our grad level operating systems class?". And the Big Guru says, "Well, that's a good idea, but there's probably only 3 or 4 people in this entire university who would know what they were doing, and we're two of them". Moral of the story: from all the ratings I've seen, USL's fairly decent (somewhere in or near the top 20-30), yet most of the students are so inept at hardware that they're totally useless for writing the necessary device drivers for a simple operating system... -- 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.
patrick@mcc-pp.UUCP (Patrick McGehearty) (09/15/86)
In article <2500002@iuvax>, jec@iuvax.UUCP writes: > > /* Written 9:30 am Sep 10, 1986 by patrick@mcc-pp.UUCP */ > > I suggest that a 4 yr program ... > [Goes on to suggest a large list of CS/CE class descriptions] > > I leave it to others to discuss the fine details of the advanced topics. > > - Patrick McGehearty > > I disagree. You are solving the problem of having CS and CE in > the same curriculum by removing the liberal arts. While this is fine if > all you plan on doing in life is work. My apologies for being unclear. By no means did I mean one should neglect obtaining a liberal education (I started with a BA myself with the equivalent of majors in Math, Psych, and CS before I started on grad work). I only intended to address the issue of what material should be covered within the 8 or so courses that constitued a CS major. Not having enough exposure to CE, I do not feel qualified to comment on the specifics of their course requirements, though I feel they should have a high degree of overlap with CS, since their job demands overlap in many ways. The differences are ones of degree rather than kind. - Patrick McGehearty
edwards@uwmacc.UUCP (mark edwards) (09/15/86)
In article <916@usl.UUCP> elg@usl.UUCP (Eric Lee Green) writes: > >>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. Alot more research is needed in these other >>areas and computer science will eventually be filled out to the >>extent that the old war-horses of numerical analysis and electronics >>will become less important. I'm just getting a little impatient. > >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. > >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. I think focusing too heavily on >the user interface is perhaps being snooty, assuming that the user is >a total brainless slug, and needs his complexity dripped with sugar to >make it palatable. Let's face it, computer programs are complex >things, and it will always take quite a bit of doing to operate >anything that is complex. I guess there is a good argument against computer programs being complex , and will always take a bit of doing to operate. 1) IBM CM/VMS it seems most things you do using it on a bare machine is complex. For an example, editing, compling and debugging a C program. Not tough but harder than UNIX. It seems that this supports your argument, but.... Take UNIX a very complex operating system, ( is VM/CMS as complex as UNIX ??? I don't know.). But doing things here seems to make life simplier. Let's see there is "make", now who could live with out that. But wait its making a difficult, and complex task ( making sure all your files with changes get recompiled) EASY ( of course someone must setup a makefile). 2) Look at the first computers, there was not even a compiler around, they had to first, set switches on the front panel bit, by bit, then came cards and paper punches. Now tell me is this not complex. But low and behold, the user interface was made simpler, and we have compilers (even though every thing runs faster and is more doable in machine code) and video terminals to do screen editting !!!!! So I guess things that seem complex can be simplified and made transparent to the users, or in other words BETTER USER INTERFACES. I am not saying that all user interfaces are good, some may in fact be frivolous. It appears that user interfaces, like AI, might be a good topic to branch off of comp. sci. Last thoughts: Picture yourself digging through all the news with out a nice tool like, rn, or vn, or whatever. A good user interface sure is worth its weight in programmers. mark -- {allegra, ihnp4, seismo}!uwvax!uwmacc!edwards UW-Madison, 1210 West Dayton St., Madison WI 53706
hsu@eneevax.UUCP (Dave Hsu) (09/16/86)
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?"
liberte@uiucdcsb.CS.UIUC.EDU (09/16/86)
>/* Written 9:12 pm Sep 13, 1986 by elg@usl.UUCP in uiucdcsb:net.cse */ >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 shall correct my previous statement and now say that the boundary between CS and EE is fairly clear. A CS person does not need to know much about the electronics below the level of logic. But a CE person does need to know both low level computer science and high level (digital) electronics. >The computer world is not totally abstract. Certainly it deals with >abstract data such as the fields and records of a database, programs >written in a programming language, etc., however, there are physical >objects out there like disk drives and terminals too. Sure there is hardware, but a computer scientist is not concerned with building the hardware unless he is also a computer engineer, by my definition. Computer science looks at the function of the hardware and makes use of it with software. As such, I consider machine language programming and even microcoding as software. Programmable logic arrays are definitly borderline firmware. But it's all relative to your perspective. An operating systems course never gets closer to a disk drive than how to use it and timing considerations. You need a fair amount of mechanical engineering to learn how to build disk drives. A graphics course never gets closer to display devices than how their various structures give them different functions. I'm told that high frequency display electronics is a black art. So why does a computer scientist need to know how a transistor works? Sure it's interesting. I took a course in it. But it is pretty much useless knowledge for a person primarily concerned with software. >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. (As someone else here has said a little more vehemently, computer science is not just learning to program.) The connection between CS and math is much closer than between CS and EE. Just about every direction you look within CS, there is math. But this is true of almost every science. So we need to look at what kinds of math are relevant to CS. And the answer is that just about everything in math may be relevant to something CS. So what are the foundations of math that every CS person should know? The answer to that question will change as CS changes. The material in many Discrete Mathematics courses taught by CS departments is certainly relevant. But right now, there is still a heavy emphasis on numerical analysis which I view as an application area. >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... Here CS borders on philosophy and psychology. We must have patience with these corners of CS since the science is indeed fuzzier. But there is still a growing body of fuzzy knowledge to teach. Philosophy and psychology departments do it, so we can too. >as for the >importance of user interfaces, yes, it is important that the user be >able to figure out how to use the software. Maybe I should leave it at that. But I'll add that just because something looks complex doesn't mean we should leave it that way. The goal is understanding as efficiently as possible. Teachers try (I hope) to make their presentations more understandable and less confusing. Designers of most things where people interact with tools are concerned with ease of use as well as safety factors. Why not for computers too? Dan LaLiberte liberte@b.cs.uiuc.edu liberte@uiuc.csnet ihnp4!uiucdcs!liberte