Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!bpa!cbmvax!jesup From: jesup@cbmvax.commodore.com (Randell Jesup) Newsgroups: comp.arch Subject: Re: It looks like he's at it again! Message-ID: <13392@cbmvax.commodore.com> Date: 24 Jul 90 01:56:58 GMT References: <1990Jul12.012730.4248@Stardent.COM> <64044@sgi.sgi.com> Reply-To: jesup@cbmvax (Randell Jesup) Organization: Commodore, West Chester, PA Lines: 63 In article peter@ficc.ferranti.com (Peter da Silva) writes: >In article <64044@sgi.sgi.com> karsh@trifolium.sgi.com (Bruce Karsh) writes: >> 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). > >You mean like the people who buy Word Perfect because it runs on just about >anything? The people who can't upgrade their software when they switch from >DOS to UNIX, Windows, or OS/2? Portability means repeat business. That would be a great point, Peter, except for one minor problem: WordPerfect is 100% written in assembler for speed. However, I agree with you in principle. Portability is very useful. However, market pressures can force certain applications to be downcoded or initially coded in assembler. When you have a large number of customers, the cost of coding, debugging, and maintenance is amortized over a larger base. When it's a one-off, or for use by a small number of customers, or is to be written and maintained in a university environment, or where speed is not an important concern, then assembler should be avoided is possible. Remember the environment that CS teachers and grad students work in. There's little or no benefit to be gained by making something particularily fast, or small (or maintainable in some cases). It's far more important to get something implemented in a minimum of programmer time than to have it run faster. The trade-offs as seen by a CS prof or grad student are different than those seen in industry. Not totally different, but often a difference of degree and philosophy. It's fairly easy for theoretical CS people to be "purists" (and for industry people to be converse). There was a good editorial about this in an IEEE publication a few months back. Most often programs written by undergrads are throw-aways (fairly often grads too), and they're taught little of software engineering, maintenance, etc that they'll need to know in industry. Regardless of the rhetoric about modularity, etc, many CS undergrads come out coding like "fortran" programmers (insert your favorite spaghetti-code language for fortran if you wish). I've seen it happen, with students with 3.x averages from a _good_ technical school. If they're good they'll pick it up, but what the hell were they being taught? When I was in CS, the only Software Engineering course was a grad- level course. I think it should be taught in 2nd or 3rd semester undergrad. I also think there's some confusion as to what computer science is. Most CS grads go into industry, and most work as engineers. Few are doing "science" in industry with a BS in CS. Most companies want a CS degree for someone who is to do Software Engineering duties. Most of the science part of CS is only really taught to grad students. Either undergrad CS majors should be trained more in Software Engineering, or they should be split, and CS should be more theoretical, and SE be more oriented to the different techniques and knowlege needed in industry. Well, more than enough flaming well of the topic of newsgroup. Sorry, I guess something touched a nerve. (In case you can't guess, I work in industry, am not a "purist", and I'm sure my perceptions are affected by this.) -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"