video@ccwf.cc.utexas.edu (Henry J. Cobb) (05/25/91)
We will always have 'new' exceptions that the continuing growth of computing power allow us to handle. A single keystroke remains about the same amount of data, but as GUI's grow (in size, complexity and user base), its meaning is extended. Finished programs of perfect regularity belong on a platonic plane. 'Creeping featurism' is an attempt to better match the real needs of real users. Data streams through our systems, and is either temporal (and therefore compact) or part of a large database that can be retrieved a piece at a time from disk. When we buy DRAMs, they are for code, not data. And shared libraries will become ever more useful. -- Henry J. Cobb video@ccwf.cc.utexas.edu SFB Tyrant Ph# (512) 447-8957 1400 Rabb Rd. Austin, TX 78704 "The problem with the future is that it keeps turning into the present" -Hobbes
uad1077@dircon.co.uk (Ian Kemmish) (05/27/91)
video@ccwf.cc.utexas.edu (Henry J. Cobb) writes: > We will always have 'new' exceptions that the continuing growth of >computing power allow us to handle. A single keystroke remains about the >same amount of data, but as GUI's grow (in size, complexity and user base), >its meaning is extended. > Finished programs of perfect regularity belong on a platonic plane. >'Creeping featurism' is an attempt to better match the real needs of real >users. > Data streams through our systems, and is either temporal (and >therefore compact) or part of a large database that can be retrieved a piece >at a time from disk. > When we buy DRAMs, they are for code, not data. And shared libraries >will become ever more useful. >-- > Henry J. Cobb video@ccwf.cc.utexas.edu SFB Tyrant > Ph# (512) 447-8957 1400 Rabb Rd. Austin, TX 78704 >"The problem with the future is that it keeps turning into the present" -Hobbes On the other hand, faster processors mean that people become used to larger 1-bit, then 8-bit, then 24-bit, then z-buffered, then double-buffered screens, and the time you spend waiting for page faults becomes more tedious, and..... ... data seems to be growing to. -- Ian D. Kemmish Tel. +44 767 601 361 18 Durham Close uad1077@dircon.UUCP Biggleswade ukc!dircon!uad1077 Beds SG18 8HZ United Kingdom uad1077@dircon.co.uk
tbray@watsol.waterloo.edu (Tim Bray) (05/28/91)
video@ccwf.cc.utexas.edu (Henry J. Cobb) writes:
Data streams through our systems, and is either temporal (and
therefore compact) or part of a large database that can be retrieved a piece
at a time from disk.
When we buy DRAMs, they are for code, not data. And shared libraries
will become ever more useful.
If Mr. Cobb is using "we" in the sense of "us down here at U Texas", he may
be perfectly correct. If he means "the computing community" he's probably
wrong, in general. While it is the case that much memory is burned
supporting multiprogramming code bloat and the GUIs of this world, there are
*lots* of applications that make profitable use of large random access data
structures; in this class I would include most of AI, all of symbolic
algebra, and many database I/O optimization strategies. In particular, for
large databases, it is often wise to go to great lengths, and consume lots of
RAM, in order to avoid retrieval "one at a time from disk".
I also think that a very general case could be made that as user interfaces
evolve, they maintain more and more state information to help minimize the
load on the user in a variety of useful ways. So bigger may in fact in
general be better...
Cheers, Tim Bray, Open Text Systems