Reflecting on reflective computing.

[Christopher Barry]

Tril wrote:
> 
[...]
> 
> For reuse, I probably meant OO.
> Debugging can reduced drastically by program proofs during programming.
> As for AI: We'll see.

AI is what you need to prove program correctness.

> However, I don't think AI is necessary to free people from linear thinking
> in programming: Use parallel languages.

Two linear streams in parallel ain't no better than one, just 10 times
more of a hassle to set up for debugging....

> And the OS should adapt to
> hardware limitations, and not provide any static requirements for
> applications so that no software limitations are induced.
> 

The OS not provide any static requirements for applications so that no
software limitations are induced? If Tunes does not provide static
requirements, then it provides either dynamic requirements or no
requirements, does this make sense? In what sense do you mean software
limitations? This is a cryptic statement as I've interpreted it.
 
> 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?

I have no compelling reason to redesign my UI to anything more
efficient. I think it's asymptotic efficiency limit has been reached.

> If you tried to do so in
> current systems, you would have to rewrite all applications to work on the
> new UI.

Kind of depends on your definition of UI, no? I didn't have to rewrite
Netscape or XEmacs to move the buttons around a little or when I
switched window managers and defined macros. These were important
changes made to the UI that didn't require source tinkering on my part,
but improved efficiency 1000 fold. Or perhaps you were thinking of a
more fundamental change, like saying using a voice only UI. But this
wouldn't require any software to be rewritten either, you could layer on
top, but yes, I see your point and know that layering isn't the One True
Way and you wouldn't need to layer in Tunes. But there are entirely
other things to consider....

> 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.
> 

This is a good point that a robust object oriented framework could
address. But I would like compelling specific examples. If you thought
my voice example was compelling, well, have you ever used speech
recognition software such as Dragon Dictate? It's Microsoft OS only and
closed source so I don't have it or use it but it can write out what you
say as fast as you can say it and it's *extremely* accurate and I wish
their were something as good for Linux. Since I have macros assigned to
most of my UI events, I could bind voice words to these macros and
voila, I can switch to XEmacs with a word and say what I want typed and
then I can bark a URL at netscape and have that loaded and displayed. No
code rewrite needed. A layered approach, but it works and with today's
technology, no? But anyways, how about some compelling UI examples?

> 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.
>

Well, maybe just one more comparison. The HURD is but an incremental
step over current operating system technology, allowing liberation of
the reboot part of some development cycles, and pervasive use of
threading and better scalability yadda, yadda, yadda....

But most importantly to consider is that many years of time has been put
into developing it and development has been extraordinarely slow despite
the fact that some of the most brilliant Free Software authors have
spent significant ammounts of time on it, such as the main implementor
of the GNU C library and some of the GNU C compiler guys as well as many
others and look what they have to show for now? The've *finally* got a
decently workable and usable system now but look at how long it took and
how much more work is left to do, and you guys want to implement
something orders of magnitude more ambitous. Sometimes a good dose of
Reality administered by a good wack upside the head with an iron Clue
Bat[TM] is in order. You've got to start somewhere, and tunes.c or some
proof of concept code that doesn't even prove your concept just isn't
gonna give you a good start. You must define intermediate goals where
there is a clear path to what you want to achieve.
 
> > > * 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).

The bash and ksh (probably all the other ones to) shells provide job
control that lets you do this without having to open another virtual
console or start another telnet session. You probably know about
appending '&' to a process to start it in the background, but any time
you've started a process that isn't accepting input while doing
something, or even if it is accepting input, you can suspend it with
control-z, and then bring it back to the foreground by typing 'fg'. You
can get a list of job numbers by typing 'jobs', and you can kill, start
and suspend, and freely move to the foreground and background your jobs.
To bring a specific job to the foreground or kill it, you get it's job
number by typing 'jobs' and then 'fg %2' for example to bring to the
foreground job 2. 'kill %3' kills job 3. So we've got a 1970's
technology that allows "Text-based multitasking control without
emulating multiple terminals."

> Non-window-based graphical interface models (no specific ideas in mind).
>

And why would we use non-window based graphical interfaces? If you don't
have a specific idea that makes your point, don't bother. Tunes would
address many limitations of current systems, but you're not going to win
the:

"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."

argument, if you can not provide examples.
 
> > > * 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.
> 

I'll agree to this, and it is one of many important, possibly achievable
goals. But you've got to define clear steps to reach the above goal and
define sub-goals. Talking about the ideal system on a mailing list for 5
years and not writing a hell of a lot of code or complete specifications
so that code can be slapped out ain't gonna get a whole lot done.

> > 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.
>

That was a mighty vague statement. But no point in picking this apart,
bigger fish to fry ahead....
 
> David Manifold <dem@tunes.org>