🚀 go-pugleaf

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.