Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!ncar!mephisto!mcnc!rti!amr From: amr@rti.rti.org (Alan Roberts) Newsgroups: comp.arch Subject: Re: Bloat costs Message-ID: <3902@rtifs1.UUCP> Date: 14 Jun 90 20:18:52 GMT References: <442@van-bc.UUCP> <266577FA.6D99@tct.uucp> <1990Jun1.200333.10672@pmsmam.uucp> <23473@uflorida.cis.ufl.EDU> Reply-To: amr@shrike.UUCP (Alan Roberts) Organization: Research Triangle Institute, RTP, NC Lines: 26 In article <23473@uflorida.cis.ufl.EDU> bp@beach.cis.ufl.edu (Brian Pane) writes: > ... >Finally, note that large and "inefficient" programs advance the state >of the art in software more often than small and clever programs. >Consider X Windows. It is a huge system designed for flexibility >rather than efficiency, and it requires significant hardware power, >but it has revolutionized the way we use computers. > Well, when you have a large base of "3M" workstations (well, they are slightly better than that, but not much) that management will not immediately replace (for many of the geo-political reasons that were discussed in an earlier article in this group), then I'm afraid you have to argue that X Windows has great promise to revolutionize how your users operate, but is "part of the current problem" relative to providing them service. I don't have too much problem with your making use of large and inefficient programs to advance the state-of-the-art in a research context, but I'd like my VENDORS to work somewhat harder at keeping their existing base operational when they convert those research results into products. The kind of turnover of large numbers of platforms that bloated products require may cause a gleam in the eyes of vendor bean-counters, but end-user bean-counters "just say no," and the frustration, disappointment, and anger flows downhill from there.