Replies to replies.

[Christopher Barry]

I just want to clear up some misconceptions, and also give specific
replies to several points and statements made in replies to postings of
mines.

Firstly, Linux sucks for a billion reasons, but some of the areas in
which I've seen it attacked I feel are not very deficient. I am by no
means a Linux weenie troll, and if specific interpretations of my prior
words have been formative in such an opinion, then I am sorry.

Secondly, none of you are Clueless or confused or anything like that.
All of you are extremely intelligent, and I remember when I first
discovered upon the Tunes page several days ago how impressed I was with
a lot of the ideas being thrown around and how much of this had
coincided with a lot of ideas I had been throwing around in my head, and
I remember feeling frustrated at having not discovered the page earlier.

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.

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

I was in the process of preparing some posts that further critised
various aspects of the work being done, for example how David's not far
from 1000 line tunes.c could have been written in I estimate under 300
lines of code using Lisp (saving still wouldn't work, but using real
command names instead of numbers would be much more trivial), and how a
number of errors in the current version such as all the cases that
result in infinite loops could have been avoided with my approach, and
then critize C for being the wrong vehicle, and then show how my Lisp
example is deficient and wrong to, and how it does nothing for creating
a system with the properties of Tunes. Lisp is the wrong vehicle to.

But my example was turning out to be a lot of trouble and a big PITA,
and I don't know what kind of audience I would have for it either after
actually finishing it and getting it to work.

There's another interesting one you guys can do to, if you never have.
Try writing a program that produces as output an *exact* copy of it's
source. For example, you write a file called foo.c, then:
$ cc foo.c -o foo
$ foo > foo.c

You'll get the *exact*, byte for byte, source file you started out with
(okay, the file's date can be different, you know what I mean). If some
of you have never done this exercise, try it. It requires little code to
get to work, but it's not trivial to do, IMO. I had a hard time with it
anyways, but I'm sure some of you are more skillful than I.

If all of you are capable of whipping out the code to do the above with
a few seconds of thought (provided you haven't commited the solution to
memory from prior experience), well, I suppose I wouldn't be too
surprised, but the point is that I would like to somehow communicate to
you guys in a constructive way some of the obstacles you will face when
the real coding begins. If this doesn't give you an idea, ask me to
provide more examples of conceptually simple things that require little
concrete substance or code for an actual implementation but are very
difficult to implement because of the current reasoning and programming
paradigm and deficiencies with how mankind thinks and reasons and what
kind the computer interaction and programming paradigm is needed to
resolve these problems, then think about how you have difficulty even
*conceptualizing* certain ways some of the versions of Tunes described
will do things (what I keep on trying to say is that I understand how
you want to change the programming paradigm with Tunes and that the way
everything is currently is screwed up, but you're going to have to write
Tunes with the way everything currently is, and in my opinion this is
kinda futile for some of the versions of Tunes I've seen described, but
maybe not at all futile and a worthy, achievable goal for other versions
or good properties I've seen).

Anyways, some replies.

Tril wrote:
> 
> On Fri, 23 Oct 1998, Christopher Barry wrote:
> 
> > AI is what you need to prove program correctness.
> 
> No.  Intelligence is required to generate proofs of program correctness in
> many cases.

I hope you read the relevant pages I fingered earlier on as I'm
essentially paraphrasing. I'll begin by saying that though the term is
"Artificial Intelligence", there is nothing artificial about the
intelligence, it's the real deal. Now let's begin here by defining what
intelligence is.

Intelligence is the computational part of the ability to achieve goals
in the world. Is intelligence a single thing so that one can ask a yes
or no question, "Is this program intelligent or not?"? 

No. Intelligence involves mechanisms, and AI research has discovered how
to make computers carry out some of them and not others. If doing a task
requires only mechanisms that are well understood today, computer
programs can give very impressive performances on these tasks. Such
programs should be considered "somewhat intelligent". 

Most work in AI involves studying the problems the world presents to
intelligence rather than studying people or other things that exhibit
intelligence. 

Proving the correctness of a program is a problem that the world
presents to intelligence.

Using AI mechanisms and set theory and systems of logic, program
correctness may be machine provable to a great extent, without requiring
many of the mechanisms of intelligence exhibited by humans, as well as
the system of proving itself able to prove it's own correctness.

But this is extremely difficult to deal with and approach and not
something I'm sure I want to personally try and tackle right now, but it
is prerequisite that a system of AI mechanisms that can handle proving
correctness be in place before a lot of real rapid advancement of the
mechanisms themselves and similar AI mechanisms, such as those that can
take the whistling of a tune and play a matching tune from a database
'indexed' if you will with intelligent mechanisms themselves. There's a
lot of chicken and egg here.

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.

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

> > [The Hurd]
> 
> I read into your words that you think TUNES will take even longer to
> implement than the Hurd because it is more ambitious. Who cares?  Why is
> imlementation time relevant at all?

Implementation time is certainly relevant if it is not a finite value
<grin>. Okay, seriously now, in 50 years I'm willing to bet we will have
stuff better than the HAL 9000, and a system like Tunes would be
pointless by then. Will Tunes be useless in 20 years. Depends on what
versions I've seen discussed.

Have you ever seen MS Visual C's wizards that generate most of the code
for you? Things like these are bound to improve, and software technology
as a whole will continue to advance. A sort of ultimate goal I think we
all can agree on is that we'll have machines that can pass the Turing
test eventually. I can see systems like Tunes being developed along the
way towards that goal as a natural progression of software technology.
As the bulk of the Free Software out there becomes just as easy to
install, use, and maintain as the best systems out there and we have
nearly all functionality of commercial applications available, people
are going to be wondering what needs to be done next, and they are going
to start thinking about stuff similar to Tunes. I bet 20 years from now
the GNU operating system will embody all of the functionality of Tunes,
since that is the only direction to move for further improvement.

If you guys don't get a decent implementation within the works within 10
years, the bulk of the Free Software community will start work on one
within 15 years from now anyways.

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

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

David Jeske wrote:
> > 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.
> 

I hope I covered this above well enough.

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

I did try and look at AOP awhile back. At the Xerox PARC site I read
through this huge license and signed up to download their AspectJ
software, and then found it is MS Windows only. I informed them of the
fact they don't mention this before the painstaking sign up process and
got a polite email back that the'll update the information on their page
to reflect this fact but don't have plans to make it run under anything
else. Oh well, I did read through the docs and tutorial a bit and it
looks interesting, but it's not a very complete solution. I've seen Self
as well. I've never heard of Handel-C, and would like a URL to more
info.

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

> > How would you argue that Tunes is a necessary prerequisite though, I'm
> > curious. This could get very confusing and technical very quickly. I
> > would argue that intelligent components and algorithms and compiler
> > technology are a necessary prerequisite to the Tunes system. Chicken and
> > egg.
> 
> In my opinion, your analogy is flawed. To me, the idea of developing
> an 'intelligent' computer with today's technology is like developing
> the internet before there is written language to communicate with on
> it.
> 

I fully, 100% agree. Remember my analogy way back of programming
Netscape in machine code through the front panel of a mainframe? With
most of my posts I was suggesting the development of mechanisms with
today's tools that could be used to implement Tunes as some of the more
ambitious envision it.

However, there is no need if more readily and realizable goals for the
system are agreed upon instead (e.g. none of this whistling stuff, but
no more static filesystems and stupid shared libraries and other good
ideas that are totally doable, and still classifiable as insanely
ambitious).

> > really am feeling kind of content for the first time, and am really
> > examining what needs to be done ultimately for real progress, and that
> > is AI.
> 
> Interesting.. I think there is alot of stuff between here and what I
> presume you mean by AI. (I presume you mean some kind of intelligent
> computer you can talk to, and which can perform tasks you ask it to
> do, etc)

No, those mechanisms are way to advanced for current methods. More
simple AI mechanisms are needed, and ultimately the proving stuff I
talked about above. But again, none of this is needed to really change
the paradigm and do away with a lot of dumb stuff with unix and the like
today.

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

> > No, I have an idea about how it could be better, but the same processes
> > no longer apply to make it any better, and there are no more trivial
> > things to improve, IMO. But I don't see how Tunes solves some of the
> > fundamental AI problems that need addressing for real progress.
> 
> You seem to be stating that you think AI is the enabling technology to
> bring software to the next level. I don't know that I agree with you. 

I don't think I agree with that statement now either. We could get rid
of a lot of the 1970s crusty unix crap without any of this stuff and
that would be real progress. But my original thinking was that doing
away with the unix crud that is Wrong still doesn't give us
automagically for free applications that really do more than current
ones. They might be easier to write, require way less effort to extend
and maintain, and be way more configurable, so that the user can say do
their word processing in more peace and never have customization or
incompatibility or configuration woes, but the word processing itself is
still pretty much the same. just comfier and more refreshing. 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.

> > How about it doesn't crash in the first place. It's called Lynx, or
> > Emacs W3, but they kinda suck compared to Netscape. And yes, Netscape
> > does crash....
> 
> Come on.. I can't believe you are sitting there telling me that Lynx
> or Emacs W3 are somehow gifted by a higher-being to 'not crash'. All
> software has bugs, thus all software can crash.
> 

And what will be the consequences of bugs within Tunes? How do we write
Tunes to be bug free without the proving mechanisms I discussed?
Debugging Tunes is gonna be unlike any other kind of debugging
experience....

And on a side note just because a large app has bugs doesn't mean it
needs to have bugs that cause it to crash. There really are some big
programs out there that never, ever crash that I think never ever would
within the scope of what they are able to do to prevent it (if the
kernel corrupts the memory of the application's address that's not the
app's fault).

> > For it to list all of the web pages that have "dog" in it that
> > you've visited in the last 2 weeks, it would have to either store
> > all of those pages on your disk, or visit every URL in your history
> > file when you ask which would take forever, and could also be easily
> > done with some Perl anyways that wgets the URLs in your history and
> > then matches the REGEXP with every page it retrieves.
> 
> There is probably not a single example I can come up with which you
> can't "explain" how I might do it with some custom perl script, or
> something else. However, in tunes, you won't have to write some custom
> perl script. You will just ask the system to index every webpage you
> ever see, and it'll do it, and later on you can search the index. No
> pathnames, no perl scripts, no custom web browser to throw the pages
> you view into the index, none of that UNIX pain.
> 

Well, you could write an application on existing systems that you can
ask the system in a friendly way to index every web page you ever see.
:) Okay seriously, I see your point that with Tunes you don't need to
write the application that does this because this functionality is a
result of the underlying architecture and functionality, and I don't
think you would need really robust AI mechanisms to do this either but
it would be a real PITA to get functionality like this 'automatically'
instead of taking the few minutes to write it specifically. I don't
think this functionality needs to be present in an initial Tunes
release, the infrastructure should be there to support it without any
major rewriting though, and that is doable (again insanely ambitious).

A lot of your other ideas in that last email David were really, really
good and more practical and achievable to I felt. I tend to think you
have the most real world programming experience of those here (but if
I'm mistaken, you other guys can speak up).

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.

I hope you all don't forget to try my little program problem though,
the:
$ cc foo.c -o foo
$ foo > foo.c

one that gives you the exact same foo.c you started out with. It might
humble a few of you, but insult the intelligence of others I suppose(ask
for a tougher one then :). Anyways guys, good luck with it all.

Christopher