TUNES Manifesto [draft]

[Jason Marshall]

Tim Wilson wrote:

>On Tue, 3 Jul 2001, Tril wrote:
>
>>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. 
>
What would you have in their place?  Closed protocols?  Look how long it 
took the Samba team to hook into the Windows file sharing protocol, sans 
specs.  Consider too that they are considered a wild success story.

> 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.
>
But without interoperability, you have nothing, because no one will show 
up to your party.

>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.
>
Not true.  XML is an answer to your previous complaint about the W3C 
putting out too many standards.  XML lowers the barrier to entry to 
implementing more than one of the W3C specifications.  It also lowers 
the impact of the "Best viewed (I mean, this only doesn't break on) 
Browser X" fiasco.  Neither IE or Netscape are going to be on my 
cellphone in the near future.  

Certainly, it also lowers the barrier to entry to creating new 
standards, but I can't imagine that ease of creation is a major 
deterrent from creating them.  You'll get a few more bad standards you 
have to weed through to get to the good ones, but the overall effort to 
implement them will still be lower, and the amount of evangelism to the 
content creation community will drop significantly.  

>>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.
>
If we can't teach a computer to be polite, we might as well abandon this 
project, and our jobs, and go be sheep herders, or mechanics.

>>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?
>
 The would work on improving the system, and porting it to new hardware. 
 Some of them would find jobs doing other things.

><< 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.
>
One of the things that separates programmers from non-programming users 
is mental models of the world.  I think what people need to realise is 
that the thought processes of a potential programmer are, in fact, a bit 
different than those of the non-programmer.  How many of you took things 
apart as children?  Or played obsessively with Lego?  Your neighbor the 
tax attorney probably didn't.  He doesn't give a damn about the inner 
workings of his computer.  To him, it's an oversexed screwdriver, and 
I'm not being facetious.

On the other hand, even programmers don't share the same views.  One 
need look no further than the religious wars over programming tools. 
 VI!  Emacs!  And you can't tell me that a blind man wants the same 
interface as I do, or even a colorblind person, which is 10% of the 
population (most are color insensitive, unable to pick up differences 
between, say, burgundy and brick red).

>>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.
>
User data is one place where the users will demand a strong separation. 
 If I want my resume, I want my resume.  It needs to be a separate 
logical unit of data, so I can manipulate it individually.

>>* 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.
>
Agreed.  If you want a PNG decoder in Tunes, then we need a C to Tunes 
converter, not native support for C code.

>>* 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.
>
I should hope Tunes would be both smart enough not to leave space 
between files that are almost never edited, and smart enough to compress 
data that is rarely accessed.  If both of those situations are true, 
then your 600 M of source becomes roughly 75 M.  Is that more 
comfortable for you?  Plus, only the pure documentation in the source 
needs to be kept in its original form.  The rest really should be stored 
in a computer-friendly format (more compact, but not more compressible), 
and translated for the human on-demand, decompiled if you will.

Also, home networks are becoming more prevalent.  You might not be able 
to trust a computer at mit.edu to provide you with the source code on 
demand, but home area networks should well be able to consolidate a lot 
of this semi-static data.  The core of the system could live on a 
central file server, further reducing the per-computer cost of having it.  

>>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)
>

-Jason

>