ncmagel@ndsuvax.UUCP (ken magel) (08/12/86)
What do you feel should be the relationship between CS and CE programs at the same school? Should they cooperate, compete? To what extent? When should institutions merge the programs rather than keep them independent? How much hardware should a CS person see and how much software should a CE see?
elg@usl.UUCP (Eric Lee Green) (08/21/86)
In article <243@ndsuvax.UUCP> ncmagel@ndsuvax.UUCP (ken magel) writes: > > What do you feel should be the relationship between CS and CE programs >at the same school? Should they cooperate, compete? To what extent? When >should institutions merge the programs rather than keep them independent? A "real" computer science curriculum might include an architecture class, something like, "These EE guys built us a simple 68000-based microcomputer, and you'll have to write a very simple operating system monitor for dealing with the disk drives and such". This is much the way it happens in The Real World. To do this, you'd need to have cooperating CS and CE courses. This is assuming that the students in this class plan to do systems programming and not commercial programming. If you are to do systems programming, you need to know systems (which include both hardware and software). If you are going to do commercial programming, a hefty dose of Accounting would be better. >How much hardware should a CS person see and how much software should >a CE see? You just hit one of my pet peeves. I have seen too many students who just feed their programs into a mysterious black box which spits results back at them. They have no knowledge of what is actually going on down in that black box they call a "computer". My first major, before CS, was CE. I also worked as an electronics technician for awhile, repairing balky terminals at the component level and installing electronic metering equipment (which is pretty much all digital and computerized, nowadays). I find my electronics experience pretty much invaluable insofar as compilers, operating systems, device drivers, assembly language programming, and other such things go. And there's often times even when I'm doing some trivial things like a "grep" utility that some knowledge of the basic principles of the OS, such as paging, IO subsystem, etc. is useful (and the OS cannot be completely divorced from the extensive hardware that supports it). It frightens me to think that there are people graduating from computer science programs today who do not even know what a computer is, just how to feed it in Cobol, Pascal or "C". It isn't necessary for a CS student to learn advance circuit analysis and design. But knowing basic electricity and what purposes such things as transistors, filters, phased-lock-loops, etc. serve is basic knowledge that is both useful and easy to learn, and should really be taught in the early years of a person's CS career (certainly before that hapless person takes architecture or OS courses, if he really wants to get something out of those courses). As for the amount of CS that a CE should know: Hmm. People who major in Computer Engineering as vs. Electrical Engineering should have at least SOME programming knowledge, I suppose, but I don't have an opinion on this one. -- Eric Green {akgua,ut-sally}!usl!elg (Snail Mail P.O. Box 92191, Lafayette, LA 70509) Bayou Telecommunications' ML guru, USL student "The story so far: In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move."
bzs@bu-cs.BU.EDU (Barry Shein) (08/23/86)
> It frightens me to think that there are people graduating from >computer science programs today who do not even know what a computer >is, just how to feed it in Cobol, Pascal or "C". It isn't necessary >for a CS student to learn advance circuit analysis and design. But >knowing basic electricity and what purposes such things as >transistors, filters, phased-lock-loops, etc. serve is basic knowledge >that is both useful and easy to learn, and should really be taught in >the early years of a person's CS career Not trying to be argumentative, but why? I have nothing -against- knowing as much as you can, if you knew me you'd know that I work hard at maintaining a fairly broad knowledge of the beasts I work with, but that's not for everyone. I guess I am looking at it from a little more pragmatic viewpoint, being involved in CS education. The curriculum for an undergraduate is quite crowded. I certainly use my systems course as an opportunity to go over the structure of a computer (I agree that without some overview of this they get funny ideas about how things work or, more importantly, how things don't work.) But 'phased-lock-loops' sounds a level or two beyond the detail I would expect from a computer scientist. Do we teach computer engineers all about NP-complete, LALR(k) grammars and augmented transition networks? No? Then how do they know what they design the machines to run? etc etc. Just curious. I think the field is getting broad enough that some specialization is necessary, although people will still exist (and will be looked up to) who are generalists. -Barry Shein, Boston University
elg@usl.UUCP (Eric Lee Green) (08/31/86)
In article <1099@bu-cs.bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes: > >> It frightens me to think that there are people graduating from >>computer science programs today who do not even know what a computer >>is, just how to feed it in Cobol, Pascal or "C". It isn't necessary >>for a CS student to learn advance circuit analysis and design. But >>knowing basic electricity and what purposes such things as >>transistors, filters, phased-lock-loops, etc. serve is basic knowledge >>that is both useful and easy to learn, and should really be taught in >>the early years of a person's CS career > >I guess I am looking at it from a little more pragmatic viewpoint, >being involved in CS education. The curriculum for an undergraduate >is quite crowded. ... ... ... ... ... ... 'phased-lock-loops' sounds >a level or two beyond the detail I would expect from a computer scientist. OK, yes, that's a little beyond what you would expect from your average CS person. I agree, someone whose specialty is something like database systems or such doesn't need to know THAT much about the hardware he's running on. However, I've noticed that CS curriculums have totally ignored the bottom level of computing -- who programmed the little disk controller/DOS in the CBM 1541 disk drive? The EE who designed it! Which is why CBM Dos sux royally... a programmer, as vs. an engineer who happened to know a little 6502 assembly language, would have done a much nicer job of it, and I would be using the DOS, not fighting bugs and "features" in it. But, that couldn't be done... the recent college grads they had doing their programming had no idea how a disk drive worked. In another example, Unix would have never come into being if Kernighan et. al. had not known how to handle disk drives and RS-232 ports... It is impossible for a university to teach someone about all such things. All that can be hoped for is that it teaches the person enough electronics to be able to understand similiar things when they read the documentation. Which requires good knowledge of digital electronics, and enough knowledge of analog electronics so that the person isn't TOTALLY lost when reading the documentation on how to interface to the XYZ disk controller. In an "ideal" curriculum, the students would cover digital electronics in their freshman year as well as the usual 3 hours of introductory programming they take (I've noticed that most CS curriculums mostly have electives in the freshman curriculum, since the student can only take one CS course at a time until he's learned enough to be able to specialize in things like Operating Systems, Databases, etc.). Then, when the student covers the usual course in assembly language and machine organization, typically in the sophomore year or so, you could have a simple microcomputer where they must make something happen at the machine level... I really don't think that learning how to program in IBM 370 assembly language is going to help you when you need to program an IBM PC, Apple 2, C-64, or other simple microcontroller-style device in assembly language, since you can't and don't have to deal with the actual machine with MVS etc. (everything goes through the OS, of course). Which reminds me of something that happened to me about a year ago. A Junior here (when I was a freshman), needed to do some assembly level programming on his IBM PC. He'd taken IBM 370 assembly language here, but didn't have the foggiest notion how to make the PC do anything. Weird sight, a former electronics technician in the freshman curriculum helping a Junior in CS with a programming task... -- Eric Green {akgua,ut-sally}!usl!elg (Snail Mail P.O. Box 92191, Lafayette, LA 70509) Bayou Telecommunication's ML guru, USL student " In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move."
janssen@milano.UUCP (09/05/86)
In article <888@usl.UUCP>, elg@usl.UUCP (Eric Lee Green) writes: > [...] who programmed > the little disk controller/DOS in the CBM 1541 disk drive? The EE who > designed it! Which is why CBM Dos sux royally... a programmer, as vs. > an engineer who happened to know a little 6502 assembly language, > would have done a much nicer job of it, and I would be using the DOS, > not fighting bugs and "features" in it. [...] Unix would have never > come into being if Kernighan et. al. had not known how to handle disk > drives and RS-232 ports... > > It is impossible for a university to teach someone about all such > things. [...] I really don't think that learning how > to program in IBM 370 assembly language is going to help you when you > need to program an IBM PC, Apple 2, C-64, or other simple > microcontroller-style device in assembly language, since you can't and > don't have to deal with the actual machine with MVS etc. (everything > goes through the OS, of course). Classic conflict between the real interface and the virtual interface. Most schools I've seen do teach some EE topics to CS students, but that's mainly because it's a mixed EE&CS department, or the degree is in Computer Engineering, rather than Computer Sciences. Perhaps all it means is that a person with a CS degree is qualified to work only with the virtual machine. In that case, though, the degree should really be in Software Studies or Systems Sciences. You've got to be willing to not know *something* -- and admit it. Anecdote: In writing a terminal driver for a 68000 board with a dual channel SIO, one part called for reading a byte from one serial port and writing it to the other. Simple to do with a nice architecture, right? MOVB 4(A6),16(A5) (or some such). Right from the input register of one port to the output register of the other. Wouldn't work, of course. Bad hardware! Change chips, then boards, and still doesn't work. Bad software? How???? Turns out the chip won't turn around fast enough for two accesses in one instruction, so the code had to be MOVB 4(A6),TMP / MOVB TMP,16(A5). And it didn't really help that the code was actually in C: port1.output = port2.input; But how are you going to catch things like that without knowing something about the hardware? How do you know when you're too "low-level"? Bill -- Bill Janssen, MCC Software Technology 9430 Research Blvd, Austin, Texas 78759 ARPA: janssen@mcc.com PHONE: (512) 339-3682 UUCP: {ihnp4,seismo,harvard,gatech,pyramid}!ut-sally!im4u!milano!janssen