TUNES Manifesto [draft]

[Jason Marshall]

Tril wrote:

A few comments from a long-time lurker:

The following ideas are self-consistent:

>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.  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.
>
>If a user can communicate to a
>computer what is needed, and it is done, then the software crisis is
>solved.  The lack of programmers means everyone has to cope with
>software that doesn't do exactly what they want.  This wastes time and
>creates frustration, only broadening the gap between elite programmers, who laugh because they know how to get the computer to do what they want,
>and ignorant users who only struggle.
>
>The Internet has gaping design flaws such as being completely vulnerable
>to Distributed Denial of Service Attacks.  Much information on the
>Internet is difficult to find.  New improved protocols that might solve
>these problems, and others, are hard to phase in because they require
>new code to be written for many different platforms, tested, distributed
>and installed.  The goal of the Internet, and of computing in general,
>should be to get information to where it is needed, when it is needed. 
>A software system that embodies this principle would be a good start at
>helping the Internet, made of smaller software systems, also do the
>same.
>
>So, to create a computing system that gives total control to the user,
>is extremely portable, safe, and fast at allowing changes to programs
>and to itself, freely available, and moves information where and when it
>is needed, we require a redesign of every aspect of computing from the
>hardware, the operating system, language, applications, and the user
>interface, to the users themselves.  In fact, we need a "whole" system
>that redefines all of these components and lets them interact in better
>ways.
>

And then you throw this curveball:

>* 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.
>
>The universal calling convention is that the dynamic compiler produces
>all the low-level code implementation of every language, and can
>therefore move processing flow across language barriers seamlessly at
>compile-time (which is right before runtime, with caching of the
>compiler result).
>
How can you possibly eliminate the difference between users and 
programmers, and still provide support for the arcane formats with which 
programmers have allegedly maintained their separation from the masses?

>* eliminate the difference between programmer and user
>
>If I am a user I am dependent on the whims of a language or library as
>to whether an interface is provided.  No more. 
>
How can I avoid the whims of language if you preserve the whims 
(favorite programming language) of the current generation of programmers?  

The real problem, the heart of the issue, in my mind, is that presenting 
the data to a layperson is difficult, due to mountainous dictionaries of 
idioms that a normal programmer uses, and the ad hoc nature of 
implementing them.  This is also the cause of a mountain of bugs.  The 
five ways to implement a visit to each element in a set not only 
introduce the potential for bugs, but alienate the uninitiated.  This is 
worsened by the fact that each language has their own idioms for these 
tasks, to the point of alienating fellow programmers.  "Say what you 
mean" is bad enough in any one of the current generation of languages. 
 It's plain awful when you consider them as a whole.  I believe there is 
no place for any of them in a System for the Masses.

I have considered the problem of language interoperability at great 
length, and the sad fact is that anything that is easy to do, a large 
population of programmers feel entitled, nay, morally bound, to do.  "If 
you didn't want me to write 10% of the program in C, 50% in C++, 30% in 
Java, an 10% in Perl, then why did you make it so easy?"

Unfortunately, I truly believe that this is a situation where you can't 
have your cake and eat it, too.  I believe that the only solution to 
this problem is the standard One True Language answer.   However, there 
are ways to ease the mechanic's heart in those of us (ie, programmers) 
who like to know the intimate details of the system, and that is by 
specifying a mechanism for providing views of appropriate levels of 
detail into the system.  

With this in mind, I have been considering the use of one language, but 
multiple presentations.  Currently, I'm investigating using an XML 
grammar as the basis of my language.  I'll spare you the usual song and 
dance about How Great XML Is, but the important thing here, besides the 
bootstrapping effect of existing tools (obviously, they would eventually 
need to be rewritten), is the clear separation between markup and data, 
and between data and presentation.  Any user can pick an appropriate 
level of detail to look at the code, and the code for handling this 
conditional presentation is comparatively straightforward when compared 
to any existing programming language.  Those with a real urge to see the 
code in a peculiar fashion can endeavor to do so, but those of us who, 
for instance, are used to Java, needn't be bothered to learn Perl to 
have full access to our system.  Those of us who know no computer 
language needn't be bothered with learning half a dozen languages to 
have full access.

I haven't yet satisfactorily addressed the issue of how to handle the 
idioms in a way that will please both myself, and my next door neighbor, 
but I expect that will take a great deal more deliberation before I have 
something I am happy with.

-Jason