windley@ted.cs.uidaho.edu (Phillip J. Windley) (05/16/91)
In article <13371@exodus.Eng.Sun.COM> stlin@stevelin.Eng.Sun.COM (Steven Lin) writes:
The difference is obvious: Computer engineering major students have to
meet the requirement of hardware design courses (of course software
courses too). On the other hand, the CS students do not have the
requirement to take hardware design courses. This does not mean that a
CS major has no capability to take hardware courses and later becomes a
hardware designer. And a CE major can be a software designer if he
wishes to do so. The difference tells that CS is oriented to software
and CE is oriented on hardware, and the faculty and equipment will be
significant different in schools for these two fields.
We are grappling with this issue right now. Political pressure in the
state has made the VP for Academic Affairs decide that there should be a
CompE degree offered here. The problem is that the new degree program will
get its resources from existing departments (read CS and EE). There are
insufficient resources to accredit all three programs so this has led to
long meetings with faculty examining what CompE is.
I'm not sure that we ever reached a concensus about what CompE is. I don't
think, as Mr. Lin does that the difference is an emphasis on hardware vs
software. One could well imagine a CS degree with two different kinds of
emphasis. I rather think that it is an attempt by industry to get
something for nothing. They want someone with the specialization one would
would normally get in an MS degree for the price of someone with a BS.
The biggest problem in my mind is that no one (faculty) I know feels
comfortable recommending that a student major in CompE. The problem is
that there just aren't that many jobs advertised for CompE majors. Thus,
everytime a CompE grad goes to an inteerview they have to start by
convincing the interviewer that they really do have the background to do
the job. Interestingly enough, the company that put so much pressure on us
to offer a CompE degree didn't even list CompE in the degrees they were
interested in interviewing this year.
--phil--
--
Phil Windley | windley@cs.uidaho.edu
Assistant Professor | windley@cheetah.cs.uidaho.edu
Department of Computer Science |
University of Idaho | Phone: 208.885.6501
Moscow, ID 83843 | Fax: 208.885.6645dwgordon@matt.ksu.ksu.edu (Dwight W. Gordon) (05/17/91)
windley@ted.cs.uidaho.edu (Phillip J. Windley) writes: >In article <13371@exodus.Eng.Sun.COM> stlin@stevelin.Eng.Sun.COM (Steven Lin) writes: > The difference is obvious: Computer engineering major students have to > meet the requirement of hardware design courses (of course software > courses too). On the other hand, the CS students do not have the > requirement to take hardware design courses. This does not mean that a > CS major has no capability to take hardware courses and later becomes a > hardware designer. And a CE major can be a software designer if he > wishes to do so. The difference tells that CS is oriented to software > and CE is oriented on hardware, and the faculty and equipment will be > significant different in schools for these two fields. Actually, at Kansas State, our CompE's are oriented to the bridge that spans both the hardware and software points of view. IMHO they can program (but not as well as a Software Engineer), and they can design and deal with hardware (but, perhaps, not as well as a "die hard" EE). Previous graduates have found themselves in departments dominated by either extreme. One graduate, now at HP, told me that he was the only person with hardware experience in his department (a department full of Software Engineers). Others have found themselves programming. >... >The biggest problem in my mind is that no one (faculty) I know feels >comfortable recommending that a student major in CompE. The problem is >that there just aren't that many jobs advertised for CompE majors. Thus, >everytime a CompE grad goes to an inteerview they have to start by >convincing the interviewer that they really do have the background to do >the job. Interestingly enough, the company that put so much pressure on us >to offer a CompE degree didn't even list CompE in the degrees they were >interested in interviewing this year. It's the same way here! Companies request EE's with extensive digital design and software experience, but they don't want a CompE! - Dwight - -- Dwight W. Gordon, Ph.D. Kansas State University dwgordon@matt.ksu.ksu.edu Electrical and Computer Engineering dwgordon@ksuvm.bitnet Durland Hall Phone 913-532-5600; FAX 913-532-7810 Manhattan, KS 66506-5105
windley@ted.cs.uidaho.edu (Phillip J. Windley) (05/18/91)
In article <1991May16.202233.17134@maverick.ksu.ksu.edu> dwgordon@matt.ksu.ksu.edu (Dwight W. Gordon) writes: windley@ted.cs.uidaho.edu (Phillip J. Windley) writes: >The biggest problem in my mind is that no one (faculty) I know feels >comfortable recommending that a student major in CompE. The problem is >that there just aren't that many jobs advertised for CompE majors. Thus, >everytime a CompE grad goes to an inteerview they have to start by >convincing the interviewer that they really do have the background to do >the job. Interestingly enough, the company that put so much pressure on us >to offer a CompE degree didn't even list CompE in the degrees they were >interested in interviewing this year. It's the same way here! Companies request EE's with extensive digital design and software experience, but they don't want a CompE! So, let's here it: Anybody in a company out there just dying to hire CompE's? Anybody in a school with a CompE degree finding jobs? -- Phil Windley | windley@cs.uidaho.edu Assistant Professor | windley@cheetah.cs.uidaho.edu Department of Computer Science | University of Idaho | Phone: 208.885.6501 Moscow, ID 83843 | Fax: 208.885.6645
torek@elf.ee.lbl.gov (Chris Torek) (05/28/91)
In article <1991May16.202233.17134@maverick.ksu.ksu.edu> dwgordon@matt.ksu.ksu.edu (Dwight W. Gordon) writes: >... at Kansas State, our CompE's are oriented to the bridge that >spans both the hardware and software points of view. ... > Previous graduates have found themselves in departments dominated >by either extreme. One graduate, now at HP, told me that he was the >only person with hardware experience in his department (a department >full of Software Engineers). Others have found themselves programming. I find this entirely unsurprising. These two Hoary Old Terms provide a nice analogy: `bottom-up programming' and `top-down programming'. These refer to the idea of `solving a problem by taking existing building blocks and putting together a solution' and `solving a problem by breaking it down into sub-problems and solving each one'. Neither method is The Answer; indeed, the bottom-up folks once put out a poster in which people were seen building a bridge `top down': placing bricks in the air, with no visible support, so that when they were done the two ends should meet the ground. (I never saw anything equivalent from the top-down people. Ah well.) What is really done, when one understands the problem sufficiently, is to use both approaches together: break the problem into the appropriate pieces (not just any old pieces) and solve them with existing techniques. The same is true for computer manufacturers. They have people who know how to build hardware, and they have people who know how to write software. Thus, they divide the problem in two: Group A builds the machine and Group B writes software for it. The typical problem that occured was a lack of communications between the two groups. Manufacturers recognized this years ago and did something about it; the hardware designers normally operate with information from the software group, and vice versa. This is all well and good, but it tends to start and end at a fairly abstract level (`we would like this instruction to work this way' or `it would help if the device did this under these conditions'). One of the reasons for this is, naturally, that Group A is not expected to know how to do Group B's job, and vice versa. Group A is supposed to know hardware in depth, and Group B is supposed to know software in depth, and there is a pervasive belief that no one can do both. This is even true to a large extent (particularly when `in depth' means down to the solid-state-physics level on the one hand, or down to the cost of each system call on the other). But this can be taken too far, and usually *is* taken too far. The hardware is done and the software people are writing code. Something goes wrong and the software people hunt and hunt for their bug. But wait, it turns out it is a hardware bug: the computer gives the wrong answer when the instruction crosses a page boundary and the address is in the `extra' segment and the latch feeding the full address to the adder is just a nanosecond too slow and the carry-ahead loses a bit. The average programmer would never guess the true cause, and might spend a *long* time before blaming the hardware, but without a likely mechanism. Finding this bug requires, if not luck, knowing something about how the hardware works, knowing that timing problems can occur, knowing to look for suspicious signs like `instruction on page boundary can delay inputs to address latches'. The Computer Organization course taught in many undergraduate CS degree programs does not go into this much detail. Is the cure, then, to each everyone everything? No---this is at best overkill, at worst a terrible waste of time and effort. But teaching *someone* everything, or as much of everything as possible, why, that is a different matter entirely. Cross-discipline training is valuable, sometimes in surprising ways. The generalist, the one who knows a little about everything, seems to me to be undervalued. (Incidentally, I do not claim to be a true generalist, although I do seem to have found an unusual path, having started with `general science' interests in elementary school and gone to electricity and electronics in junior high, thence to computers in high school, so that I have a reasonably vague idea what transistors *really* do and how hardware *really* works. This also has some bearing on a separate discussion, about `math education'. While most of you are probably doing the same thing I am---working from your own memory of your <elementary/junior high/high school/college> days---perhaps you have managed to forget something that I suspect remains true to this day: Being `smart' got you nowhere with your peers. Sometimes it did not work too well with the teachers either, at least if you, like me, would try to correct them.... At social skills, I always was a slow learner. [Do I detect a hint of bitterness in my own writing? It is there, I suppose, but I think it got overstated here. Things were not really *that* bad for me.]) -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov