TUNES Manifesto [draft]

[Tim Wilson]

On Tue, 3 Jul 2001, Tril wrote:

> I propose the following document as a TUNES manifesto.                          
> If I am severely wrong, and you disagree this is where tunes should be          
> going, let me know, and I'll call it something else ("Tril's project            
> manifesto" :).                                                                  

Sounds good..
                                                                                 
> Programmers have too much power and too much responsibility. They can
> control everything on a user's computer and they feel a need to do so.

Not so sure I agree here.  I've never really felt the need to control
everything on another person's computer.  The thought of controlling more
aspects of my own computer is a nice one though.
 
> There is a widespread belief that programming is a black art, that
> normal people cannot understand, and shouldn't want to.  This belief
> perpetuates a stratification of technological society into elite knowers
> and the ignorant, who are at the mercy of whatever new download they can
> get their hands on today.  The opposite belief, that any user can be a
> programmer, and get their computing job done, should be established and
> eliminate the threat that one segment of society will gain control over
> another.

I'm not so sure about the "black art" bit.  I really don't think many
people using computers today consider programming them.  They
just want to type up a Word doc and print it out.  Maybe check out a few
golf scores on espn.com or something.

>  Whatever factors that make programming and using a computer
> difficult, that make code incomprehensible, and that make computers not
> obey their users, should be eliminated.

Agreed.

> The software crisis is created by a surplus of ideas for what people
> want computers to do, and a shortage of willing and able programmers to
> make the computer perform. 

I believe whats hurting the computer industry the most are standards.  I
look to web standards (W3C) and cringe.  VRML, XML, HTML, DHTML.  A
mark-up language for everything you can imagine.  Mark-up is supposed to
be used for text, so as to be "out of the way" of content.  Mark-up was
never intended to become _the_ content.  Today if you remove the mark-up,
the content is rather meaningless itself.

Rob Pike claims "90-95% of the work in Plan 9 was directly or indirectly
to honor externally imposed standards."  Standards is where all developer
time is being spent.

People today are creating standards first, then trying to find a need for
them.  Take XML for example.  There is no benefit available (and I
wouldn't even claim forseeable benefit) from it yet, but there is a push
in every imaginable direction for it to be something.  It is more
marketting than technical achievement.

> Ideally, programmers would be not needed and
> the computer could program itself.  If a user can communicate to a
> computer what is needed, and it is done, then the software crisis is
> solved.

Until two of my computers on my network get into a fight over the same
printer.  Just wait.

> In addition other problems exist in computing: Bloated programs that
> have features no one will ever use, platform incompatibilities, frequent
> crashing, rebooting, reinstalling. 

True.  Most of these are software corporation issues.  Of course, if
computers programmed themselves we would have no software corporations and
then no problems.  Then where would the programmers work?

<< Large portion cut.. >> 

> * eliminate the dependence of an application on a single user interface
> 
> When you write a program today you have to write both its functionality
> and a user interface.  This practice should end.  TUNES will allow
> programmers to be write programs without a user interface, writing an
> abstraction layer instead.  Using the TUNES standard abstraction layer
> all user interfaces that TUNES supports can access the functionality
> that is programmed.  This will allow users to use their interface of
> choice at all times, and provide the best accessibility.

This seems contradictory to what you said previously.  If users ARE the
programmers, then it makes sense to program through the user
interface.  There can be no abstractions.  Everything would have to be
thought of as on "equal ground."  To me, user interface abstractions are
what divides users and programmers.  I think we should just ignore any
differences between "non-programming users" and "programmers."  Simply
concentrate on the similarities (why do people use computers, what are
good ways to access particular information, etc.).  Step back from the
"create software for user" mentality of software corporations.

> The artistic ability of programmers to create their own custom user
> interface for each program will not be denied, but all programs will
> work detached from the given interface and attached to another.

I agree that information stored within a computer should have many
ways of interaction.  I'm not so sure we should even say "interface."  How
about "people should use computers by any concept or manner imaginable?"

I know this is supposed to be an introduction to TUNES, but you seem to
mix "concrete" concepts with more abstract concepts.  If I understand
TUNES correctly, there will never be any individual "program."  It will be
one continuous, evolving unit.  The word "program" to most people means a 
individual binary file stored on disk.  The TUNES I picture will not have
a concept of binary, file, or disk unless the user's context demands such
abstractions.

 
> * eliminate the barriers between programming languages
> 
> When I write a program in Perl I have to use "glue" to call the C library.  
> And vice versa: when I write in C I do not have easy access to perl
> features.  Data types across programming languages have subtly different
> semantics.  Fixed-size integer types may be different sizes or have
> differing bit-representations.  TUNES will provide a "universal glue" to
> allow any language to call any other.  All the languages will be
> implemented in TUNES as modules for the system-wide dynamic compiler. Each
> language module specifies its own datatypes and provides conversion
> to/from its types to/from TUNES native, very expressive typesystem.  This
> provides a path between any two types by converting from one language to
> the TUNES typesystem, then from the TUNES typesystem to another language.  
> TUNES can automatically search for a conversion path and find what values
> of a type can be converted without data loss.

First you mention self-programming computers, and now this.  I do not
believe any goal should involve making Perl or C compatible to another
system.  They were both designed with different (and specific) goals and
on outdated hardware and operating systems.  I don't use Perl enough, but
I do know C is tied to hardware and operating system conventions (such as
stdin/stdout, returning int from main(), etc.).  I do not really see how
keeping around dinosaur languages will advance computer software.  Could
C/Perl be ported to a TUNES-like system?  Sure, if the user really desired
it to be.  Should TUNES even be considering keeping them?  I don't believe
so.  Focus on what is important.  Let users worry about things like
this.  I believe a good deal of narrowing down goals is needed for TUNES
to survive.

> * specifications, state always available for reflection
> 
> People have a habit of writing implementations and leaving out
> computer-readable specifications.  This is unacceptable in TUNES where the
> implementation must be automatically generatable from its specification.  
> In TUNES the specification is its source code.  Programmers can make hints
> or completely write their implementations as they wish, as long as the
> specification is there.

I'm not so sure I understand why source code (specification) should always
be present.  Wouldn't the semantics (meta-specification?) be
enough?  Doesn't keeping specification also fall under "doing what the
user wants?"  If the user does not want specification, should he/she be
able to remove it?  I know you are trying to promote the free software
ideology (and I agree with information freedom), but I do not agree it has
to be a technical "wall."

155772  /usr/src/linux

155M for source code to Linux.  I believe it is another 300-400 for X
Window System.  This is a great deal of space inefficiency that rarely
will be used.  When was the last time you cared to look at any free
software source when a change wasn't needed?  There should be a way to
modify system/software behaviour without needing the source code
(meta-programming?).  Specification (source code for particular
language) should be a non-issue really.

> The dynamic compiler can re-implement any part of the system at any
> time, so the source code has to be there.  It also has to be there to
> prove the system correct according to its specifications.  But the most
> important reason is that the user has a right to know exactly what goes
> on in his or her own computer.  TUNES will allow the user to inspect and
> change any part of the system's source code, and then have the system
> re-compile from that code, without any rebooting or manual intervention.

I agree that the user should be allowed to know what is going on within
his computer.  I do not agree that source code for a particular language
will be useful.  I also do not get this "re-compile" stuff.

Okay, it's late and I'm tired ;-)

Don't get me wrong.  It is good that there is any discussion being brought
up on the mailing list.  I do feel it would be better to start small and
narrow on TUNES' goals.  Leaping in with broad, and for the most part
vague, goals is a sure way to end a project before it's started.  Figure
out the smallest thing that would work for one particular goal and build
from there (Keep It Simple Stupid).


-Tim (td)