Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!haven!decuac!shlump.nac.dec.com!e2big.mko.dec.com!ceomax!gillett From: gillett@ceomax..dec.com (Christopher Gillett) Newsgroups: comp.arch Subject: Re: It looks like he's at it again! Summary: Computer Science? No such thing, really. Message-ID: <379@e2big.mko.dec.com> Date: 13 Jul 90 17:37:18 GMT References: <1990Jul12.012730.4248@Stardent.COM> <64044@sgi.sgi.com> Sender: usenet@e2big.mko.dec.com Reply-To: gillett@ceomax.dec.com (Christopher Gillett) Organization: Digital Equipment Corporation, Semiconductor Engineering Group Lines: 148 In article <64044@sgi.sgi.com> karsh@trifolium.sgi.com (Bruce Karsh) writes: >>Oh, stick it in your ear, Karsh. > How about that for creative, constructive dialog? Nothing like the calm, rational approach to discussion, eh? :-( >When I was an undergraduate in CS, I became very frustrated >with what we were taught. We were bombarded with information about how >programs "should be" structured, but usually the end-result of all this >structuring was slow, user-unfriendly, huge programs. ... > >Portability, modularity, programming style, and extensibility are >religious issues, Their general necessity has never been proven, but >it's been taken as an axiom or a dogma of the field. In some >instances, they may indeed be necessary, but the massive faith in these >techniques as a panacea is widespread and harmful to the field and it >has driven otherwise promissing people out of the field. > I, too, found my CS education to be a tour de force in frustration. It was painfully evident that most, if not all, the CS profs were complete ivory tower types who'd never worked a day in their lives in the "real world". I felt as if most of my education was indoctrination into some sort of weird cult of comment outlines, structured walk-throughs, and correct punctuation and indentation. Issues of architecture, hardware, and system building were treated like Great Mysteries of Faith. I finally had to go over to the EE folks to get my head on straight about these issues. All things considered, I graduated *knowing* that I really didn't know much. Most of what I learned was by working with fellow students on interesting work. I can't think of any course that provided reasonable information that was useful outside of the ivory tower. I could go on like this for hours, but I digress (sorry). >I still hope for a day when programming professionals will evaluate >programs by how well they perform their intended function, not by how the >souce code is indented and commented, or how portably they were >written. (This is, by the way, how people who purchase software >usually evaluate it). Bruce, you're close here, but I don't fully agree. Yes, when someone purchases a piece of software they are looking for speed, power, ease of use, and error-free functionality. And it is definitely appropriate to evaluate a software professional by examining the output of her work. But, I think the better way to judge someone's ability is by also looking at issues of design efficiency, portability, and other issues usually associated with "proper software engineering technique". Why? Because the better the upfront engineering is, the easier it is to produce correct programs with good portability, robust user interfaces, etc. If you accept that good engineering leads to good software, then the best way to evaluate somebody is by how much $$$ they make for their employer. Certainly that is an excellent measure of professionalism (of course, I'm excluding a whole host of ethical issues here that aren't appropriate for this forum). >There seems to be little interest inside the CS field in issues of how >well the end program works for its intended purpose. Issues like >portability, programming style, extensibility, and modularity are given >way more emphasis than they deserve. ... >Is it correct to sacrifice >modularity to improve the refresh rate of a graphics display? I think >it is, but there are too many programs out there where the religion of >modularity superceeded the necessity of fast performance. > Here I would beg to disagree again. Of course, you don't want to sacrifice performance for structure, but you also don't want (dare I say you *must not*) sacrifice structure for performance. This leads, ultimately, to software that isn't maintainable, and will cost a lot to keep running (assuming that it's your intention to keep developing, extending, enhancing, etc. In my world, there's no such thing as a "one off" program). Real-life case in point: In a previous job, I worked on a suite of compilers targeted toward various MC680x0 machines. These compilers were written exclusively in assembly language. No high level fluff for us, dammit :-). The compilers were capable, under normal circumstances, of compiling around 40,000 lines/minute...more if you tweaked the environment a tad. But these guys sacrificed all semblance of structure, modularity, and documentation in the quest for incredible speeds. Finally, it got to the point where we just couldn't make cost efficient changes. Bugs tooks days, not hours, to track down and fix. In the end, we wound up (at considerable expense) writing a whole new suite of compilers (in C) using better engineering techniques. Now they have a maintainable set of tools, but it sure was expensive. >Just what is the common base of knowledge that is basic to computer >science? The problem here is that we insist of calling this field a science. It's not. It simply isn't. You can't compare the "basic tenets of CS" to the underpinnings of mathematics, physics, chemistry, and the like. The longer I work in this field (a little over 10 years now), the more I'm convinced that this field is art, not science. You either have the intellectual and (*especially*) creative abilities to "do software" or you don't. The folks that lock themselves in ivory towers and think about strange mathematical phenomena are not computer scientists, they're mathematicians who are harnessing computers in interesting new ways. A fresh out of school EE is a scientist, a fresh out of school CS type is someone ready to learn the real truth about computers and software engineering. >My favorite example of the anti-intellectual current in CS is a paper by >a very famous computer scientist in which he states that the teaching of >certain computer languages should be treated as a criminal act. Which paper is this? I've seen a lot of (IMHO...) silly stuff floating around (like "GOTOs considered Harmful"...geez, will these guys ever learn?), but I've not encountered this gem. Please post a citation. >Exactly right. Really good computer scientists don't often argue that >there's no place for assembly language. But many typical one do. I once got "marked down" on a software project in school because I had the unmitigated gall to implement a set of lookup routines in assembly language. First, the prof couldn't understand how the routines worked, then he reamed me out for using "dangerous implementation techniques". He never really could justify his remarks, but he's the prof... >>>Often I think many programmers don't care at all how long things take. >>>If you don't believe this, just watch a Unix workstation boot. Ten >>>million instructions per second, and it still takes minutes to boot. > >>Amen to this, at least. Even some O/S programmers, who spend a lot of >>time in the lab waiting for computers to boot up, are guilty here. > Geez, you guys must be using the wrong iron. My fine DECstation 3100 boots up in no time at all. Maybe you should rush to your nearest DEC office and grab a few, eh? :-) Wow, I guess we're now fully off the subject of computer architecture. Should we move this discussion, or do the system architects find it amusing to watch the software guys beat on each other? > Bruce Karsh > karsh@sgi.com FWIW, /Chris P.S. Ken Olsen speaks for Digital Equipment Corporation, I speak for me! #include --- Christopher Gillett gillett@ceomax.dec.com Digital Equipment Corporation {decwrl,decpa}!ceomax.dec.com!gillett Hudson, Taxachusetts (508) 568-7172