Replies to replies.

[Tril]

On Fri, 23 Oct 1998, Christopher Barry wrote:

> But as I read more and more, the state of things began to sink in. The
> list seems to serve only as breeding ground for new ideas and a
> playground to toy with some existing ones. The state of things in my
> scope of interpretation is that you guys are not working towards some
> common end, but each have your own idea of what Tunes is and your own
> idea of how you will ultimately build it in your own way hopefully
> eliciting the help of others to do it your way. There seem to be
> differing opinions of what is realistic for it and what is not.

I hope that this forum can be used so that we CAN help each other do it
our own way.  Differing concepts are good.  Even if we don't end up at the
same place, we have a LOT in common and we should work together.  It's in
our mutual interest.

> David Jeske has thrown around some _very_ good ideas that do away with
> much of the UNIX paradigm but don't necessarily have to describe a
> system that will access a CD based on a tune you whistle, or anything
> else like that. You could just rip away what is a retarded way of doing
> things with current systems by using current tools and technology.

I think we will do both.  We can do the more basic stuff first, since it's
an obvious requirement for complex stuff, like the whistling.  Accept no
limits, and see how far you can go.

> I was expecting to find a community working on a project in the sense I
> am accustomed to in the Free Software community, but you guys are not
> working on this in that sense, which threw me off initially but now
> everything has kinda sunk in.

As Brian Rice said, we haven't the terminology yet to define a central
project.  However, we are (at least I am) working on it.  I am trying to
unify my terminology with Fare's, by working on his web pages.  Hopefully,
Brian, you will help me with this by adding your own input on the
terminology from your own ideas.  This way our web pages can be a
"specification" that perhaps we can independently implement.

I wouldn't have minded waiting longer, to materialize the specs further,
but I see a lot of desire for something resembling progress, and I don't
think starting separate projects is worse approach than the other.  After
all, we are doing something that has never been done before.  Who is to
say one way is better than the other?

> [about tunes.c and lisp]

I'm just glad that somebody even looked at my tunes.c.  Yours is the first
comment I've gotten about it.  Remember, the snapshot for tunes.c is on
the "release early" (release often, too, when I am working on it) model.
Don't expect it to make any sense...

> [foo.c challenge]

I'm not sure how helpful the foo.c challenge was for understanding TUNES.
It was fun, and it did demonstrate very well C's lack of reflection, but
that's not the same as demonstrating how to do reflection well.  Perhaps
you could explain more how you thought it would be used.

> [AI stuff]
>
> But if you want to replace /usr/local/bin and other static and dumb
> concepts with something better there's no need for any of this crap I
> just talked about, it's all relative to what your idea of Tunes is.

The "idea" of TUNES is not discrete.  That is, it encompasses all of
computing and everything anybody might want to do in computing.  So, TUNES
doesn't end, and there is no computing idea inapplicable to TUNES.  If AI
is only one aspect of computing, then it is only one aspect of TUNES.
Don't mix up intelligence with comprehensiveness!

 > > There will always be a case where humans are required, no
> > matter how elaborate or intelligent of algorithms are used.
> 
> I have to disagree here because sufficiently elaborate or intelligent
> algorithms are mechanisms that can be just as good as the ones we
> ourselves use. It does not require a system of mechanisms as
> sophisticated as the HAL 9000 or able to pass a Turing test to generate
> proofs of program correctness. It does not have to require human
> intelligence.

You are right, because of the "just as good".  Humans can't prove
everything that is provable.  Computers may be "just as good", which means
they can't prove everything either.  (keyword=decidability.  Search the
list archives for 'decidable' for more in-depth discussion.)

The problem of decidability then provides absoluetely no evidence one way
or the other as to whether computers could replace humans.

I believe humans will always be needed because computers can't come up
with new, useful ideas.  That's all the reason we need.

> > Orthogonalization of specification and implementation:  The specification
> > is given priority.  Implementation is dynamic, changing based on resource
> > constraints, but always conforming to the specification it is attached to.
> > A specification is a high level description of something.  The
> > implementation is a mapping from the description onto the low level 
> > machine's domain.  Generation of the implementation is attempted
> > automatically, and uses hints from the human when necessary.  In addition,
> > the implementation can be adjusted manually to override the automatically
> > determined parts when you have better ways or just want to try something.

> I wish I had a remote clue about how to sit in front of XEmacs and start
> writing stuff to make this work, do any of you? This is very
> interesting, is there 90% agreement that this is correct, and can each
> of the above sentences therefore be further defined and more precisely
> specified?

Whether there is agreement or not, that is part of the TUNES specs.  If
you don't agree, that's not TUNES.  

More precise specification of the system is in the works.  Be patient.

> > The system will be complete when these goals are accomplished:
> > * a powerful, extensible, abstract specification system
> > * extend it to specify low-level hardware
> > * extend it to specify translation from itself to low-level hardware
> 
> These things themselves are kind of abstract, but is there 90% agreement
> among you guys out there that this is so far correct? Can we try and
> focus and unify the effort more, or is this not possible for many
> reasons?

This is the approach I intend to use.   I think it should be done that
way. I don't think it's the only way, and since we're using more than one
simultaneous approach to implementation, Brian and Fare are free to do
something different.  I know my approach uses less steps and less
temporary layering than others would like.  So it could be harder, but it
could also save me development time.  We'll see...

> [AOP is incomplete solution]

The separation of spec and implementation, above, allows top-down control
of the meaning of objects (their semantics), while freeing the
implementation to be optimized without changing the spec to be confusing.
I think this separation encompasses aspects.  It may be a definition of
what aspects are.  I've only looked at aspects very superficially; Brian
(or anyone), do you have more experience with aspects and care to comment?

> > 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.
> > 
> 
> In Lisp you can declare an integer to have any range you care to define,
> it can be a truly astronomical value. Yes I do agree with the rest of
> what is said, but which of these languages that go further that are
> available today will Tunes use?

Brian looked at more languages than I did, and he is using C.  I am
using C.  Fare is using Scheme.  Neither language can describe TUNES, but
we can try to approximate something resembling TUNES and use that
something to approximate something more resembling TUNES... and so on.
That seems to be the common approach of all three of us.  (Correct me if
I'm wrong)

> > I'd be content if we (as the software community) could just write a
> > block of code to (say to decode a new image format ) _once_ instead of
> > 50 times. (once for Linux in netscape, once for windows/activeX, once
> > for MacOS, once for BeOS Datatypes, once for Java, etc, etc)
> > 
> 
> Yes, this a really good goal, and doable, though insanely ambitious.

To realistically do this (which I agree is our goal), we need a
"superlanguage" which is more expressive than every other language.  In
this superlanguage other languages are implemented, then automatic
translators are made between them.  Programmers should ideally write any
new code in the superlanguage itself.  Programs in the superlanguage can
combine concepts from any of the lower languages.  Of course, programs
that do that will not be fully translatable into the less expressive
languages.  The superlanguage itself will not require any of the other
languages to run.  It will include the machine hardware as one of the
sublanguages, and translate directly to that.


> My thinking is that more ultimate progress would be having the word
> processor have real intelligence mechanisms, and AI is the enabling
> technology for this.

You'd have to be more specific.  I'd be satisfied if my word processor
wasn't an isolated module, but was just integrated with my system.  

> Anyways, I'm gonna stop following the list and posting for now (all of
> this is taking _a lot_ of my time), but I'm gonna check back month to
> month (not necessarily post, just lurk) to see if you guys maybe have
> come to more agreement on a few things, and maybe a more practical idea
> of Tunes, in what is in my opinion practical anyways.

Sorry for following up your posts, take as much time to reply as you need
(if you want reply at all).

David Manifold <dem@tunes.org>