From ... From: Erik Naggum Subject: Re: Rob Pike article Date: 2000/06/15 Message-ID: <3170066864060276@naggum.no>#1/1 X-Deja-AN: 634894963 References: <8i689h$iao$1@nnrp1.deja.com> <8i7sr9$1a7$1@counter.bik-gmbh.de> <8i9v6c$2la3$1@counter.bik-gmbh.de> <8iadpd$49o$1@counter.bik-gmbh.de> mail-copies-to: never Content-Type: text/plain; charset=us-ascii X-Complaints-To: newsmaster@eunet.no X-Trace: oslo-nntp.eunet.no 961078243 7185 195.0.192.66 (15 Jun 2000 14:10:43 GMT) Organization: Naggum Software; vox: +47 8800 8879; fax: +47 8800 8601; http://www.naggum.no User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.6 Mime-Version: 1.0 NNTP-Posting-Date: 15 Jun 2000 14:10:43 GMT Newsgroups: comp.lang.lisp * Tim Bradshaw | Getting rid opf the ram/disk difference is called virtual memory, I | think: kind of a solved problem. The xerox Dmachines and so on even | had the software to exploit this at the user level. I think he maans the MULTICS way to deal with disks. Not just kind of a solved problem, but kind of a not-a-desirable-solution-problem. There's another way to look at this: Opening files for reading as streams is a very serious bottleneck to the development of much more interesting ways to deal with persistent data, and I'm not talking about "persistent objects" and databases as a solution to this particular problem, but the inability to think about it when data is stored on disks that are conceptually still thought of as serial input devices because that's what they were in 1950. Streams with sequential access is OK for serial input, such as network protocols, users, and time-based data (audio, video, etc), but it is not OK for data that is mapped into memory on demand. Not just virtual memory, but the management of input sources. #:Erik -- If this is not what you expected, please alter your expectations.