Path: utzoo!attcan!uunet!philmtl!philabs!linus!mbunix!eachus From: eachus@mbunix.mitre.org (Robert Eachus) Newsgroups: comp.sys.amiga.tech Subject: Re: Why do you need metaphor? (Re: What should be learned from Unix Summary: Those who forget history are condemned to repeat it... Keywords: Multics, Unix, Bell Labs Message-ID: <64502@linus.UUCP> Date: 21 Aug 89 23:14:09 GMT References: <7570@cbmvax.UUCP> <440@xdos.UUCP> <1417@bnr-fos.UUCP> <13207@well.UUCP> Sender: news@linus.UUCP Reply-To: eachus@mbunix.mitre.org (Robert I. Eachus) Organization: The MITRE Corporation, Bedford, Mass. Lines: 105 In article <13207@well.UUCP> xanthian@well.UUCP (Kent Paul Dolan) writes: >If you go back and look at the '60's operating systems (OS 360, GCOS, etc.), >you find that the OS was responsible for knowing the structure of the >bytes in a file. The result was the JCL nightmares of fixed, varying, varying >spanned, and so on record structures, each of which was built into the OS, >and all of which had to be describable by the system user in JCL. >The glory of Unix is the realization that the OS has no business knowing the >internal structure of a file; a file is just a stream of bytes. It is the >responsibility of the program accessing those bytes to interpret some >structure into them.... If the idea of "unstructured" files came originally from Unix, or if the reason that Unix originally treated files the way it does had anything to do with your reasons, or if the files in Unix were "just a stream of bytes", I probably wouldn't have commented. But...THAT ISN'T THE WAY IT HAPPENED, THAT ISN'T WHY IT HAPPENDED, and finally THAT ISN'T WHAT FILES ARE IN UNIX! Please don't rewrite history, especially where it is important like here! Unix was written to be a small single user system by people who had been part of the Multics effort before Bell Labs pulled out. One of the key principles of Multics was that there was no distinction between disk (or originally drum) files and main memory (back then core). Dynamic linking, segment tables, snapping of links, packed pointers and unpacked pointers, and a hierarchical memory structure were all tools devloped to make that user abstraction work. (There were other principles, and other innovations to support them, involved in the design of Multics, but that is another story.) Multics users (and at that time all such users were developers) quickly became used to the programming paradigm that the way to change a file was to operate on it in random access fashion, in memory. The fact that Multics used demand paged virtual memory to make that efficient in all cases was hidden. (Maybe that wasn't entirely another story. :-) The developers of Unix wanted to work in the same fashion, and having internal structure to files was an unnecessary nuisance. So the file system was designed so that the internal structure of files was hidden from the users. (But files had structure, and programmers needed to understand it, unlike on Multics.) The "new" file system had different structure, and it is what Unix systems commonly use today, but boy was it a porting nightmare. Note that Multics files have structure normally (very well) hidden from the user, Unix files also have a hidden (but not so well originally) structure, and AmigaDOS learned the lesson well. (So well, in fact that I can't remember ANY tools, programs, or files which wouldn't work with the 1.0 files system, the Old File System, and the Fast File System. (The incorrect reporting of file sizes in earlier releases of info and list to my mind was a bug.) There is good documentation for how all of those file systems work, and if you really believe that those file systems are unstructured, go read it! >Somewhere in there, the idea of bundling the process and its data became >the concept of an abstract data type so dear to the object oriented >programmers of today. Huh? There are lots of definitions of abstract data types floating around, so someone, somewhere, must have proposed one like yours, but you missed the mark again. The idea of an abstract data type is to combine the definition of the type with the operations on the type, so that the details are hidden from the user. That is a good fit with modern file systems. >Not too scruffy from a beginning of "keep it simple, stupid." ;-) This is a real insult, however you are probably, based on the above comments, unaware of just how insulting it is. There are SHELVES of papers, almost all of which make interesting reading today, on the design details you dismiss so glibly. Making these things have a simple appearing paradigm, and what that paradigm should be, were a decade of labor for hundreds of people who thought that there was a better model of computer human interaction than was embodied in the early 360's. (Note that I probably should have said IBM 704, but the IBM 704 was the ancestor of the 7094, which was the predecessor of the GE 635... The announcement of the 360 series was the step that caused MIT to turn to GE for the processor to run Multics, but I digress.) Minicomputers, and CRT terminals, and interactive computing, and the box that you have on your desk were the product of a lot of visionary people who saw how good it could be, and spent years in the wilderness making it happen. Some eventually got rich, but a lot of people who could have deserted the cause, stuck through good times and bad, to the idea that batch processing on mainframes was NOT the way to use computers. The first computer I programmed was an IBM 650. I still have a copy of the first assembler manual at home (GP for the Univac I). I played Spacewar on the PDP-1 and MIT in 1964. I worked on debugging the first time sharing systems. WHERE WERE YOU? Robert I. Eachus with STANDARD_DISCLAIMER; use STANDARD_DISCLAIMER; function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is... If thare are people who want to reminisce about the old days, I'd love to, but lets keep it to e-mail. I only posted this because I don't want young programmers kept in the dark. Santayanna, got it right, and I remember seeing a column (in Datamation I think, eight or ten years ago when it was still worth reading) about visiting a microcomputer show in the Z80 days, and recognizing a lot of the old mistakes being repeated.