PLEASE READ What I think Tunes is (and what I think it is not)

[Maneesh Yadav]

[I guess no one really liked my idea of the deadline, understood, well I
am at least going to follow that plan, if I don't produce useful stuff
by then, i probably never will]

I just read Fare's paper he was going to give at the conference he
mentioned, it really got the point across and this is EXACTLY the type
of stuff that I think we need.  I think it should be required reading
before becoming a Tunes member :)

Ok here is what I think Tunes is, I hope this will help others out and
give us some direction in what we are going to make.  Feel free to
respond, it'd be nice if we could agree on something soon :)

Tunes is a model, just like other models (what we think an atom looks
like, how we define numbers etc.), that will be describe information
about information.  What the tunes group wants to do is create a piece
of software that will allow people to use this model in order to tell a
computer what to do (like we use equations to work with models).  Why?
Well there are a lot of problems about the way we are telling computer
how to do things these days.  We often generate large, bloated pieces of
software, we do repetitive tasks in coding that could (and should) be
handled by a computer, we produce implementations of ideas that are
difficult to get to elegantly interact with implementations of other
ideas (exchange and manipulate each other's information), code
maintenance is also a repetitive chore, still not handled well.

Examples to illustrate the previous;
The 1.1 JDK uses a new event model, more robust, but developers were
forced to go back and rewrite their event handling code (this isn't
supposed to happen in OOP right?), but this change in event model didn't
change the way their programs behaved.  The only reasons developers
revamped was because their software would eventually die because it uses
deprecated methods from the java libs it relies on.

Wouldn't it be nice if the ideas of what the programs did could be
implemented abstractly, in such a manner that if the even the event
model, window model or anything else changed, it wouldn't change the
code for the program.  For instance if you wanted to write a program
that asked someone's age and displayed the results of the question on
screen the java code would look like this:

class questionApp
{
 public void main(String args[])
 {
  System.out.println("How old are you?");
  Integer age=new Integer( System.in.readln());
  System.out.println(age.intValue());
 }
}

See all the dependencies, what if we changed the way System worked or a
wrapper class was implemented differently? You'd have to go back look up
how they were changed and make the appropriate changes in your code.
What if the program could be written like this:

Ask the user how old it is
Transmit the user's age to the user

Now of course this is a little hypothetical, but imagine if we could
leave the dirty work up to the computer to figure out what calls to make
etc.  The idea of what the program is contained is in those two
sentences.  Regardless of how the system draws windows, how it holds
integers, transmits information to the user (voice, display etc.), how
you tell it to write a string to the screen etc.  Note there are a lot
of specifics left out, what if you wanted the string to be printed in
red say, Tunes won't be a complete natural language to machine code
converter, but it will be a model that will allow the uniform expression
of ideas, like the two that make up the above, and the tunes software
will be responsible for making the computer actually turn the ideas into
actions of the computer.

This is what Tunes is not:

A new language/compiler

A language is a specific set of (usually) english words that are
associated with a particular grammar (valid sets or words), which a
compiler translates into instructions that the machine can execute.
Languages usually have at least the two goals:  like to use words and
grammar that encourage easy understanding of a program's function, and
allow the programmer to write efficient code that will solve problems
quickly so the user's of the program can spend more time doing something
else.  Until perfect code analyzers exist, no language will solve this
problem, and it is not our intent to create the perfect optimizing
compiler.

A new OS

Sometimes people are little confused as to what an OS actually is.  We
all have dreams of amazing 3d interfaces with voice recognition etc.  it
is not our goal to create a new user interface.  It is also not our job
to create an OS has the best memory handling, task switching or
messaging system.  There are lot's of other that you think about when
designing an OS, distribution, parallelism, security etc.  Such things
are not included in the goals of the tunes project.

Having said that, Tunes is a model that we want in which people can
elegantly design pieces of software such as the previously mentioned.
We can design a user interface in tunes that can communicate with the
file system, say, to exchange data that the user has (in his/her mind)
into data on the file system, in such a way that the ideas are
represented (for what the UI and FS do) in a way that if we replace the
way the file system is implemented, nothing on the UI is changed.  But
you say, linux virtual file system stuff already works like that.  Yes,
but those file systems have to implement an defined interface, what we
would like tunes to do is to be able represent the ideas of a what a
file system does in such a way that if they change at a lower level
(i.e. a high level idea of a file system is that it stores information,
a lower level idea is that you give it commands through a messaging
interface or through a system call), tunes software will figure out how
to change the software appropriately, a mechanical task that should be
left to the computer, not the human.

Ok is this on the right track?