Reflecting on reflective computing.
David Jeske
jeske@home.chat.net
Thu, 22 Oct 1998 15:53:59 -0700
On Thu, Oct 22, 1998 at 02:37:03PM -0700, Christopher Barry wrote:
> And after downloading the Tunes "source code" and reading up on a lot of
> the archives, it appears that the tools and language theory to develop
> this thing still don't exist. I can't believe that there are message
> archives dated back to 1994, and that how Tunes will handle and do very
> fundamental things still isn't understood or specified yet and still
> discussed, nonetheless certainly not prototyped with working code.
It is true that so far Tunes has not been focused on implementation.
> To make really cool OO system is certainly possible, but to have it
> incorporate *every* miracle feature you guys discuss I doubt is possible
> with current technologies. It's seems an analogy for this would be like
> trying to write 90s software technology like Linux or Netscape back in
> the 60s by toggling it into the front panel of a mainframe in machine
> code (and assuming for analogy's sake that the 60s computer could run
> the 90s code, since today's computers can run what you guys want, but
> it's as though you have 1960s tools to make it with relatively).
It's not just a "really cool OO system". Tunes is following the trend
of software abstraction to it's logical extreme. Hopefully, when
enough people (on this list or elsewhere) have enough stuff figured
out we can take a few steps back from the ideal and come up with an
implementation.
Tunes, more than anything else, is proof that there is some convergent
goal out there just beyond the horizon. Many of the people on the
Tunes list developed their ideas on their own, and while many of the
discussions on this list are filled with nitpicking discussions over
semantics, or approach, we each have a private version of the same
vision stirring in our heads, knawing at us. Something we know is
achievable, if we can just put the right pieces together.
THAT is Tunes.
> And you guys have got little fruit to show for for quite a few years
> effort, IMO. Unless real coding that won't eventually require a 100%
> rewrite starts Real Soon Now. 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.
There is really not much point in visiting a group of people, and
telling them all they are confused. It serves little purpose except to
erupt into pointless argument. Fortunatly, I'm not easily (or ever)
riled.
To counter your point, there certainly is fruit to the Tunes
labor. First off, Tunes saught out to sketch a map of software
strategies. The review part of the Tunes project has largly achieved
this goal. There is certainly alot of information gathered during this
which is either buried in the mailing list archives, or in people's
heads, however, information was gathered. The review pages most list
the stopping points along the way.
Second, Tunes is trying to map out what working with a computer
could be like if, instead of being limited by what you _can_ do, you
were limited by what you could _think of_.
Last, and probably most importantly, Tunes (and the documentation
pages) have served as a discussion list and sticking post for all
these convergence ideas I talked about above to settle together in one
place.
If you are looking for a finished project, or even some group of
people who think they have it all figured out, you are looking in the
wrong place.
If you are here to tell us all that you really just want a better
version of gcc, you again, are looking in the wrong place.
If you are interested to know why a group of intelligent and capable
people have converged to share their ideas on what computing could and
should be like, then stay a while... you might learn something.
Open your mind, and read on...
> Yes, these three could always use some work until the very processes
> themselves are made obsolete when the computer is intelligent enough to
> do it for us. I don't see Tunes as directly a step towards this end,
> because I think implementation of intelligent algorithms and the
> improvement of language and compiler technology itself through the
> implementation of these intelligent algorithms is the most important
> thing, and actually probably a nessecary first if you guys wish to have
> what you need to create Tunes.
The trend you speak of above is only possible when these "intelligent
algorithms" can become 100% equivilant to a human thinker. Only then
would a computer be able to read through software manuals, talk to
other somputers, and figure out how in the heck it's supposed to make
some software do what it wants.
The idea of Tunes is that if we change the nature of the system, and
how pieces of software are described to the world, we can allow
computers to perform much more useful tasks, with much less work. Some
of us might even argue that a Tunes-like approach may end up as a
necessary prerequisite to a system any of us would call intelligent.
I wish I could find the original Tunes 'example problem', about the
"cd database", however, I can't. Can someone else provide the URL.
However, the idea behind Tunes is that there is a heck of alot of
stuff that computers are capable of doing, which are far from easily
expressable. I know this isn't going to give you a very nice happy
feeling of understanding. Wait until someone posts the above URL and
read it.
> > * Actually went toward programming, instead of going back and forth
> > between applications/windows/menus/directories/sections of the same
> > document.
>
> This is a point I tried to address with my original post, if you use
> good software and take the time to really learn to configure and use it,
> this is not an issue. I think existing UIs are plenty good if you learn
> to use them. I never waste any time scrolling through menus or doing
> redundant UI operations. Everything is set up to use macros and I can
> instantaneously do anything. I've thought long and hard about UI theory,
> and with current free software I've made an environment where I am in
> complete control and don't waste time with redundant UI operations. It
> took a long time to set up, but it was worth it.
I'm going to try to explain this as best I can. The paragraph you
wrote above, to you, looks like a perfect example of why you like the
system you use. You've taylored it to do the common operations
quickly, and find it functional.
The paragraph you wrote above, to me, or to other people on this list,
looks like a perfect example of why computers today are constraining,
limiting, and difficult to deal with.
What do you do with this 'environment' you've made? What useful work
does it perform for you? How much time did you spend learning to
control it, and how much time will you spend when you realize
something different offers better control? What do you think it could
do for you that it dosn't do today? What things have you not even
considered it doing, because you are used to its limitations?
> > * Spent rebooting. (kernel crashed, or we were developing the kernel)
> >
>
> Well, I think very few people writing software do this kind of work, but
> the GNU HURD addresses the reboot part of the kernel development cycle
> pretty good, by allowing dynamically loadable userland drivers and
> servers that can provide any service usually provided by a kernel such
> as low level networking and graphics hardware code that currently is run
> as root privelaged processes mostly in kernel space. And it is working,
> usable software right now to that you can use Emacs on and everything
> else. If it had PPP support (soon...), or if I had a real net
> connection, I'd try and use it as my default system. It's buggy, but
> there isn't anything so bad that I can't handle it.
You keep talking about specific scenerios, when we are talking about
making the software development process better. The Hurd does not fix
anything. The code which is in the "hurt kernel proper" still is
troublesome to write. They just moved the boundary of where drivers
are put, so that people can develop drivers from userland. However,
like most similar designs, they will pay the performance price.
I'm going to paint a picture here, make sure you read it all before
you start gettings ideas about what Tunes will do.
A better solution to the above problem would be to run your
'experimental' kernel in a software simulation of the machine. So that
you can test out new code in a safe environment. How do you do that on
Linux? Well, you probably down the source for bochs (an x86 emulator)
and compile it. Then you muck with setting up a bochs boot image from
whatever kernel image you are developing. At some point you may have
to write some bochs code to emulate some new device, and maybe push
that code back to the bochs people.
In Tunes, the idea is to remove all the 'implementation' dependent
work in the above picture. To draw a half-correct analogy, you would
merely ask Tunes to "run your kernel in a software emulation
environment", and it would do the rest of the above stuff for you. It
might need to know where to map input and output devices to (like the
emulated PC's screen), so it would either make some safe-choice, or
ask you what you wanted it to do.
> > * 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.
Back when people were using Windows 3.1 on 386 machines, I'm sure some
people said "I don't see how any system could make this more useful",
yet today, you can run Win95, WinNT, Linux, or Hurd on that same 386.
I believe you when you say that you can't imagine how Tunes can make
computing better. You don't seem to want anything different than you
have now. I'm telling you that _I_can_ imagine how computing could be
better, and I call that idea in my head Tunes.
I can imagine a world where when an HTML browser crashes, it dosn't
take down the other 29 HTML windows. I can imagine a world where I can
run some ActiveX plugin, whether or not I have an x86 processor and
Microsoft Windows. I can imagine a world where I can actually install
a new version of an application without breaking the old one. I can
imagine a world where I can just 'reconnect' to my desktop from any
terminal, anywhere.
And I'm not even talking about Tunes yet...
I can imagine Tunes, where I can ask the system for a list of all the
web pages I've seen in the last two weeks with the word "dog" in
them...where I can ask the system to cross-reference the list of
people I have had email or phone correspondence with in the last year
with the list of people that work at my new company to find out if
I've met anyone there before...where I can run out of disk space, pick
up a new drive, drop it on my machine, and have it say "10gb
available", no partitioning, no moving data around, nothing. Where I
can do all of the above without having to deal with 'installing' or
'configuring' even a single 'application'.
> > * 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.
>
> 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.
It's not like that. There are many optimizations which are much better
done by people who know about the hardware, then people who are
writing software. That's why you use languages like C, with C
compilers. Because the hardware people tell the C compiler people what
optimizations to perform. However, there are a whole bunch of types of
optimizations which can be done better if you change the software
model a bit. Go take a look at MIT's "Tick-C" pages.
However, it's not even about this (to me anyhow). It's about removing
all the add-hoc libraries and headers, and manual installation and
configuration which is necessary to actually use new optimizations, or
build with new stuff.
--
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net