Your post seems to imply that these are two different things; I think
they are simply directions on a continuum. When your documents become
sophisticated enough to explain to computers how to do things -- for
example, documents in certain formal software-verification systems
containing symbolic logic, or Mathematica notebooks -- they have become
as powerful as programs, and when programs explain what to do, rather
than how to do it, they have become declarative -- and thus documents?
I'm not sure this preserves the durability and accessibility difference
you describe below, though. I think the essential difference is that
information that is mostly self-contained, requiring only a little bit
of external information to interpret in a meaningful way -- or requiring
more-commonly-available external information -- is likely to be much
more durable and accessible.
> . . . in general documents are easier to decode than software. . . .
> Once you get past the "how do I read x inch mangetic tape" problem,
> chances are that you can extraxt the content of [a 30-year-old] text
> file with a few lines of perl.
Suppose you have a hard disk instead of a magtape, and the hard disk's
control mechanisms are kaput. Then, in order to read this 30-year-old
text file (in 2028, say), you must figure out the following:
- how are the 1's and 0's written to the disk? Generally there's some
sort of encoding that prevents long runs of the same magnetic
direction from being written to disk (because that would make the
drive electronics lose synchronization with the disk), of which
RLL is the simplest, and there are various more-recent more-complex
- where are the tracks, the sectors, etc? (This is also encoded somewhere
on the disk, but you have to figure out where.)
- how did the disk controller map those things to logical block numbers?
- what filesystem is the disk formatted with?
- what character set is the file in? Is it gzipped, compressed, zipped,
RARred, ARJed, LZHed, compressed with some more arcane format?
Once you get through all of these, it should probably take a few lines
Documents can be very difficult to extract, too.
The primary distinction is not whether something is imperative or
declarative, but rather how complex and arcane the knowledge to decode
it into a usable form is. Computer programs inherently require more
complex and arcane mechanisms to decode them than text does; decoding text need
only create a short sequence of characters, while decoding a computer program
requires the ability to do all kinds of things, from simple arithmetic to
storing large volumes of information and retrieving it quickly.
> The hardware is dead and emulaters only work for games.
> If you want to keep information unlocked for future generations, don't
> put in into software.
Depends on the information. If you want to describe a nifty method of
solving the eight-queens problem, you'd probably be better off describing
it in LISP or the lambda-calculus than in HTML -- simply because the
latter lacks the semantic depth to express it correctly.
But in general, I definitely agree with you. Use widely-understood
> Use HTML whenever you can -- it has established unprecedented global
> semantics which computers can read 50 years from now.
I suspect you are correct -- and even if you're not, it should be pretty
easy to understand HTML even without a Web browser.
-- <email@example.com> Kragen Sitaker <http://www.pobox.com/~kragen/> I don't do .INI, .BAT, .DLL or .SYS files. I don't assign apps to files. I don't configure peripherals or networks before using them. I have a computer to do all that. I have a Macintosh, not a hobby. -- Fritz Anderson