Where Tunes is going.
22 Oct 1999 12:19:31 +0200
>>>>> "Brian" == Brian Rice <email@example.com> writes:
Brian> So where is Tunes going? Arrow is Tunes. Any who disagree
Brian> are those who read my words (as codes) and mistake my
Brian> explanations for the idea. Many of you believe that we must
Brian> have an OS to boot Tunes from in order to have Tunes. I
Brian> agree on the fact that Tunes must make an OS framework (a la
Brian> OSKit) in order to extend its usefulness, but requiring an OS
Brian> to be on hand before we build Tunes is absurd! If the
Brian> OS-code is not available as Tunes objects, then it's not
Brian> useful, and therefore not Tunes.
>> I'm not sure to understand you, but as far as I'm concerned, it
>> is out of the question for me to develop device drivers or such
>> lowlevel things. That's why I am implementing the bootstrap
>> interpretor of OIL on top of Unix with C/C++
Brian> It sounds like you've completely missed the point. I'm
Brian> suggesting abandoning the *language* idea altogether as a
Brian> model for Tunes, and you state support by proposing your Open
Brian> Implementation *Language*.
Don't get fooled by the words. OIL is *not* a language as C or
Lisp. It does not have a builtin syntax. It should provide a means to
describe _what_ you want to do in the most abstract manner, without
having to care about the _how_ you want do it. It's not fully
implemented yet, but that's our goal.
Brian> That's absolutely absurd. Unless your language has no
Brian> inherent semantic content whatsoever, you're just feeding me
Brian> the same nonsense that I've seen from everyone else. It
Brian> sounds like you have the usual mis-interpretation that
Brian> assumes that Arrow is a language, and not a framework for
Brian> abstracting arbitrary information patterns. I'll even go as
Brian> far as accusing you of not being able to distinguish Arrow
Brian> from Lisp. If you can't prove that you understand the
Brian> difference, then you merely re-inforce my point.
Brian> Here is the line. Either cross it, and move on with Tunes
Brian> into history, or detract from it as you have been wont to do.
Brian> I will accept nothing else. I want Tunes, and I want it more
Brian> badly than Fare or Tril or any of you do by any stretch of
Brian> the imagination. Deal with it.
>> I want Tunes very very badly too. In a few weeks I'll be
>> starting up a company with a friend, and we intend to provide
>> support and services for Tunes. (We don't actually call it Tunes,
>> but the ideas are the same I think). I am working on a prototype
>> which you can download at
>> http://laurent.penguinpowered.com/~laurent/oip.html. I'd be very
>> glad to work with you on Arrow if I knew that we have the same
>> goals. But I still don't know what is Arrow all about. So if you
>> have a working implementation, or a few _real world examples_ to
>> show me, I'll have a look at it and see if my OIL is equivalent
>> to your ARROW.
Brian> Yes, you're right. You (and others) still have no idea what
Brian> Arrow is about. I've looked at your code, and it isn't any
Brian> more impressive than an open-source Maude or some equivalent.
It is not meant to be impressive. It's just bootstrap code and
experimentation for the moment.
Brian> And how can you ask me for a "working implementation" when
Brian> you don't know what the damned thing is for? I re-iterate:
Brian> it is not a language, it is a framework for migrating
Brian> information patterns with no inherent semantic content.
I ask for a working implementation because I still don't understand
what it's all about, so I need some examples so that my little brain
can get the idea.
Brian> And I've already stated that much work needs to be done to
Brian> even get the core constructs working properly. Once that is
Brian> done, even more work will have to be done to express some
Brian> fundamental libraries of theory in Arrow in order to make it
Brian> workable. This system won't be built in a day. But the
Brian> information it will manage once it's done will be more
Brian> powerful qualitatively than any programmming or
Brian> meta-programming system could make it.
Brian> I also disagree that you want Tunes.
Every body here has his own definition of Tunes anyway, so I think
that this kind of remark is useless.
Brian> I believe that I just expressed why a C coder will never
Brian> actually want to have Tunes. They would never support it
Brian> properly, even if it did exist. The fundamental difference
Brian> between coding and supporting Tunes spells it out quite well.
I don't consider myself a C coder. I'm using C/C++ to implement the
bootstrap interpretor for OIL because my first attempt with Tcl had
very serious performance problems. Once the interpretor will be
reimplemented in OIL, I won't touch C anymore. All will be done in
>> Laurent Martelli firstname.lastname@example.org
Brian> Thank you for underscoring my point that no one on the Tunes
Brian> list has done the work to learn what my (or Tunes) ideas are
Brian> really about. I suggest you re-read the Arrow Introduction
Brian> paper or get on IRC and meet with me to discuss this.
I'll have to learn IRC one day ...