Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!agate!dog.ee.lbl.gov!elf.ee.lbl.gov!torek From: torek@elf.ee.lbl.gov (Chris Torek) Newsgroups: comp.edu Subject: Re: CS and CompE Message-ID: <13604@dog.ee.lbl.gov> Date: 28 May 91 03:00:02 GMT References: <1991May12.224331.20754@lynx.CS.ORST.EDU> < <1991May14.190239.1330@cs.yale.edu>> <13371@exodus.Eng.Sun.COM> <1991May16.202233.17134@maverick.ksu.ksu.edu> Reply-To: torek@elf.ee.lbl.gov (Chris Torek) Organization: Lawrence Berkeley Laboratory, Berkeley Lines: 89 X-Local-Date: Mon, 27 May 91 20:00:02 PDT 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 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