> > I support you basic belief: locking up information is bad. While t=
he
> > the discussion of application-specific vs. general-purpose hardwar=
e is
> > interesting in this regard, I think there is an even more importan=
t
> > axis: imperative software vs. declarative documents.
>=20
> Your post seems to imply that these are two different things; I thin=
k
> they are simply directions on a continuum. When your documents beco=
me
> 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 bec=
ome
> as powerful as programs, and when programs explain what to do, rathe=
r
> than how to do it, they have become declarative -- and thus document=
s?
True. Bits will move from one side of the fence to the other. But the
fence is distinct and it's always clear which side of the fence they
are on at any given point in time.
> 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-o=
ld
> 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 so=
me
> =09sort of encoding that prevents long runs of the same magnetic
> =09direction from being written to disk (because that would make the=
> =09drive electronics lose synchronization with the disk), of which
> =09RLL is the simplest, and there are various more-recent more-compl=
ex
> =09schemes.
> - where are the tracks, the sectors, etc? (This is also encoded som=
ewhere
> =09on the disk, but you have to figure out where.)
> - how did the disk controller map those things to logical block numb=
ers?
> - what filesystem is the disk formatted with?
> - what character set is the file in? Is it gzipped, compressed, zip=
ped,
> =09RARred, ARJed, LZHed, compressed with some more arcane format?
Yup. There are all kinds of problems and librarians of the future will
have to deal with them. For my personal archives, I have settled for
ISO 9660 CD-Rs. I think they will be readable a long time ahead --
long enough to have them transferred to the next medium. For video, I
use analog Hi8. I don't trust digital tapes (Exabyte having failed
once too many) and storing the master copy on CD-ROM isn't feasible.
(DV is around 25Mbit/s which would yield less than 5 minutes footage
on a CD-ROM.)=20
What do other forkers use?
> The primary distinction is not whether something is imperative or
> declarative, but rather how complex and arcane the knowledge to deco=
de
> it into a usable form is. Computer programs inherently require more=
> complex and arcane mechanisms to decode them than text does; decodin=
g text need
> only create a short sequence of characters, while decoding a compute=
r program=20
> requires the ability to do all kinds of things, from simple arithmet=
ic to
> storing large volumes of information and retrieving it quickly.
Decoding a computer program requires that you execute it. Setting up
an environment for execution is magnitudes more complex than reading
declarative data, and the difference will only increase as time goes
by. Also, some things are impossible to to with imperative formats.
Dan Connolly has written an essay about unconvertable document formats
[1], from which I quote:
I conjecture that it is impossible to write a program that will
extract the third word from a TeX document. It would be an easy task
for 80% of the TeX documents out there -- just skip over some
formatting stuff and grab the third bunch of characters surrounded by=
whitespace. But that "formatting stuff" might be a program that
generates 100 words from the hypenation dictionary. So the simple
lexical scan of the TeX source would find a word that is not third
word of the document when printed.
[1] http://www.w3.org/MarkUp/html-spec/html-essay.html
-h&kon
H =E5 k o n W i u m L i e
howcome@w3.org http://www.w3.org/people/howcome
World W i d e Web Consortium