Reflecting on reflective computing.

[Tril]

On Thu, 22 Oct 1998, Christopher Barry wrote:

> But the Tunes documentation (my apologies
> if it's insanely out of date, but this is isn't indicated) indicates you
> guys don't have any Clue of the nitty gritty of the system, and not much
> of a Clue about how many fundamental aspects can even roughly be
> realistically implemented.

Yes, it is quite outdated.
I'm still unsure whether to try to document the current concept or to work
on developing the system and have the work document itself.  I'm leaning
toward resuming development but continuing to jot down notes and converse
on the list.

For reuse, I probably meant OO.
Debugging can reduced drastically by program proofs during programming.
As for AI: We'll see.
However, I don't think AI is necessary to free people from linear thinking
in programming: Use parallel languages.  And the OS should adapt to
hardware limitations, and not provide any static requirements for
applications so that no software limitations are induced.

UIs: It's good that you can accept a UI.  But what if you want to redesign
the UI itself, not just configure its behavior?  If you tried to do so in
current systems, you would have to rewrite all applications to work on the
new UI.  TUNES makes the assumption that each user wants to customize his
or her UI (and any other part of the system) in subtle ways, any of which
might cause an incompatibility in today's layered systems.

The Hurd is an incremental step in design.  TUNES is, as you probably can
tell, a huge leap straight up.  It's probably good not to try to compare
them any further.

> > * Spent waiting on the computer to do something while it ignored input.
> 
> Not an issue unless I open 30 Netscape Windows and the mouse pointer
> freezes during heavy swapping, but it's for 2 seconds tops, and never
> happens unless I try to make it happen anyways. I think modern
> multitasking environments with windowing systems address this pretty
> good. And I don't see how a Tunes system can allow the user to be doing
> something useful at any given time that is more useful than how current
> multitasking systems let you do something useful at any given time, but
> examples would help.

Text-based multitasking control without emulating multiple terminals (I'm 
not sure of any details here).
Non-window-based graphical interface models (no specific ideas in mind).

> > * Went toward figuring out how to optimize special cases to get decent
> > performance.
> >
> 
> This seems kind of unavoidable, unless I misunderstand the sense of what
> you mean.

I was sort of unclear.  I meant when you actually redesign your entire
program to get an efficiency boost.  Code that is efficient for the
machine is not always maintainable.  AOP (aspects), or the more general
orthogonalization of specification and implementation, solve this.

> Do you mean optimizing in the sense of say special hardware cases
> (presence of MMX unit or deep pipeline), or software, like case N=13 for
> an algorithm or system=SysV? Or perhaps both? In any case if the system
> you guys are making has the intelligence to automatically optimizes
> programs and algorithms for all relevant special cases that the
> programmer would be interested in automatically, well, good luck.

Both hardware and software.. but there's no magic to optimizing.  Allow
automatic optimizations where they work, but allow users/developers to
specify information necessary at any level to provide the structure they
want.

David Manifold <dem@tunes.org>