[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]

:zz,skx,virt: "Re: oooo...kay



Hidey Ho,

>Maybe: Zigzag is sort of like a database file, in having fields, and a
>spreadsheet, having cells, but instead of having records or pages of cells,
>it's more like the loose fields are linked in amost any way one could
>possibly (logically) link them. 

PERFECTLY EXPRESSED!

Let's go back a little way.  People think the concepts of
 "database" and "spreadsheet" are well defined, and so
 this must be some kind of a hybrid.  That's exactly backward
 from my point of view.

"Computer basics" are all lies.  Not in the sense that they
 deal with the world as it is: files (named lumps with changeable
 contents), hierarchical directories, "applications," and
 WP DB & spreadsheet as our friendly Scarecrow, Cowardly Lion
 and Tin Woodman of familiar structures.  

Yes this is the world as it is.  NO, THIS IS NOT HOW
 COMPUTERS "REALLY" WORK!  Computers deal with
 ARBITRARY CONSTRUCTS-- and the step-by-step
 pursuit of the seemingly reasonable has played itself out
 (both senses) into these familiar constructs.  Simple ideas
 have lead to unspeakable complication.

Example: word processing, a geek's notion of what writers
 want.  Assumes that the objective is a sequential package
 of text with no connection to other packages of text,
 no need to maintain connections, versions, etc.-- "That's
 too difficult," "Why would you want that?" or my favorite,
 "This forces the user to be disciplined."

But the principal issue of creative work is version management
 (including parts management-- e.g., "where did I say that
 in version B?")-- and by ignoring these issues in the software
 the geek merely PUSHES THE PROBLEM OUT INTO
 THE USER'S LAP, a bagful of fighting cats.  Where it is invisible
 to the perpetrator.  And the poor user, having been told in
 no uncertain terms that this is the wave of the future, deals with
 the problem as best he can.  Like me (and lawyers I know)
 keeping tens and forties of back drafts, but with no clear trail
 of where the pieces are.

This is just one example, but a very important one to me.

So my first article, 1965, was about how a proper text system
 would keep the parts linked between versions (among other
 properties), and nobody understood it.  That structure was
 called "zipper lists".  Not implemented until December 1995,
 Sapporo Japan (and that implementation rather unusable due
 to complexities of the implementation environment).  

Okay, now let's switch to operating systems.

An operating system is an environment in which computer stuff
 happens.  

By TRADITION, it deals with "files" (big named data lumps,
 remember), in hierarchical arrangements of names, and the
 connections among files and among directories, and between
 files and directories, are handled in general by text strings
 agglomerated into files.

What's wrong with this?

1.  The "file" is too big a unit.  You want to go down to the
 "item," of which things like texts and spreadsheets are made.

2.  The operating system should have "connection" as a
 primitive.  So that as you move things around your world,
 the connections are automatically maintained with some
 richness (i.e., all references are correctly resolved despite
 changes).

 And so that today's world of "files" and "metadata" is
 broken up into something much richer.  Today, the "file"
 (lump of stuff) has a number of pieces of metadata:
 name, location, aliases, date of last change, length.  But
 where do you put the "comment"?  Or the "disagreement"?
 Or the "intended use"?  Answer: in dingbat adaptations
 such as the "read.me" file and the note taped to the console. 
 If the operating system had connection as a primitive,
 all this would be right there automatically.

3.  Hierarchies are generally spurious as mappings of reality
 (biology the interesting exception), and destructive as mappings
 of computer work-- consider all the "aliases" and "shortcuts"
 that are used to get around it, but all at the BIG-LUMP LEVEL
 (files).  

 The alternative to hierarchy: FINE-GRAIN TRANSCLUSION,
 meaning that small things can be in many collections and contexts,
 and you can see sideways among the small things to all the
 contexts they're in.  I write about this everywhere (but it's
 taking me a long time to make the stuff available, unforch).

WHERE ALL THIS LEADS:  For the OPERATING SYSTEM
 ITSELF, we need a CLEAN, CONSISTENT, PRINCIPLED
 ENVIRONMENT with FINE-GRAIN STABLE CONNECTIONS
 AMONG SMALL OBJECTS, with transclusion.

What else do we need?  

Specific functions.

So ZigZag is a highly principled environment that
 does all that and can be extended with specific
 functions.

Data and programs are all cells which you may
 scramble as you wish.

>If you want to make a computer do some job, you're pretty much stuck with
>an "application", aren't you?

No.

The term "application" as presently used really means an
 ACTIVITY TRAP, an oversized bloated environment
 which has been made much to big to put on floppies,
 with some data structure the manufacturer wants to trap
 your data in (AutoCAD, Microsoft Word, Photoshop, etc.)
 and only poor channels to other "applications" (export,
 import-- "you may lose some information", heh heh).

In the ZigZag model you will not open an application;
 you will use cells with different functions (which you
 may have bought as an "application cluster", separate
 cells which may work with each other or with cells
 you have already.

Example: you buy a Photoshop-like application cluster,
 you get a Canvas Cell, a Brush Cell, Color Selector
 Cell, and use them together or in other contexts.

'Nuff for now, T


At 04:13 AM 6/20/98 -0400, you wrote:
>
>Ted,
>
>Maybe I should just shut up and wait for the docs. Maybe I haven't earned
>the right to talk to the heavy minds at the cutting edge. If you are going
>to strike off so many sparks, you are going to have to put up with the
>occasional novice who knows it ain't nothing but backbreaking work,
>catching a fire. I presume to send this along, aware as I am of the gap
>between our respective understandings. I have a similar gap to deal with,
>and in my case, my job is to maintain that gap. So I know better than to
>try to catch up to you. But you have purturbed me greatly, and now, you
>shameless tease, you tell me to wait for the docs. I'm a Barus, dammit.
>I've never pulled that one before, but I've gotta know. You're the fucker
>who first showed me a banjo, resulting in a thirty-year journey (is yours
>in tune?). That ought to count for something. Ok, I'm sorry I got excited.
>Just deal with it. I'll try to sit on it after this.
>
>Here is my little kindergarten system I built all by myself. It makes my
>living in an earlier version. I call this a hierarchic RDBMS, or "HRDBMS".
>It uses a very good, but conventional, runtime system. It's a generic
>application framework. It could be programmed in a variety of systems, I
>just used what I had. Of course I'm limited to a record-based paradigm. It
>provides a user with the ability to dump lists of stuff into it, and
>organize them "instantly" into relational databases; and then, to link
>these RD's in subsidiary chains, or a tree or root system. Using a bike
>shop for an example:
>
>(Bikes Database)---------------------------------------
> |                                                     (Labor Database)
> |                                                      |
> Best Bicycle                                           Assemble Bike
> |    |  |    |                                         Tune-up
> |    |  |    |                                         fancy paint job
> |    |  |  (Wheels Database)
> |    |  |        |
> |    |  |        fancy wheel
> |    |  |
> |    |  (Brakes Database)
> |    |       |
> |    |       fancy brake------------------------------
> |    |                  |                            (Cables Database)
> |    |                  |                             |
> |    |                (brake pads Database)          expensive cable
> |    |                  |
> |    |                  expensive brake shoe
> |    |      
> |    (Frames Database)------
> |      |       |           (Front Forks Database)-------(Labor Database)
> |      |       |                 |                         |      
> |      |       |                 |                         adjust front
>fork
> |      |       |                 really cool front fork
> |      |       |             
> |      |   (Handlebars Database)
> |      |          |
> |      |          fancy handlebar 
> |      |
> |      fancy frame
> |          |
> |       (Labor Database)  
> |          |
> |          assemble frame
> |      
> Mediocre Bicycle 
> |       |    |
> |       |  (Wheels Database)
> |       |        |
> |       |        cheap wheels
> |       |
> |      (Brakes Database)
> |           |
> |           cheap brakes
> |      
> Etc.
>
>This kind of thing is probably old hat. I built this because I desperately
>needed one, and couldn't get one. Otherwise I'd still be a craftsman,
>whittling things. You can't whittle in an information age, without a CAD
>system. My first attempts used spreadsheets, but they were limited, maybe
>just by the programming interface. This one manages many-to-one-to-many
>relationships using a minimum of three files, one of which just maintains
>all the links. I could not sell an abstraction, but this prices things that
>couldn't be priced before, and damn quick, which makes it a golden egg.
>
>Maybe: Zigzag is sort of like a database file, in having fields, and a
>spreadsheet, having cells, but instead of having records or pages of cells,
>it's more like the loose fields are linked in amost any way one could
>possibly (logically) link them. So if that's the case, a "record" could be
>a set of fields with something in common; but those fields might also be
>part of a "record" from a whole different angle. Sort of like, if I build a
>matrix based on a cube, and sink it about halfway into a pool of water,
>then the surface of the water defines the current view of the contents.
>Roll the thing over, or sink it deeper, or just tilt it, and you get a
>whole different set of fields. Don't start with me, now, I don't wanna hear
>about making waves in the water, or doing it in zero gravity. I'm just a
>whitebelt at this stuff.
>
>Is anything in this at all related to zigzag (if so, what?) I'm just going
>on what I've downloaded. I can't see bloody much in the demo so far. Do any
>of the commands work? Is there a version that's loaded with anything
>familiar?
>
>What does zigzag need?
>
>If you want to make a computer do some job, you're pretty much stuck with
>an "application", aren't you?
>
>Are you interested in the problem of the triumph of mediocrity, and how
>this affects the birthing of zigzag? (I know: not if I have to use
>words...<g>)
>
>I still haven't heard from you, whether you ever ran across this
>Giambattista Vico?
>
>Peter
>
>
>
________________________________________________________
Theodor Holm Nelson, Visiting Professor of Environmental Information
 Keio University, Shonan Fujisawa Campus, Fujisawa, Japan
http://www.sfc.keio.ac.jp/~ted/    PERMANENT E-MAIL: ted@xxxxxxxxxx
 Home Fax: 0466-46-7368  From USA: 011-81-466-46-7368
_________________________________________________________
Project Xanadu (Permanent)
 3020 Bridgeway #295, Sausalito CA 94965
 Tel. 415/ 331-4422, fax 415/ 332-0136
http://www.xanadu.net
_________________________________________________________
Quotation of the day:
"Education is the process of ruining different subjects for you.  The last
subject to be ruined determines your profession."  Ted Nelson, ca. 1970.