Where Tunes is going.

[Laurent Martelli]

>>>>> "Brian" == Brian Rice <water@tscnet.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
OIL. 

  >> Laurent Martelli martelli@iie.cnam.fr

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

-- 
Laurent Martelli
martelli@iie.cnam.fr