Where should the type information be: in tags and descriptors 431

This is one of those religious arguments that are very hard to settle rationally: - the Unix-TOPS-10 argument: Every file is a binary stream (in unix it is a stream of 8-bit bytes) and any structure is entirely up to the application program to define. (MS-DOS and Windows-NT are also of this religion. - Good: File maintenance is easy. Runtime systems for sequential formatted files are simple. - Good: Low overhead, high throughput, may need fewer or no memory to memory copying. - Bad: Common data management such as ISAM indexing must be incorporated into every program that needs it. - Bad: An ISAM file cannot be edited with a text editor that does not know ISAM - Fairly optimal for "programmer workbench" environments - the IBM mainframe-VMS argument: Files are strongly typed, and come with descriptors defining their structure. All access to the file is mediated by a semi-privileged layer of record management software - Good: The actual layout of the bits on disk is separated from the programs, and the file may be physically reorganized without the program's knowledge. - Good: An ISAM file can be accessed in sequential mode by any program that knows how to work with sequential files, such as a plain text editor; when writing the file back, ISAM indexes automatically get rebuilt by the ISAM management module (RMS in VMS) - Bad: Unless byte stream is an explicity defined type, it is almost impossible to implement unix-posix semantics in this environment. For editors and other "normal" programs to be able to work with byte stream files, lots of special case code ahs to exist in the data management subsystem to convert between byte stream text files and sequential record streams. - Very important for DATA PROCESSING environments

This distinction is analogous to the difference between strongly typed languages and languages with almost no type enforcement.

Lars Poulsen