On Tunes infrastructure

Michael Conrad conradme@email.uc.edu
Fri May 30 21:53:02 2003


> "Reflection is the ability of systems to know enough about
> themselves so as to dynamically metaprogram their own
> behavior, so as to adapt themselves to changing
> circumstances, so as to relieve programmers and
> administrators from so many tasks that currently need to be
> done manually.
>
> Metaprogramming is the activity of manipulating programs that
> in turn manipulate programs. It is the most general technique
> whereby the programming activity can be automated,
> enhanced, and made to go where no programming has gone
> before. ..."
>

> I really don't mind someone saying that a project like Tunes
> requires some preparation prior the readiness of any individual
> to participate in its development.  I do mind if the preparation
> itself, that which we must first traverse, spouts nonsense,
> something which has not, does not, and will not ever occur.
>

Wow, I can already imagine the flood of discussion this is going to start...
(I hope you're not trolling)

> Programs cannot automate themselves through the use of
> other programs beyond the programmed boundaries contained
> in them.  If we as programmers dictate those boundaries by
> our writing of them, no program that we ever write will ever
> extend beyond those boundaries.  In short no program can
> operate outside its own logic.  No program as meta-program
> can either.  Changing the name does not change the limits.

Would you agree that a programmer could write-up their own programming
algorithm?  I tend to agree that there are aspects of programming that
probably require human ingenuity (I could be wrong, too), but there are many
tasks that a person just mechanically codes in order to accomplish
something.  For instance, if you were programming in assembly and you
suddenly realized that some integer function needed to return a
multi-precision integer rather than a register-sized integer, you would have
to go through and rewrite almost every line.  In C++, you could make a
template out of your function and the compiler would generate multiple
versions with whatever integer-like data type you used.  In a higher
language, the live compiler could determine the size of your calculation
automatically and rewrite your function for you just based on changing
circumstances.  (Like applying the algorithm to 128-bit integers that came
from an MMX register, which inadvertantly got connected to your code)  Thus
the compiler performed a complexity increase you never planned.

When you imagine all the interrelated objects that could be built around
your hardware and software, and all the ways they could be mixed and
matched, and all the optimizations that could be made automatically (and
increased compatibility between components as the live compiler detects
compatible interfaces between intermediate objects in order to allow two
incompatible objects to operate on eachother) the complexity of the system
would quickly exceed the understanding of the programmers who wrote those
components.

I think this is enough backing for the statement: "the programming activity
can be automated, enhanced, and made to go where no programming has gone
before. ..."

> He cannot make good on the delivery.  Tunes cannot.  So why
> not stay within the realm of the possible, which has much yet
> unexplored, instead of going where no program (nor
> programmer) will ever go?

Why spend time and effort on anything that is less than the best?  Look at
Linux- thousands of developers spending all their free time trying to keep a
very static system in a state of motion; almost like claymation.  All that
effort could be directed toward something better and more expandable and
dynamic, and not soak up everyone's time rewriting config files and
rearranging directory structure. (and patching gcc and writing new
single-purpose scripting languages and adding ACLs to the filesystem and
etc)

I think its a good thing that TUNES aims so high- the more intermediate
semi-great systems that we don't build, the less wasted effort.
(But I do think that the thinking has to change to implementing some time,
or we'll be stuck with new patched and expanded static systems for ever.)

-Mike