Two complementary views of the system.

[Tril]

On Sun, 27 Dec 1998, RE01 Rice Brian T. EM2 wrote:

> Wow!  I can't disagree with anything here.  :)
> Naturally, I'd like to shamelessly plug my Arrow system, and add some
> comments, if you don't mind.  ;)
of course!

> > 4. There are multiple views on the same system or parts of the system. 
> > The system automatically translates between views for the user's
> > convenience.  It keeps track of what structures are equivalent in
> > different views, so if the user changes something in one view, the
> > corresponding change can be made in the other views.  Views include things
> > like user interface (graphical and textual), as well as paradigms of
> > objects, such as functional, procedural, and declarative. 
> > 
> Maybe the user would also want 'static'-style views where each incremental
> addition would be shown as built 'on top of' the viewed system, so that the
> user can compare.  This would just be a feature of the development tools, of
> course, since the system would be able to encapsulate reversibility of
> information-update actions, and so it could reconstruct previous states if
> it kept track of changes.  You also have the potentially non-intuitive
> effect of having all the tools that you are using change inadvertently due
> to some user-tinkering.  I'm just trying to illustrate the fact that the
> understandability of this system may be one of our highest standards /
> goals.

It's a feature of the versioning/module system... and I'm very aware of
the confusion possible from automatic updating of information.  I think
the user's ability to view any information flow (and customize the output
format), as well as slow it down to viewable speeds, and interact with it,
should help tihs a lot.

Also, there will be (some number of) levels of "difficulty";  at novice
(lowest)  the user will be prompted for confirmation of almost anytihng;
at expert (highest) there may be no confirmation at all.  Of course the
difficulty levels are completely configurable; I expect everyone to have
their own personal one.

> > 5. It is a goal to include rudimentary natural language support from the
> > beginning.
> > 
> The interface that you're talking about doesn't exist yet, and probably
> needs a system like ours to become reality before someone makes a far less
> efficient version for traditional systems.

I don't think it will be that hard.  I'd like to pursue the NL aspect of
the system.  I have a good idea of how to do it (in my system model, at
least).  I took an introductory linguistics class and I'm taking a syntax
class starting next week.

I especially think the adding of terminology to objects from the
beginning, even if nl doesn't work right away, will help... the terms can
be used for human-readable documentation in the meantime (and interfacing
to various programming languages that link by name).

> > More extensive natural language support requires an enormous lexicon of
> > the words in the
> > human language, and will be developed later with an online distributed
> > database. 
> > 
> I'm inclined to think that we could achieve an information density that
> would allow that database to be a lot smaller than you think.  Of course,
> we're not ready to build that yet, but we should get there in the
> development process.  We should also consider the possibility that
> (eventually) the system may diverge for many different groups, while still
> remaining Tunes.  This of course smacks of the theory of natural selection.
> We could also attract the attention of some linguists to help out.

If tunes diverges, the splinters must remain compatible.
Of course it will diverge. ... It may not even ever converge!
I resist asking for help until I need it.  But sure I'd ask linguists in
my own university first.

> > 6. The system is integrated.  This means every application is part of the
> > system.  Also, applications are developed at a much finer grain than in
> > traditional systems.  Any functionality, once added, is available
> > everywhere in the system.  Users will be able to combine different
> > functionality to create custom environments.  [this section needs to be
> > developed]
> > 
> Incremental development suggests that combination of functionality would be
> transparent to the user.  I guess that the direction for elaboration would
> be in differentiating between various types of 'combinations' of
> functionality.

ok, thanks.

> > 7. infinite customizability, automation, ...
> > 
> I couldn't agree more.  Maybe you should add on something about factoring
> out code by the user or something, since we seem to be headed towards an
> aspect-orientation.  This suggests that we provide tools for doing this.

Everything is already factored.  That's how my system design works- all
aspects of abstractions are factored out, to the finest grain possible.
Factoring is done by humans, when they create objects.  Within the system,
most activities involve exploring objects, and drawing relationships
between aspects.  ...Does this make any sense?  Probably not.  I'm working
on it.

> > Developer's view.
> > 
> > 1. ...When the very high level language is not enough, developers write
> > documentation and attach it to their specifications.  The documentation is
> > meant to stay with the specification as long as it lasts. 
> > 
> But with incremental development, won't documentation be changed as well?
> Would we have to develop a Linux-style log system of changes?  Since the
> incremental development can be performed in 'many dimensions', so to speak,
> how would the documentation be kept consistent?  Someone could always
> re-interpret the meaning of the specification, no matter how high-level,
> into some previously unused context.  Maybe if we could achieve some sort of
> 'totality' in knowledge-level reflection, but that seems far too lofty a
> goal.  I'm not exactly sure that even the Arrow language could handle it.

The documentation is attached to the objects it documents.  It is good
style to update the document at the same time as you update the objects.
Hopefully it will be easier to keep documentation up-to-date than in
current systems.

> > 2. interactive development ...
> > 3. hyper-programming, programming adding inherently to the deduction
> > system ...
> > 
> Cool!  I hope that the Arrow system turns out to fulfill those expectations.
> That's certainly what I'm planning on.
let's hope so.

David Manifold <dem@tunes.org>
This message is placed in the public domain.