Two complementary views of the system.

[Tril]

Here's a try at describing the overall system, organized around the two
points of view (which overlap), user and programmer.  I know most of this
stuff has been discussed before, but hopefully this is clearer (but by no
means complete). ...


==========================
User's view.

1. The system is open, the user can view every thing.  The system opens
itself up for exploration.  Objects in the system are simple, intuitive,
and documented.  The purpose of this is for the user to be able to
understand his or her system by browsing around it. 

2. The system is dynamic, the user can change every thing.  The system
provides tools for interacting with every part, changing it, by replacing
components with equivalent ones.  The user can also remove any part of the
system that he or she doesn't want. 

3. The system keeps track of dependencies between parts.  So, when the
user is viewing their system, they can see what objects depend on what
others, and move between them.  When changing the system, the changes
propagate from one object to another, and the user can view the flow of
information. 

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. 

5. It is a goal to include rudimentary natural language support from the
beginning.  The user will be able to communicate to the system, and
receive information from the system, in their native language, to some
degree.  The degree this will likely be supported is: the system will
understand basic grammar, and will know words for all the objects in the
system.  The user will be able to ask questions and give commands relating
to the objects in the system using natural language.  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. 

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]

7. Everything is infinitely customizable.  The user can change settings
for resource allocation, optimization constraints, hardware access, and
can choose exactly what objects are in the system and which aren't.  The
user decides what actions will be automatic, and which will be done
manually.  The user can decide which tools are interpreted and which are
compiled.  The user can specify global preferences in areas of system
performance, such as SPEED and SPACE.  The user decides how strictly
access will be restricted.  The user controls each and every 1 and 0 that
goes in or out of the system and what happens to it while it is there. 
The user controls what questions the system asks about configuration.  And
the user can specify a program to take the place of the user in deciding
any of the above options.  The user does not need to make use of this
power at all.  If the user does not exercise control over the inner
workings of the system, the system will provide adequate defaults.  The
user can change the workings on a situation by situation basis.  The
"Control Panel" isn't isolated, but is just one view on everything.  It
doesn't require extra coding on the programmer's part to add configuration
to a module.  Code by its nature restricts configuration.  Instead of
adding configuration the programmer LEAVES CODE OUT.  Anything left out is
configurable.  In the end, all programs are just user configuration
options.  This is because configuration is going in and changing code. 
All code can be changed. 

8. Parallel distributed processing: not much more needs to be said.  This
is the direction all systems are going. 

Developer's view.

1. Tools are provided to design modules in a user-oriented way. 
Programmers construct generic tools.  Sets of related tools are grouped
together in modules.  The generic tools are designed in a very high level
language.  "Code" is not an accurate description, so "Specification" is
used instead.  Specifications are simple and easy to understand (because
they are so high level).  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. 

2. The system is an assistant to the programmer in writing tools. 
Edit-time type checking is done as much as possible.  Interactive
debugging will be utilized to a great extent.  Programs will be proved
when possible, using logic to verify consistency.  First the programmer
writes a specification: defines the problem, usually consisting of some
input, and some transformation to reach some output or desired state from
the input.  Then the programmer proceeds to find ways to implement this
specification, using tools already available in the system.  The system
assists in implementing the specification as much as possible.  The final
goal is for the system to be able to implement specifications itself with
no help from the programmer.  This goal will be gradually reached because
programmers will add to the system's deduction abilities as they program. 

3. Specifications are not written in a textual, syntactic file-based form. 
Instead, they are produced interactively by "hyperprogramming:" directly
linking persistent objects.  This direct linking will contribute to the
ability to develop generic tools, because programs can be connected with
related programs.  An example of two related programs are programs that
perform conceptually similar actions on different sets of data.  The goal
is that when the user wants to do something, the system can have a group
of related tools available to present the user a choice from.  The
integrated development tools (which are intended to be used by ordinary
users, so are hoped to be included in every distribution) assist the
programmer to contribute to a single, integrated system. 

4. Integrated distributed networking, together with an advanced versioning
system, and module system, allows multiple developers to collaborate. 
Hopefully the simplicity of the system and the ease with which changes can
be made will allow ordinary users to contribute more actively with the
bazaar development model.  The goal is to eliminate the difference between
ordinary users and elite programmers and system designers. 


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