scalable abstraction

[Tril]

[Brian Rice wrote:]
> >> I hope so.  This banter is definitely helping me expose my internal
> >> arguments and questions to pressure, and I've narrowed my focus
> >> somewhat.  Naturally, there are many more issues I wish to discuss, but
> >> I've got to work on one stage at a time to make sure that I keep
> >> progressing.
> >
> >You seem to be better at expressing yourself in English than I am.  But,
> >also, you seem to be the only one other than Fare and myself with a really
> >in-depth idea of how the system works.  Could you help me focus my design
> >by asking questions to me?
>
> sure, i guess. which approach is yours? (i.e. self, ...)
> questions to you in the group thread?

I'm currently (embarassing as it may be) bootstrapping a reflective
architecture using the C language.  I'm willing to help Fare in his
bootstrap starting with Scheme, and refining it until we have TUNES.  I
need to learn about Scheme in more detail, however (vectors and such).

I don't necessarily want to talk about the bootstrap method, although
that's part of it.  I'm really working on the project definition.  What is
it that we are doing ... how to organize the quantity of ideas that
revolving around Tunes.

But the most useful thing to me would be if you could help me express my
concept of the inner workings of the system in words.  The 'abstraction
system'.  This is the core of the system, where all the external features
must have a basis.  TUNES is like one big typesystem.  Also, inspired by
Fare's 'fuck low level systems' letter, I realized our goal is to allow
a full range of visibility of the low level, from completely hidden to
completely visible.  Any given application in current systems exists on
some point on the scale, but that's exactly the problem.  Applications are
_fixed_ at some point on the scale.  We need to orthogonalize visibility
of low-level, from functionality.

> >I have found the best way to stop worrying about the success of the
> >project is to realize it doesn't matter if it runs fast on current
> >hardware.  I completely ignore efficiency.  Forget about efficiency.  It
> >doesn't matter.  New hardware will be designed for TUNES.  It's just a
> >fact.  Our job is to make the system as an example of what can be done,
> >and if it runs slowly that'll just encourage hardware to be made.
> >
> >I think you are thinking too much about the optimizing compiler... In my
> >opinion, that is the last feature we need to worry about (For the reason
> >above).
>
> well, i'm also considering the efficiency of the interface.  i.e. how
> long / how much effort does it take the user to grasp this or that
> complex concept? how difficult is it for the user to manipulate objects
> in all desirable second-order/meta-order ways?

Good.  We need to debunk the myth that ease-of-use comes at the expense of
power.  I think the sliding-scale for abstraction level I mentioned above
goes a long way to do that.

It's important that TUNES be unified among abstraction layers, as well as
between paradigms and invididual generic methods.  By this I mean the user
interface, no matter what it is, accesses the same underlying
representation.  We've said this before, but maybe not clearly enough.
That's my idea of a UI for TUNES: You can use GUI, or Text, or anything,
but all interfaces should be encouraged to directly support the abstract
typesystem.  (We need a page describing unification, and why it is needed,
in detail.  Is there stuff about this in WhyNewOS?)

If the UI is just an extension of an editor for the typesystem then the
user interface is just as easy to understand as the underlying typesystem.
Therefore my goal is to make the BASE abstraction system easy to
understand.  I think this differs from your view, because you said "no one
would WANT to mess with the internals" or similar.

David Manifold <dem@tunes.org>