Reflecting on reflective computing.

[David Jeske]

On Fri, Oct 23, 1998 at 02:52:23AM -0700, Christopher Barry 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.

I hate to say it here Chris, but for someone who wants to spend his
time telling the Tunes people we don't know what we're talking about,
you sure are making quite a few opinionated statements sound like
fact.

How exactly is AI going to prove program correctness? Isn't that just
giving up on the problem of program correctness? If You basically say
you have to have 'something intelligent' to check a program, and that
in order for it not to be a person, it has to be a computer thinking
like a person, it sounds like your just punting on program correctness.

You're calling some of the Tunes ideas weird, or crazy, but your
hedging all computer advancement on an even more poorly understood
goal (i.e. AI). Sounds like you should go find a bunch of people on an
AI list, and go see how much they've implmented.

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

You should take a look at Aspect Oriented Programming, and
Handel-C. Two methods for developing programs in a different
manner... where the system as a whole can help you make it parallel.

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

I don't understand what is meant by the original statement above
either. However, I think the idea is that we wouldn't encode bottom-up
implementation oriented limitations in software. Right now, if you
write software in most popular languages, and you need an integer, you
pick 8, 16, or 32 bit. What happens if someone needs it to be a bigger
number than that? What happens if it's really only valid in a certain
range. The most appropriate dependence to build into a program is the
top-down dependence that the code/algorithm imposes on the numbers,
not these bottom up implementation dependence things. There are
languages which help this today..Tunes will go further, and do it in
ways which go beyond variable types.

Did that come close to what the original author was thinking? (I think
David M.?)

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

Damn... where is this interface which is so efficient? I have a
Linux/X setup at home, and I can think of half a dozen things I would
do to make the interface more efficient. More importantly, I'd really
like to be able to build custom interfaces for display of a few
different types of data: (a) my mailbox data, (b) information from my
PalmPilot.. 

Nextstep taught me that coding interfaces with source code is a big
waste of time. Self showed similar promise. Yet neither system is
prevalant. Other GUI builders are nowhere near as powerful (i'm sure
there is some nice smalltalk tool, but I've never used one). Not to
mention, current systems hard-code the interface to the logic/data
manipulation. While that may make sense for Quake2, most
non-entertainment apps (IMO) would be more functional if it was easy
for the user to create custom interface for his data.

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

Actually.. there are quite a few things I would like to change about
how the Netscape UI itself is done. When Mozilla is stable enough,
I'll go make them. However, current systems don't handle this
well...only "developers" can really go in and make UI changes, and
"users" are forced to just take what they get. Tunes blurs the
distinction between user and developer.

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

I have read reviews of dragon dictate. 

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

Yes, but how do you have the voice software access that menu item
without a command hotkey? Record some mouse macro?  Center at the top
of the window? That's painful, and would not be trivial. Tunes
considers the idea of having applications work together horzontally of
the utmost importance. Furthermore, what happens when Netscape
releases a new version, or when you want to use a different web
browser? You get to redo your mouse macro, or key input macro. Tunes
intends to provide a system where components work in concert, not
despite eachother.

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

I know plenty about the Hurd, and I think Microkernel's and Exokernels
have some distinct advantages over Linux. However, the HURD isn't the
first microkernel, and it isn't the first user-land driver system. It
isn't even the first GPL microkernel. Take a look at VSTa.

However, all microkernels I know of, with the exception of QNX, have
backpedeled on their claim, and realized that there are performance
issues. So in today's world we are force to pick between speed
(i.e. macrokernel) or safety (microkernel) with the exokernel
somewhere in the middle (and a bit better than both). (Ex. Mach 3.0,
and the NT microkernel both pulled drivers into the kernel for speed
reasons)

Tunes (at least my idea of Tunes) seeks to change this, by no longer
forcing the software and drivers to be coded 'for' one of these
models. In Tunes, code your hardware-access code... let it live in
user space, let it live in kernel space, let it run in a software
simulation, it dosn't matter, and the code won't change. Those are
run-time details which should not change the operation of the code.

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

If I could kill one thing in Linux, it would be the "standard C
library". Don't even get me started on that. The standard UNIX/POSIX
libc is the source of at least half of the 'implementation dependence'
and 'application install problems' that exist on UNIX today.

> 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 a lot of nerve for someone with so little clue^h^h^h^h patience.

Sometimes there are hard ways to do things, and there are short ways
to do things. Some of us pick the hard ways, because they are right in
front of our faces (linux/libc). Some of us spend out time looking for
the better way. We are spending our time looking for the better
way. If all you want is Linux, then why are you wasting your time (and
ours) here?

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

Really? You don't even understand what Tunes is about and somehow you
are qualified to tell us what we must do? I think someone needs a
reality check, and it isn't me. :)

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

What happens if you, as an end user, in UNIX want to do something
which dosn't have a configuration variable in some file? You are
screwed, you go to the author of the software and ask him to put it
in, or you change the software yourself. However, changing the
software is a daunting proposition for an end user. Tunes seeks to
blur this distinction by making the user and developer system one
cohesive system with many ways to change software. 

You should go take the SELF environment for a drive before you start
saying that isn't possible. (http://self.sunlabs.com)

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

Here you go again with the "you've got to"...

Do you know what AOP is? Do you know when the research was done? How
many other useful research projects out there which would lend a hand
in creating a better system? How many of these will you see if you
spend all your time hacking customizations into your Linux system? 

There is a time for implementing, and a time for learning. You sound
very impatient, you want an implementation and you want it now. That's
fine, go run Linux. If you want to learn, stick around. You can have
both, but you can't tell us we should be Linux, because we're
not. Besides, what fun would that be.

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

Tell you what.... this is the last email from you which I'm going to
wade through your antagonistic statements in order to provide you a
dignified response. 

For someone who has it all figured out, you sure don't know very much
about social matters. So I'll give you some advice. This is a
community. Like all communities, when we challenge eachother, it is
with respect. You, in your repeated chidings, have demonstrated that
you do not respect the people here, or their ideas. You pretty much
have three choices:

1) keep ranting on... in which case you'll be ignored by me (and
hopefully others) until you get bored and leave. You'll have made a
great impression as an "internet flamers"/"linux weenie".

2) decide that there might be something you can learn from these Tunes
ideas, put some of your own effort into it instead of having us do all
the work, read some mailing list archives, post some questions about
some of the statements people have made in the past. Make these
questions respectful inquiries, so people are inclined to share their
ideas instead of wanting to boot you out the door.

3) decide that there isn't anything for you to learn from here, and go
away.

The choice is yours...

-- 
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net