TUNES: Making computers so easy even your dog can understand them...

[David Manifold]

On Mon, 22 Jun 1998, Ashley Winters wrote:

> > People don't naturally think in lines.  Tunes is
> > supposed to be easier to use because it mimics the way people really
> > think. 
> 
> Easier to use? Probably not in the down-to-earth sense. Perhaps it will
> be easier to express your desires, therefore making it easier to get
> something done. But will it *really* be easier to use than something like 
> MacOS?

Yes, it will, because being easy to use is part of the specification.
That means Tunes won't be done until it's easy to use.  Squeak
(http://squeak.cs.uiuc.edu) is claimed to be "...a practical Smalltalk in
which a researcher, professor, or motivated student can examine source
code for every part of the system..."  Tunes needs to go beyond that.
In Tunes, a child, a computer novice, or YOUR DOG should be able to
examine source code for every part of the system.

> One of the goals of Tunes, as I understand it, is to promote computing
> Freedom, part of which means freeing the world from the computing caste
> system that exists today; Users and Programmers. Everyone is a
> Programmer in Tunes, and the degrees of experience are all that 
> distinguish a user. The product of experience is distributed for the
> benefit of all.

I think some people have the mistaken impression that if there is no
difference to the system between a user and programmer, that everyone will
immediately start developing their own modules to share with others.  I
still think it is perfectly valid for many, if not most, people to use
software modules developed by others.  There will be modules that are
designed for people who have no interest in tweaking the system.  Maybe
your computer treats a mouse movement the same way it treats a perl 
script, but that doesn't mean humans are expected to.


> Apart from the "You can setup your system however you want" argument, a
> question is raised as to how a power-user will setup their system to meet
> their needs. Tunes will probably be distributed in a form about as usable
> as today's best designed programs. However, that does not provide any
> advantage over the current standard.
> 
> Tunes will be harder to use in the sense that in order to get the best out
> of it, the user will have to do more. With shrink-wrapped Micro$oftware,
> the program is as good when you install it as it will ever get. It's
> pointless for anyone to discover or understand what makes it work, or how
> to make it better, because they can't. That saves time in the short-term.
> 
> In the long-term, Tunes will end up being more useful, and easier to use
> once it's understood and setup. The "You can set it up however you want"
> invites users not to embark up the Tunes learning-curve, instead relying
> on a distribution setup in a generic way which they will never modify.

On the contrary, I think there will be a broad range of default setups
that are each easy to use, and yet customized for different users' needs. 
In addition, I think the system will be inherently easier to use, simply
because of its high level.  Being very high level means essentially that
the system is self-documenting, or written in native pseudocode.  There is
a game for Apple II called Rocky's Adventure or something like that, where
you build electronic circuits out of AND, OR, and NOT gates.  It's for
kids.  It has animals in it.  But you learn computers interactively.  The
entire Tunes system will be based on this paradigm.  Another one is Robot
Odyssey.  In it, you not only construct circuits, you can place them
inside a chip and use that chip in other circuits-- to an infinite nesting
depth.  When you're done constructing a robot, you watch it walk around
and bump into walls.  What if your entire system were like that?  It
wouldn't just be EASY to use, it would be FUN.  How many fun OSes are
there?

> Constraints are important. For bonus points, define a constraint as it
> relates to programming.

Programming in Tunes consists of writing specifications for objects.
These specifications are defined by sets of constraints.  Each constraint
corresponds to a specific property that the object has.  For example, an
array object has a constraint that says how many elements are in it.  In a
C program, the function bodies, preprocessor directives, and variable
declarations are all constraints on different objects at different levels.
The functions are part of the specification of the main program, and the
flow structure of the functions are part of the specifications of the
functions.  Attributes are called constraints because they limit the
possible things an object can be.  Objects with fewer constraints are less
limited, and therefore more abstract.  

> One of the problems of customizing a system to a user is
> inter-operability. When you learn Window$ or MS Word on one computer, you
> can use that experience on any other computer with that software. When you
> start making vast parts of a program easily configurable, you must relearn
> a piece of software on each machine. 

Limiting the available options in a system is a bad approach to
interoperability.  The notion that more powerful systems are hard to use
is a myth perpetuated by Microsoft.  The truth is their systems are
neither powerful nor easy to use.  Microsoft creates systems like a remote
control with one button, and markets them as "easy to use".  Then, to
prove their point, they make a "Deluxe" remote control that has 100
buttons and takes a month to learn.  This false dichotomy is based on the
premise that the avaibility of features confuses the user.  Actully, the
visibility of features confuses the user.  Tunes makes a remote control
with one button, and a sliding panel that reveals the other 99.  You can
learn the basics quickly, and progress to advanced features if and when 
you are ready.

> Until the technology comes along to
> store and distribute personal preferences to each machine a person uses,
> such configurability has a severe inter-operability drawback. Not every
> computer can be reached from every other computer all the time.

This technology has already been invented.  We just forgot about it for a
while since we stopped using it.  But if I'm not mistaken, your
description sounds strangely familiar to an old, dusty component in my
computer.  Yes, folks, it's time to revive the old FLOPPY DISK!  Now I
know what it means when they say Tunes makes full use of your system.
Your old hardware starts doing good for you again.

> > > > Since the system is constantly evaluating, an edit on the expression will
> > > > cause changes to take place immediately.
> > > 
> > > What changes? What are the changes doing?
> > > 
> > > Let see... if programming is equivelant to editing the expression, then a
> > > change would be something like pressing Enter on a command-line interface?
> > > The immediate change taking place would be the execution of the command?
> > 
> > Yes.  Also, moving the mouse may update one byte that contains the current
> > position of the mouse.  The byte is part of the system expression, so when
> > it changes the entire system re-evaluates. 
> 
> I assume this means that every object that uses the byte to calculate its
> value or generate its side-effect is reevaluted. And that the mechanism to
> do this is implementation-dependant.

Yes and no to both questions.  Every object that depends on that value
will be aware of the
change and be able to update if desired or if necessary.  The mechanism is
identical at the high level--the mouse pointer context contains a
constraint to perform some action when the mouse position changes--but,
like everything else, can be dynamically compiled to different platforms
in a variety of different ways.

> > > > Any changes that are not to take
> > > > place immediately (or subexpressions that are not to be evaluated yet)
> > > > will simply be specified to not evaluate yet.
> > > 
> > > Would these be programs that are written, but not executed yet?
> > 
> > Yes, also programs that are not done being written (because we would not
> > want to try to execute them); functions that cannot be fully evaluated
> > because they would expand into infinite recursion; and other objects that
> > wouldn't make sense to execute, such as a database record.
> 
> execute, not evaluate? Can't you evaluate a database record? The data
> doesn't have meaning until it is evaluated by an object, right?

I use the terms execute and evaluate interchangeably.  They are really the
same thing.  But if your database record only contains names and phone
numbers, it won't make much sense in any programming language (evaluation
context) unless it is combined with a function that does something to it,
right.  Each object can be evaluated in different contexts, depending on
its type.  When an object is put in a different context, the receiving
context tries to evaluate it.  What this means is that Tunes takes the
constraints from the destination context and the source objects and tries
to resolve them (check whether they can exist simultaneously).  If the
typecheck succeeds, the constraints combine to create a new object which
then begins evaluating.  It continues evaluating as long as it exists,
even if its only constraint is the one that says "take up memory".

[I agree with everything you said here, so I deleted it]

> [ An agreeable, convincing and helpful argument for reflection snipped ]
> 
> [ Everything else also snipped ]
> 
> What is stopping me from releasing my left thumb as Tunes 1.0? How would
> anyone know that my left thumb isn't Tunes?
> 
> What is a Tunes system?

Tunes is the free, reflective, intentional, interactive typesystem that
Fare is going to use to catalog his CD database.

> What would it do?

Obey Fare's commands.

> How do you know if you've written it?

Show it to Fare, and ask him if it's the right one.

> What is the shortest path between here and Tunes?

Send me money.  Seriously, all I need is time.  I think the most feasible
strategy is to convince RMS that he could probably use a system where it
is impossible to not have source code, even if you don't.  The other
strategy is to market Tunes as a learning tool for children.  Doing both
is acceptable.

> What would a bootstrapped Tunes system consist of?

That's a good question.  We should probably figure that out.  We know what
it should have, eventually.  It should contain emulators for every
existing hardware and software platform, and environments for every
existing language, implementations of all network protocols and all user
interfaces.  All that's for running old applications until they can be
paralellized.  Then, idealists like Fare and I will need all new
interface, network protocol, and application modules.  Our interface is a
hybrid text-GUI.  The network protocol is a 100% transparent evaluation
context, i.e. networked systems connected seamlessly in every aspect, able
to share ram, disk, cpu, modules, and desktops.

For the initial system, I thought a simple text adventure game might
demonstrate that the system is feasible.  If the game is playable, and
editable with a text interface, it'll be a good start.  (Built on top of a
secure, reflective type system of course)

> The high-level descriptions of what Tunes will do are good, but I want to
> know what Tunes is. None of the high-level Tunes discussion lends itself
> to contemplating an actual implementation. What Tunes does (will do) has
> been well-discussed, but what it *is* (will be) still eludes me.

Existentialism aside, you'll have to be more specific.  I think the
question "What is Tunes?" has been asked so many times that it's worn out.
Maybe you should tell me what Tunes is.  If everybody on this list does
their best to explain what Tunes is, we can iron out some of the details.
One-liners are welcome, but longer would be appreciated.

[David Manifold] <dem@tunes.org>