The State of TUNES

[Tom Novelli]

To the best of my knowledge, here's what's been happening (or not) in
the TUNES project:

PROGRESS

Participation was light in 2007.  There were about 10 people engaged
in substantial talk and/or action at various times throughout the
year, including 4 new members.  We are vaguely aware of other people
interested in TUNES, but there's not much excitement about it.  On a
positive note, there were no flame wars :-)

We made modest progress on the website.  All the old wiki/cliki
material has been frozen and preserved.  I wrote some Python scripts
to manage the website and member list, just enough to conveniently
make changes via a web browser.  Tril, Fare and I are now preparing a
Django-based site to run under UserMode Linux, which will be a huge
improvement in terms of features and maintenance.  How far we go with
this depends on our activity level... we could add blogs, annotations,
task lists, calendars, etc.  I'm inclined to keep it very simple,
using GIT for versioning and updates.

On the development front, we've done nothing, but the rest of the
world has made progress.  Computers are faster, multicore processors
are becoming the norm, and high-level languages have become practical
and popular.  One of these days the world will be ready for TUNES.

PLANS

I think informality is crucial at this time.  We've always recognized
the need to experiment, to try things and see what really works, but
previous experiments got too big and cumbersome.  Let's plan to write
a bunch of throwaway code, get our hands dirty, and have some fun.

If there's anything resembling a silver bullet, it's Persistence.
This allows Capability Security, the decoupling of storage from the
filesystem & database abstractions, and more.  This is no small task.
A whole new runtime environment seems necessary, starting with a
Scheme(-like) compiler.  The challenge is to keep it simple.  To me
that means setting aside perfection, performance, portability, and
especially C.  First make a simple system that works, then improve it.

An easier project: write a better "Scheme Shell".  This would bring
the *NIX shell's terseness and interactivity to Scheme.  IPython does
this for Python, but imagine what it could do for a real gem of a
language like Scheme...

Fare's proposals still stand:
http://fare.tunes.org/computing/term-project-proposal.html

The general idea is that all these efforts, and others, and some
existing software, will eventually meet in the middle.

TOOLS

Distributed versioning, namely GIT or Mercurial.

We talked about using Common Lisp last year, but there was a slight
outcry from the Scheme and Ruby crowd :-)  Since then I've played with
PLT Scheme for a few weeks, and that's what I want to use.  Setup is
easy, it runs on all major platforms, and it's pretty featureful for
Scheme.

Here's a little code-sketch I did in PLT Scheme... If you modify it,
please send me a patch just to try out GIT:
- git clone http://tom.bespin.org/src/tlisp.git
- http://tom.bespin.org/src/tlisp/

TIMELINE

- Website upgrade... March 2008
- GIT and/or Mercurial repository... April?
- Start experimenting
- Produce something slightly useful... 2010?
- Produce something really great... 2015? 2020?

Is that wishful thinking? :-)

--
Tom Novelli