🚀 go-pugleaf

In article <8315@cbnewsm.ATT.COM> mls@cbnewsm.ATT.COM (mike.siemon) writes:

>The example of reading an arbitrary file is just that, an example of a
>much larger general problem.  If I have a file I may want to use it in
>a number of different ways, totally unconstrained by the file's origin
>or by my intentions when I create the file.

[...stuff deleted...]

>But you cannot specify an arbitary file and an arbitrary application TOGETHER.
>A new application may know all sorts of neat conversions to operate on
>earlier kinds of output; the older applications are then practically
>guaranteed to be unable to cope with the output of the new one.

We seem to have another religious war heating up here.  This real issue
seems to be "Should operating systems do typechecking (between files and
applications?)"

This is analogous to the Pascal vs. C religious war about typechecking.
Some people hate Pascal because it "forces" you to feed the right type of
data to an operation, whereas C "liberates" you by allowing you to feed
data of any type to an operation (whether it makes sense to do so or not).
Others love Pascal because it prevents you from making the mistake of
feeding bad data to an operation, thereby saving you long hours trying to
track down insidious bugs.  These people hate C because it's too easy to
write programs that contain undiscovered mistakes.

The same arguments hold about Mac vs Unix/MSDOS applications and files; just
substitute the word "application" for "operation" and "file" for "data."
Unix is like C; it lets you feed any file (a typeless stream of bytes) into
any application, whether it makes sense to do so or not.  (Liberating?  
Dangerous?)  The Mac associates a type with each file, "forcing" you to only
feed files of the right type to a program prepared to handle it.  (Safer?
Too restrictive?)  The same arguments apply in both religious wars.

Sure, it's nice to have the flexibility in a Unix-like system to process
textfiles in virtually any program, but one penalty is that every program
has to start with data that's in least-common-denominator form (raw text).

One advantage of file types is that Mac applications can work with fancy
file formats (TIFF, NFNT, whatever) without having to convert to/from a
lowest-common-denominator raw text stream each time, and users are protected
from accidentally doing unnerving things like displaying binary object code
on the screen (I think everyone's done that at least once on Unix using
"cat"!).

A disadvantage of special file types is that they make it hard to write
general-purpose utilities that can be pipelined together in flexible ways
(i.e., forming bigger tools out of several little ones).  That's why many
Mac programs tend to be large, "try to do it all" programs rather than
small, single-purpose utilities.

The overall problem is being (partly) solved in the programming-languages
world by object-oriented, hierarchical type systems which "factor out" the
common characteristics of different data objects.  That way, an operation
can be applied to any data item that is of a certain type OR ANY SUBTYPE OF
IT.  If the Finder had that capability, it would be possible tell it that
a TEXT file is a subtype of the file formats used by Microsoft Word,
MacWrite, WordPerfect, etc.  Then when you double-clicked on a TEXT file,
the Finder would know that any of those word processors could be launched
safely.  (Perhaps a list of word processing applications would pop up,
allowing you to pick your favorite.)

Distributing a simple text program with the OS (like TeachText is) would
then guarantee that SOMETHING useful would get launched, which I think is
where this whole discussion about "text file madness" got started.

I hope this armchair analysis heads off WFW III (World Flame War III ;^).

--
-------------------------------------------------------------
Email:    tonyrich@titanic.cs.wisc.edu    Phone: 608-271-8450
US mail:  Tony Rich, 4321 Sentinel Pass, Madison, WI 53711
-------------------------------------------------------------