From: Julian Stecklina
Subject: COSI - Where?
Date: 
Message-ID: <86r7nrwwgl.fsf@goldenaxe.localnet>
Hello,

I found this really interesting page on cliki:

http://www.cliki.net/COSI

Is this code available somewhere? I would be thankful for any pointer.

Regards,
-- 
                    ____________________________
 Julian Stecklina  /  _________________________/
  ________________/  /
  \_________________/  LISP - truly beautiful

From: Kenny Tilton
Subject: Re: COSI - Where?
Date: 
Message-ID: <hcYdd.90215$Ot3.22128@twister.nyc.rr.com>
Julian Stecklina wrote:

> Hello,
> 
> I found this really interesting page on cliki:
> 
> http://www.cliki.net/COSI
> 
> Is this code available somewhere? I would be thankful for any pointer.

Did you try the authors at STCI? Mark Giuliano is one. I have followed 
COSI with interest since the LUGM '99 presentation and never heard of 
source being available, for what little that is worth.

kt

-- 
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
From: Julian Stecklina
Subject: Re: COSI - Where?
Date: 
Message-ID: <866553xf5g.fsf@goldenaxe.localnet>
Kenny Tilton <·······@nyc.rr.com> writes:

> Julian Stecklina wrote:
>
>> Hello,
>> I found this really interesting page on cliki:
>> http://www.cliki.net/COSI
>> Is this code available somewhere? I would be thankful for any
>> pointer.
>
> Did you try the authors at STCI? Mark Giuliano is one. I have followed
> COSI with interest since the LUGM '99 presentation and never heard of
> source being available, for what little that is worth.

Ok, I'll try to mail them. Thanks. You seem to be aware of your
competitors. :)

Regards,
-- 
                    ____________________________
 Julian Stecklina  /  _________________________/
  ________________/  /
  \_________________/  LISP - truly beautiful
From: Kenny Tilton
Subject: Re: COSI - Where?
Date: 
Message-ID: <QW7ed.91321$Ot3.26521@twister.nyc.rr.com>
Julian Stecklina wrote:

> Kenny Tilton <·······@nyc.rr.com> writes:
> 
> 
>>Julian Stecklina wrote:
>>
>>
>>>Hello,
>>>I found this really interesting page on cliki:
>>>http://www.cliki.net/COSI
>>>Is this code available somewhere? I would be thankful for any
>>>pointer.
>>
>>Did you try the authors at STCI? Mark Giuliano is one. I have followed
>>COSI with interest since the LUGM '99 presentation and never heard of
>>source being available, for what little that is worth.

Oops, that should be STSCI, and I think this might be a lead:

   http://www.stsci.edu/resources/software_hardware/spike/

They have a link there for inquiries: spike-support at stsci dot edu

> 
> Ok, I'll try to mail them. Thanks. You seem to be aware of your
> competitors. :)

:) And Mark was at my talk at ILC 2003, after which not one but two 
people described to me /their/ similar hacks. You cannot keep a good 
idea down.

The big diffs I see between Cells and COSI is that Cells allows 
different instances of the same class to have different rules for the 
same slot. That is the key to achieving true object re-use.

And COSI is all-lazy-all-the-time. I think that diminishes the 
look-ma-no-hands thrill (and productivity) of fully buying into the 
dataflow paradigm by letting it Just Work without the programmer 
worrying about when to propagate change.

Also, COSI does not have an on-change callback mechanism ala 
def-c-output, ne "echo".

kt


-- 
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
From: Kenny Tilton
Subject: Re: COSI - Where?
Date: 
Message-ID: <4Z7ed.91322$Ot3.9871@twister.nyc.rr.com>
Better?:

http://www.stsci.edu/resources/software_hardware/spike/obtainingSpike

kt

Kenny Tilton wrote:
> 
> 
> Julian Stecklina wrote:
> 
>> Kenny Tilton <·······@nyc.rr.com> writes:
>>
>>
>>> Julian Stecklina wrote:
>>>
>>>
>>>> Hello,
>>>> I found this really interesting page on cliki:
>>>> http://www.cliki.net/COSI
>>>> Is this code available somewhere? I would be thankful for any
>>>> pointer.
>>>
>>>
>>> Did you try the authors at STCI? Mark Giuliano is one. I have followed
>>> COSI with interest since the LUGM '99 presentation and never heard of
>>> source being available, for what little that is worth.
> 
> 
> Oops, that should be STSCI, and I think this might be a lead:
> 
>   http://www.stsci.edu/resources/software_hardware/spike/
> 
> They have a link there for inquiries: spike-support at stsci dot edu
> 
>>
>> Ok, I'll try to mail them. Thanks. You seem to be aware of your
>> competitors. :)
> 
> 
> :) And Mark was at my talk at ILC 2003, after which not one but two 
> people described to me /their/ similar hacks. You cannot keep a good 
> idea down.
> 
> The big diffs I see between Cells and COSI is that Cells allows 
> different instances of the same class to have different rules for the 
> same slot. That is the key to achieving true object re-use.
> 
> And COSI is all-lazy-all-the-time. I think that diminishes the 
> look-ma-no-hands thrill (and productivity) of fully buying into the 
> dataflow paradigm by letting it Just Work without the programmer 
> worrying about when to propagate change.
> 
> Also, COSI does not have an on-change callback mechanism ala 
> def-c-output, ne "echo".
> 
> kt
> 
> 

-- 
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
From: Julian Stecklina
Subject: Re: COSI - Where?
Date: 
Message-ID: <86lldx5y6y.fsf@goldenaxe.localnet>
Kenny Tilton <·······@nyc.rr.com> writes:

> Oops, that should be STSCI, and I think this might be a lead:
>
>    http://www.stsci.edu/resources/software_hardware/spike/

Thanks very much for the links! I am curious whether I can convince
them to give me access to COSI. :)

> The big diffs I see between Cells and COSI is that Cells allows
> different instances of the same class to have different rules for the
> same slot. That is the key to achieving true object re-use.
>
> And COSI is all-lazy-all-the-time. I think that diminishes the
> look-ma-no-hands thrill (and productivity) of fully buying into the
> dataflow paradigm by letting it Just Work without the programmer
> worrying about when to propagate change.

How would you compare Cells and COSI on one side to KR? (Except that
the latter is completely non-CLOS.) It seems to offer the same
"freedom" with the advantage (disadvantage?) of being prototype-based.

Regards,
-- 
                    ____________________________
 Julian Stecklina  /  _________________________/
  ________________/  /
  \_________________/  LISP - truly beautiful
From: Kenny Tilton
Subject: Re: COSI - Where?
Date: 
Message-ID: <TAued.92364$Ot3.54726@twister.nyc.rr.com>
Julian Stecklina wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
> 
> 
>>Oops, that should be STSCI, and I think this might be a lead:
>>
>>   http://www.stsci.edu/resources/software_hardware/spike/
> 
> 
> Thanks very much for the links! I am curious whether I can convince
> them to give me access to COSI. :)
> 
> 
>>The big diffs I see between Cells and COSI is that Cells allows
>>different instances of the same class to have different rules for the
>>same slot. That is the key to achieving true object re-use.
>>
>>And COSI is all-lazy-all-the-time. I think that diminishes the
>>look-ma-no-hands thrill (and productivity) of fully buying into the
>>dataflow paradigm by letting it Just Work without the programmer
>>worrying about when to propagate change.
> 
> 
> How would you compare Cells and COSI on one side to KR? (Except that
> the latter is completely non-CLOS.) It seems to offer the same
> "freedom" with the advantage (disadvantage?) of being prototype-based.

OK, now the person you have to talk to is Thomas Burdick. He is a big 
fan of KR and esp. prototypes. Last I heard he was trying to hack up (+ 
cells prototypes).

I have not looked at KR hard enough to get below the surface. I think 
the non-CLOS thing is the biggest issue for most fans. Syntax sure looks 
similar to Cells. I managed to make Cells a lot more transparent and 
powerful in that one does not have to use a special 
dependency-generating accessor to get a dependency established. The 
standard slot reader or accessor does that. So no matter how a rule 
dynamically ends up sampling a slot, either explicitly or through some 
function call, a dependency gets established. That makes the programming 
a lot easier and transparent.

KR offers a kazillion backdoors so you can shoot yourself in the foot 
with the constraint equivalent of GOTOs. If anyone likes that they could 
easily fork Cells to get it. My sense is that the huge productivity gain 
of Cells comes from playing within the constraints so the cell engine 
does all the work that falls back on the programmer once they decide to 
take causality into their own hands.

kt

-- 
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film