deutsch.PA@Xerox.ARPA (05/23/85)
From: deutsch.PA@Xerox.ARPA I can't believe that people are taking this PDP-8, Timex, etc. vs VAX argument seriously! Seriously, though. If you want to crack peanuts, use your fingers. If you want to crack walnuts, use a nutcracker. If you want to break rocks, use a sledgehammer. You won't get very far on the rocks with a nutcracker. And you shouldn't be surprised that it takes more effort to lift and operate the sledgehammer than the nutcracker! That's half the argument -- that the little machines solve the little problems better partly because they can't solve the big problems at all. The other half of the argument is one that can't be made in the breaking- rocks domain. Software is truly unlike just about anything else in the human universe: managing its complexity is a major intellectual task (again, for big problems). One of the tradeoffs we're usually willing to make is to get some assistance from the machine architecture in this task. If you have a system made up of 500 modules, and you want it to be BOTH reasonably efficient AND reasonably easy to understand AND reasonably easy to modify, then either: - you can write it all in assembler and be an "iron man" like Doug (and me in past lives), and God help you if the person involved ever leaves, gets run over by a truck, loses interest, etc., or if your requirements change substantially and you have to change a data structure; - you can write in a HLL, and either: - have a slow, complex compiler that produces mono- lithic output that runs like the wind but can't be debugged (which, in fact, is a good tradeoff for some of the large-scale numeric problems like weather simulation), and makes you wait forever if you want to change the smallest thing in the program, or - pay some overhead for hardware that assists modularity, like the infamous VAX call instruction (which I confess I've never heard one good thing about). In other words, some of that machine overhead you're paying at execution time is intended to reduce the development and maintenance time for the kind of program that seems to absorb the largest part of people and machine resources -- big ones. It's interesting how our environments shape our ideas of what the "real" problems are. People using computers as adjuncts to real-time equipment think the real problems are the small ones requiring fast computation -- that's where FORTH came from. People in research often think the real problems are the ones of fast turn-around and development -- that's where the high-powered interactive environments (Interlisp, Zetalisp, Smalltalk, etc.) came from. Physicists think the real problems are big numerical ones -- they want Crays and FORTRAN. People at Universities often see the problem as teaching -- hence BASIC. -- Peter Deutsch --
doug@terak.UUCP (Doug Pardee) (05/30/85)
While I generally agree with Peter's comments, I must take issue with: > - you can write it all in assembler and be an "iron man" like > Doug (and me in past lives), and God help you if the person involved > ever leaves, gets run over by a truck, loses interest, etc. Now I disagree with the "iron man" moniker, but I'll let it slide 'cause it ain't worth arguing about. But I had to pick my jaw up off the floor when I read the suggestion that employers shouldn't hire talented people because if those people left then the company would be in trouble! Oh, I've seen companies run on this basis. I worked for one for seven months once. Nobody in the place did anything useful, so they were all easily replaceable if need be. Of course, they didn't need to be replaced because no one ever quit and no one ever got "hired away". Next time I buy a car, I'll go to the junk yard and pick up one without an engine or wheels. It'll be easy to find, cheap to buy, won't use much gas or need much repairs, won't need to have license plates, won't get into wrecks, and nobody'll be stealing it. Heck, it'll last me a lifetime. I wonder if IBM regrets having hired "iron men" like Gene Amdahl and H. Ross Perot, who both left the company and even went into competition against IBM? Does CDC regret having allowed "iron man" Seymour Cray to design its 6000 series systems, now that Cray is gone (and is also in competition with CDC)? Or maybe the Apple Computer Company wishes it had been founded by someone other than the "iron duo" of Steve Jobs and Steve Wozniak. Perhaps Lockheed wishes it hadn't had Bill Kelly around to single-handedly design the Super-Constellation, the U-2, and the SR-71. A colleague once had a poster that read, "A ship in the harbor is safe, but that is not what ships are made for." A company without competent employees is safe from losing any valuable employees, but they're not too likely to turn a profit, eh? -- Doug Pardee -- Terak Corp. -- !{ihnp4,seismo,decvax}!noao!terak!doug ^^^^^--- soon to be CalComp
karsh@geowhiz.UUCP (Bruce Karsh) (06/01/85)
In article <582@terak.UUCP> doug@terak.UUCP (Doug Pardee) writes: >While I generally agree with Peter's comments, I must take issue with: > >> - you can write it all in assembler and be an "iron man" like >> Doug (and me in past lives), and God help you if the person involved >> ever leaves, gets run over by a truck, loses interest, etc. > >But I had to pick my jaw up off the floor when I read the suggestion >that employers shouldn't hire talented people because if those people >left then the company would be in trouble! I dont think that Peter said that "employers should not hire talented people". I think the argument is that companies usually do not want software that can only be maintained by one person. The Cray & the CDC 6600 may have been designed largely by just one person. But that person is no longer *required* to maintain these systems. Besides, if you had a person who was as good as S. Cray, you probably wouldn't have him hand code assembly programs. -- Bruce Karsh | U. Wisc. Dept. Geology and Geophysics | 1215 W Dayton, Madison, WI 53706 | This space for rent. (608) 262-1697 | {ihnp4,seismo}!uwvax!geowhiz!karsh |
ksbszabo@wateng.UUCP (Kevin Szabo) (06/02/85)
>> - you can write it all in assembler and be an "iron man" like >> Doug (and me in past lives), and God help you if the person involved >> ever leaves, gets run over by a truck, loses interest, etc. >But I had to pick my jaw up off the floor when I read the suggestion >that employers shouldn't hire talented people because if those people >left then the company would be in trouble! The original posting never mentioned anything about not hiring talented people to do a job. Quite the opposite actually. It was more a comment that you shouldn't hire people with TUNNEL vision. It is very interesting that you are still arguing the advantages of assemblers over High Level Languages while people are finding compilers preferable in designing HARDWARE. Yes, I'm talking about Silicon Compilation and its next of kin, Symbolic Layout. Both INITIALLY have a penalty in speed and chip size, however silicon is at the point where the emphasis has moved from squeezing a cpu onto a chip to a new outlook of trying to get the chip designed before the I.C. process is obsolete. Sorta sounds like operating systems development ten years ago doesn't it? As designers start using high level design tools they find that their designs can even turn out smaller than manually designed circuits. This occurs because design is fast enough that a few approaches can be experimented with, and initial design decisions are not as expensive to reverse when necessary. Machines like the MicroVax* and the ethernet chips would have never made it to market as quickly as they did without the benefit of High Level Design. And you're still harping on assembler. Sheesh. I hope everybody appreciates my not repeating all the talk about mom, apple pie, and greats like Amdahl & Cray. How all that fit in with the original statement I'll never know. Kevin -- Kevin Szabo watmath!wateng!ksbszabo (U of Waterloo VLSI Group, Waterloo Ont.)
gnu@sun.uucp (John Gilmore) (06/05/85)
> Machines like the MicroVax* > and the ethernet chips would have never made it to market as quickly > as they did without the benefit of High Level Design. Oh, is that what makes today's Ethernet VLSI so buggy? Busted compilers?