Reflecting on reflective computing.

[Christopher Barry]

David Manifold wrote:
> 
> On Wed, 21 Oct 1998, Christopher Barry wrote:
> 
> > We have language compilers for everything under the sun, and people
> > continue to develop these things and similar things so that they can
> > develop more development tools and it goes on... most development effort
> > in the free software community isn't focused on making the applications
> > that computers could actually allow us to do useful work with to
> > accomplish goals in the real world, but only to further the development
> > process itself, which is pointless.
> 
> People are probably writing new dev tools because it still is very
> difficult to write software.

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.

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

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.

> This is a main issue adressed by TUNES.
> Look at how long software takes to be developed.  Then look at how much
> work/time was:
> 
> * Duplicated, done before by someone else in some similar, or even very
> different product, because people were unwilling or unable to share code,
> or didn't know about the other project that they could have used code
> from.  We can't do anything about the unwilling, but we sure can about
> unable and ignorant.
>

In the free software community this isn't such a big deal/thing, since
there isn't really commercial competition. There is that whole GNOME/KDE
"duplication" thing over licensing issues but other than that people
usually extend and work on existing software rather than doing Their Own
Thing.

But I also know you probably meant duplication in the sense of OO, and
yes, I agree that OO is very important, but see below.
 
> * Realling making use of the programmer's skills, or was it just time
> spent trying to think like a computer (linearly)?
> 
> * Spent debugging.
> 
> * For the purpose of working around existing software or hardware
> limitations.

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

Similarely, it seems just now there are some decent MMX libraries for C
that you can include that help a little bit, but aren't a fraction as
good as doing it yourself, though they involve considerably less effort.
I don't see how in the development of your system you guys are going to
have methods available to you that make writing the relevant parts of
the compilers and translators that generate the loadable machine code
automatically more optimised for special processor features than what
the best painstaking efforts of brilliant minds with current methods
have produced and will produce. But of course, good luck.
 
> David Manifold <dem@pacificrim.net>