[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Applitude connectivity, was: Re: Spaceparts vs. first-class structures, was: Re: [Gzz] Summing up...
- To: Tuomas Lukka <lukka@xxxxxxxxxx>, zzdev <zzdev@xxxxxxxxxx>
- Subject: Applitude connectivity, was: Re: Spaceparts vs. first-class structures, was: Re: [Gzz] Summing up...
- From: Benja Fallenstein <b.fallenstein@xxxxxx>
- Date: Sun, 06 Oct 2002 02:09:10 +0200
- Cc: gzz developers list <gzz-dev@xxxxxxxxxxxxxxxxxxxxxxxxx>
- References: <20021005074638.GA29712@xxxxxxxxxxxxxxxx> <3D9EB840.800@xxxxxx> <20021005103400.GA1203@xxxxxxxxxxxxxxxx> <3D9EC1BB.30005@xxxxxx> <20021005105238.GC1203@xxxxxxxxxxxxxxxx> <3D9EC55B.4070202@xxxxxx> <20021005122039.GD1203@xxxxxxxxxxxxxxxx> <3D9EDC6A.9010100@xxxxxx> <20021005144951.GH1203@xxxxxxxxxxxxxxxx> <3D9F070D.40101@xxxxxx> <20021005183705.GJ1203@xxxxxxxxxxxxxxxx>
Tuomas Lukka wrote:
On Sat, Oct 05, 2002 at 05:36:45PM +0200, Benja Fallenstein wrote:
Ok, this is a more fundamental issue.
Definitely. Note, of course, that I'm really undecided on this issue
and therefore am playing the devil's advocate.
Ok. Sounds like this could become a really useful debate :-) (note to
everybody: that was a cue for you to participate :) )
I know. This is why we need to consider the alternatives carefully.
Some ZZ structures which are interpreted by a program seem to be
fragile, and sometimes difficult to change with the general
What exactly are you refering to? And why difficult to change?
Putting each character in its own cell (the vstreamdim approach) was a
big mistake because the optimizations intended to make it work never
worked correctly. But that doesn't seem to be what you're refering to.
What is it?
Basically, any interaction between two structure. Can we really have
a situation where different applitudes' data shares cells and have it
I'd really love it if you can convince me on this.
Ok, now I understand better. Let me see. (I had to think about this for
Let's assume we have:
- an IDE that allows structuring code in interesting ways, allowing
connection of methods etc.
- a task planning tool like Ted has been talking about: lists of tasks
with dependencies and a "now line" that seperates what's done from
what's next and after.
- an email client.
- a scheduler.
- an annoying daemon that alerts the user on appointments.
All of these have been developed independently, but the scheduler, the
email client and the appointment daemon have agreed on a common format
for representing dates. Unfortunately, though, the scheduler and the
daemon use different structures for representing appointments (there has
not been coordination, as there cannot always be). Everything is
programmed in a modular fashion. Also, all the applitudes have been
designed carefully so that unanticipated connections will be possible,
as far as is feasible. (We're assuming the ideal case w.r.t. the design
of the individual applitudes, but a not-quite-ideal case w.r.t. the
coordination between developers.) Now let's see what we can make of this.
We'd like to stitch these together into kind of a software project
management applitude. (Note, btw, how we *can* say we're creating a new
applitude here: the desired result is a "zone of functionality" not
walled off from the rest of the system, an activity that you might want
to do by itself for some time or that is easier to explain by itself).
We'd like to manage tasks in code development using the task planning
tool and because that tool is just about dependencies, we'd like to use
the scheduler for doing deadlines, and the appointment daemon to remind
us when a deadline for some functionality approaches. (We'll be
subverting the normal purpose of the daemon somewhat in that we'll make
it remind us days or weeks instead of minutes or hours before the
deadline. Its programmers were clever enough to make this configurable,
even though they did not think of *this* use.)
So, let's start by putting programming tasks in the task planning tool
(see btw <http://xanadu.com.au/zigzag/manual/zigzag31.gif> for a
graphical rendering of it). These are like, "Write class X," "refactor
class Y," "document package Z," "redesign aspect A of classes B,C,D" and
so forth (i.e., they're relatively close to the code). -- When creating
the tasks, we want them to show up as cells like "Refactor class Y,"
with some paragraphs of explanation below if we choose a view that shows
more of the cell. Now, of course, we want that cell to be
bidirectionally connected to the class itself. Ok, we use some general
linking mechanism. This link works as long as both cells are there-- the
task and the class; if one of them is deleted, the link doesn't work
anymore. Can this happen accidentally because of the way either
applitude treats its structure? If the task is deleted, that probably
means that the user decided it was a mistake (or that it's done, but I
for one wouldn't delete done tasks). In that case, it's fine if the link
disappears. If the class is deleted, that can mean that it's gone or
that it was renamed, BUT if the IDE application is programmed sanely it
will NOT use a different cell if the user requests renaming the class,
so let's assume it means the class is really gone. Well, duh-- the link
doesn't make much sense then either. (Neither does the task, but that's
the user's problem.) If the user splits the class in two parts, there's
also not much we can do-- if they do it by creating a new cell and
moving some of the stuff in the class there, the link will stay with the
old class, it's the user's responsibility to change it if that's the
right thing to do. All not terribly new or exciting.
So now, we have those tasks that are in a dependency structure. Each
task is a single cell, and the dep. structure is on two specific
dimensions. Now enter the scheduler. It allows us to schedule
appointments-- that is, assign dates and times to them. Each appointment
is a cell, each date/time is a cell, and they're paired along one
dimension. Date/times are connected on a long chronological line along
another dimension, and related appointments are also connected
chronologically along that dimension. (Not the best structure for this
task, probably, but I don't want to think too deeply about this now...)
The applitude features a spiral view of time, such as Ted has been
advocating as an example for non-paper design somewhere (it's a spiraled
timeline, where you can change a view parameter to set the time
corresponding to one round in the spiral-- an hour, a day, a week and so
on). On the spiral, it shows the appointment cells near the time of the
appointment. Very nice.
What we do, of course, is appointment = task in the dependency structure
(same cell). We enter the deadline for that task as the date of an
Now (assuming an advanced Gzz...) we can open two views side-by-side:
the task dependency view (possibly vanilla zz view with special
treatment of vinks, or some other more-or-less general view that fits
well with this task) and the time spiral, and toggle a view option that
helps us seeing what is what (possibly procedural textures or some form
of lines between instances of the same cell). This view can be of great
help when planning/scheduling. We can drag-and-drop tasks to different
places on the spiral to (re-)schedule them: that's a feature that the
scheduling applitude offers.
What we do *not* have is a view showing automatically when we have a
dependency conflict, i.e. scheduled a task before another task it
depends on-- this is a new view option that flows from the combination
of the two applitudes. If the user is an absolute non-programmer,
they'll live without it. If they know some programming, they should be
able to easily write a one-liner or almost-one-liner that colors a task
bright red or some such the moment a dependency is in conflict (while
dragging the task into place in the scheduling view). If we have this,
we can drop the task, having the conflict, then click on it to focus it
in the dependency view, look at the dependencies and decide whether to
reschedule them (or break the dependency relationship, if appropriate).
[As Ted says in the Floating World docs: The system does not include
these views, but functionality with which they're easily set up.]
Now note what we have archieved: now, when we look at class Y in the
IDE, we automatically see the task connected to it, and if we have a
view that shows that much focus, we also see what other tasks it depends
on and when it is expected to be done. This could be quite helpful when
reading/editing that class.
Bringing in the alert daemon, it has unfortunately a different structure
for storing the appointments: two other dimensions, one for
appointment/datetime pairs and one for connecting the appointments that
we want an alarm on. As a third cell on the rank with the
appointment/date pair, we can specify how long in advance we want to be
notified of the event. The dates are not connected.
Now there are two possibilities to combine this with the scheduler
applitude. If we know some programming, we can step into the alarm
daemon code; as it is terribly modular and the code is extremely well
designed, it's trivial to change the structure used in one central
place, so that it can use the structure of the scheduling applitude. If
we don't know programming, we can still add the deadlines in the
daemon's structure. *Because the applitudes are sharing the date cells*,
rescheduling works: the date changes, and the alarm daemon uses the same
date format and the same date cell, so everything goes fine. Breaking
the connection between date and task doesn't work out so nicely: we have
the redundant connection, so you need to break it in both dimensions, or
you'll get superfluous annoying alarms. ;-)
Finally entering the email client, I'll skip over the details, but we
- make links between the code and emails that discuss it
- set up replying to specific emails as tasks
- set up discussing specific tasks per email as dependencies of those tasks
Because we share the date format with the scheduler and alarm daemon, we
can with somewhat more effort probably also:
- use the scheduler's time spiral view to show received email
- view received emails and pending tasks on a single time spiral
- do 'reverse alarms': if I haven't replied to an email a few days after
receiving it, notify me
These may require a little programming to stitch things together.
All this isn't so terribly deep sharing of internal cells between
applitudes. The sharing is quite shallow; the 'deepest' data sharing is
the date cells, which only works because dates are stored in a
previously agreed-upon format. BUT, this *is* an example of sharing that
is both highly desirable and impossible in classical computer
environments IMHO, possible because all data is stored in zzstructure.
(In many ways, it's the unix philosophy: many small tools using a set of
simple interfaces that allow them to be combined in powerful ways.)
Certainly the project hasn't been emphasizing the point of using
structure directly enough-- there's been this bias that 'applitude'
means 'views and bindings that hide the structure.' But turning 180? and
saying that structure interpreted by programs is bad or not important is
just as wrong.
I'm not saying it's bad. I'm just afraid of all the difficulties
when there are several programs using the same cells from orthogonal
points of views.
The potential interactions between the programs are very complex
and it'd be easy to get undesirable emergent behaviour (oh, because
this applitude wanted to insert a linebreak here, it split this cell,
and because of that, this other applitude didn't see that half of the
text and the xanadu link there any more etc etc etc).
This is the one part which Ted never talks about: there are all these
clever and simple things that can be done with the structure, but once
these simple things are combined, really bad complexities can emerge.
Yes. Ok. -- I think the lessons I would draw from the thinking above are:
- We need simple and clear protocols for sharing between applitudes that
are agreed upon. The simplest of these is sharing a single cell
representing one concept in two structures-- examples: the
task/appointment of above, a person in address book and birthday book
and genealogy and email client, etc. More difficult is if the data in a
cell or plex of cells (defined by a maincell) is also shared somehow,
for example the date in the example above.
- Data sharing between applitudes isn't going to be terribly "deep" in
the sense of large and complicated data being shared, probably. It's
likely going to be mostly cells (identity of concepts) and some easy
types useful in many different contexts (such as dates). You could say
that the pattern for the latter one is: Someone defines a fundamental
structure (e.g., for representing dates), possibly as part of a larger
applitude, and other applitudes start to use the same structure when
representing the same kind of data. This isn't magic, just simple
agreement on standards, but the point is that by using zzstructure,
actually sharing these objects between applitudes is possible at a very
low level (with the result that if one applitude changes the contents of
the cell or plex of cells-- the date, here-- the change will be
reflected in the other applitude(s) using the same cell(s)).
- Combination of applitudes isn't automatic, but needs a human in the
loop who spots the possibilities for combining applitudes and carries
them out (to create a new applitude). Or, sometimes it may happen
implicitly when a human decides to use a plex created in one applitude
as data in another applitude using the same format-- again dates being
the example from above, i.e. for example cloning a date into another
applitude and having it updated when it changes in either applitude. (Of
course, again this rests on a clear and agreed-upon definition of the
semantics of the date structure and how to change it.) In any case, it's
not magic, it happens when humans do it.
- Often, combination of applitudes will involve data sharing, but at
least just as often it will not-- only making links (which is, though,
data sharing with the general-purpose link structure). Still, this works
only if the applitudes have a cell for each item that is important to a
human-- i.e., it is a property made possible by zzstructure.
Arguably, making links is making "human structure," because it doesn't
mean real cooperation between the applitudes involved. Still, even for
that, it is necessary that the data is stored in zzstructure, because
only this allows building the "human structure" of links-- zz links need
cells representing concepts (items) at their endpoints.
The idea of zzstructure is that all activities around the
computer take place in the same structure, allowing interconnections and
overlap between *everything*, human-interpreted or program-interpreted.
Exactly. My question (which I haven't been able to formulate as clearly
earlier) is whether we can handle the ensuing complexity.
After this thought experiment more strongly than before, I think that
the key is to clearly define structures used by multiple applitudes
(including what behavior is expected for changing the structure), and
then allow users to exploit the combinability of applitudes that ensues.
The users are mostly responsible for conflicts-- they should be informed
of the behavior of each applitude's bindings and have to determine
themselves whether there'll be conflicts. (Which doesn't mean that we
need good tools to recover from problems, just that it's a strong AI
task to determine whether what the user does is reasonable ;) )
Also, note again that my true views are somewhere between what you say
and what I say here; I also hope for great things but here I present
Yes, I understand completely; I've had similar thoughts. This email from
you was much of a relief from me, because your last email before that
sounded to me like, "maybe zzstructure for everything is not such a good
idea, let's keep it on the surface as an interface but store the real
data in conventional data structures," which made me go, "argh, why're
we working on this project?!?". Now I understand much better, because
I've also pondered the problem, "how can applitudes *really* work
together which are not just zz connections interpreted by humans?" (In
fact, this was the cause for my 'thing' draft >2 yrs ago, and after
Ted's reservations about it, I tried to express these concerns to him
[http://www.xanadu.com.au/mail/zzdev/msg00397.html]. Anyhow, nowadays I
would say the combinatorial approach of that idea-- build new
objects/"things" out of other ones-- isn't so great in the general case;
it's *one* thing we need, for example to embed a formula into some text
or into a figure etc., but it's not the most exciting part about zz
applitude interconnectivity. I like the thought experiment example above
better ;-) )