TUNES is a Useful Nevertheless (NOT?) Expedient System

I want to take a moment to acknowledge a piece of digital history that's on the verge of evaporating. As early as the mid-1990s (when I was in college), I read about this ambitious TUNES is a Useful NOT (*) Expedient System aspirational project. The core-idea as I saw it, was a user-centric software system that let the user express what they want to happen, and the software would then deal with the details. 

For most (if not all) of the tunes.org history, the project was merely aspirational. François-René Rideau's  dream of how software could adapt to people, instead of people adapting to software. And *that* mentality, is what became the most enduring legacy of TUNES in my mind over the many decades I've worked in technology.

As I recall, there was a motivating user-story about organizaing a music or CD collection, which probably was to feed into the TUNES namesake. Where the user simply expressed commands to the system, and it dealt with the details of organizing the data, searching it, presenting it, etc.

While one might think that only now in the era of AI are we getting close to the vision, there are many layers to this idea that have to be tackled as technical problems long before AI can be incorporated. Inside the project David Manifold <dem@tunes.org> got involved and did experimental work on bottom up practical elements, attempting to undestand how TUNES would ever come to be.

However, those of us inspired by TUNES carried the torch of the dream into our own lives and in our own ways. 

I personally became fascinated with reflective and self-introspective language systems like Smalltalk and the SELF environment. I also became fascinated with the technical callenges of automatically optimizing databases. Despite most RDBMS systems still using b-tree based storage, any who have worked with them understand how little write throughput they have because of b-tree write amplifcation. If we are to achieve automatically optimizing databases, it will likely be through write-optimized storage systems, because automatic optimization means a constant write load of reorganization. Modern storage engines like Bigtable, Spanner, LevelDB, Cassandra, and Cockroachdb are based on row-split log structured merge based storage, which has orders of magnitude more write througput while asymmetrically only giving up a little read throuput.

Even today, I dream of a day where software systems such as TUNES exist, and deliver the dream none of us know we have. The dream of a software system that does what the user wants. Depicted in movies like Star Trek, aspired to by Richard Stallman's dream that GPL'ed software would return control to users (though IMO it hasn't).

Perhaps now that we have AI, both to embed into the system, and to help write it, we can finally start to see someting approaching the TUNES dream come into existance. Lets make sure it happens in the promise of user-soverign control, rather than the software balkanization for revenue that has marked most of the software industry's pattern to date.

(*) I recall TUNES described as "NOT expedient", as a way to explain that the focus was utility not necessarily performance. Now I see it described as "Nevertheless expedient", and I'm not sure if that transformation happened in the project, or in my own mind. I the framing in my memory, as it was offering the audiciousness of "what could we do if performance wasn't an issue?"