Path: utzoo!attcan!uunet!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!samsung!crackers!jjmhome!banyan!gil From: gil@banyan.UUCP (Gil Pilz@Eng@Banyan) Newsgroups: comp.arch Subject: Re: The CPU with 3 brains---486 compatibility with 8008 Message-ID: <1106@banyan.UUCP> Date: 12 Nov 90 21:24:17 GMT References: <42737@mips.mips.COM> <1990Nov4.014901.23819@zoo.toronto.edu> <1990Nov6.223738.13265@ux1.cso.uiuc.edu> <9333@b11.ingr.com> Reply-To: gil@banyan.com Organization: Empire of the Senseless Lines: 52 In article pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >The problem we have now is that we are running the same thing twenty >years later when a laptop has got vastly more power and a more >sophisticated architecture than a PDP-11/34, and that the people doing >development are simply not of the caliber, or at least of the good >taste, of Kernighan and Ritchie, in language, compiler, and OS >architecture. Well these guys also didn't have a horde of marketing weeines telling them the machine must: o) dice o) slice o) moosh o) squoosh or else they wouldn't be able to sell it ! Most of the UNIX bloat can be attributed to the "creeping featurism" that results when purchasing decisions are based on oversimplified lists of system features. It's not _that_ hard to come up with a NEW system that is simple and elegant when you're tucked away in some lab with no one watching you (K&R deserve kudos for designing one that was also portable and widely usefull). It's quite another thing to be working on an existing product and tell your boss or whatever "Look, this system doesn't handle concept A very well. In order to work with concept A I'm going to have to redesign major portions of the system. Not to worry though, the end result will be much simpler, much smaller and much more robust than if I just tacked it on to the side. And it'll only take five times as long initially !" I don't know about y'all, but everyone *I've* ever worked for would say "Tack it on to the side !" because they know that those _buying_ the system _don't_ _care_ wether the underlying implementation is elegant or not. They just want to see "feature A" as a bullet item in some marketing spiel. "Good taste" carries absolutely no weight in this industry. All you can hope for is to sell your company on the fact that a well designed, integrated solution will end up costing them far less in support later down the road. Unfortunately the current software industry has the unfathomable habit of chronically underestimating or simply discounting support costs. Even if they do appreciate support hassles they know that those problems will probably be a year in surfacing, and if they don't ship this product NOW with "feature A" in it they won't even be AROUND next year, so "feature A" get's glomed onto the side. Any simple, elegant system will quickly become a large, sticky mess of poorly designed, redundant features when it is brought into widespread industrial use. It's the nature of the beast. If you want simpler, more elegant systems you'll need a market that makes its purchasing decisions based on simplicty and elegance and NOT on gross features. Gilbert Pilz Jr. "I don't believe in nihilism, anarchy is too confining gil@banyan.com for me, I have no opinion about apathy." - g. panfile