[admin] Cello, too?

[Kenny Tilton]

Nikodemus Siivola wrote:

>On Sat, Nov 08, 2003 at 01:14:04AM -0500, Kenny Tilton wrote:
>
>  
>
>>>"Should Common-lisp.net host multiple projects with greatly overlapping
>>>objectives?"
>>>      
>>>
>
>  
>
>>I have zero problem with doing all this under one project (I'd just have 
>>    
>>
>
>Heh. ;) That was actually a reference to multiple GUI-projects, as we
>already host Mario's lgtk (GTK for CL) project.
>
Oh. OK, looking back then to:

>For what it's worth, I think yes. Common-lisp.net should be a fertile
>ground where most flowers can bloom. 
>
>Once we have MORE CODE we can start sorting the wheat from the chaff,
>but even then Common-lisp.net isn't probably the place to do it.
>  
>
<heh> I can tell you already that I will continue the open thing only 
if  others vote for it with their support. It is too much trouble 
otherwise. So there should be a nice self-selection thing going on. If 
resources are scarce you might want to evict inactive projects (I'll let 
you know if I pull the plug, btw.) Over on SourceForge I think there are 
tons of projects that never got further than being created (mine 
included until recently).

It is interesting to see selectivity (by the admins) even being 
considered. You'd have to update the mission statement to "open source 
boutique" or something.

>>separate bundles/directories/whatever for Cells and Cello) and it might 
>>even be a lot more manageable that way until/if one or the other catches 
>>on. I can see myself over on a Cello list saying, "Oh, that's a Cells 
>>    
>>
>
>...I really think they're stunting each other already. Take me for
>example: I'm definitely interested in Cells, but could not currently
>care less for Cello. ;)
>
POI: "stunting each other"? You mean Cells is hurt by the Cello thing, 
in that one gets the idea they are inseparable? The names are almost 
inseparable, maybe that's the problem. I know I have encountered 
confusion in others on that score.

>>One project, then? :)
>>    
>>
>
>As an admin: "Your choise." 
>
>As a lisper: 
>
>  I haven't looked at the codebase, so I have no idea of the boundaries
>  between them -- so this is rather theoretical. ;)
>
>  Cells is a "dataflow oriented extension" to Common Lisp, in a sence
>  analogous to CLOS. I think that if the paradigm and ideas of Cells are
>  universal enough, then Cells (or another implementation of that paradigm)
>  has the potential (yes, I know this is unlikely) to become "another
>  CLOS" on the long term.
>
Aside: I think it is very likely the dataflow paradigm will prevail, and 
I /know/ Cells won't because a fundamental rewrite is planned (and 
needed), and in the end brighter folks than me will have to find the 
Right Way. Dataflow is the Lisp of paradigms, first implemented in 1962, 
then Steele tried again with his PhD thesis cum language in the 80s, now 
Garnet and RETE and COSI and Cells and a couple people that approached 
me at  ILC2003 with news of their own similar hacks.

Back on topic: right, this has nothing to do with GUI, per se. GUIs are 
just the killer app for Cells.

>
>  Cello on the other hand seems to be at least three totally different
>  projects rolled into one: 
>
>   1) An experimental CLIM-like system based on Cells instead of CLOS.
>
? Cells extend CLOS (and defstructs are on the way). Cello is all CLOS 
all the time.

>
>   2) A backend for the above, built on top of OpenGL.
>
>   3) OpenGL bindings for Common Lisp.
>
>  Now, *if* these perceptions are correct (I'm largely guessing here),
>  then there really should be three projects if the CL community were to
>  reap maximum benefit from all this:
>
>   Cells, Cello, cl-opengl
>
God, I'd love a cl-opengl, tho I have enough bindings done to keep me 
happy for a while. But I ducked the scary ones. :)

>.. people who certifiably are writing open CL
>stuff instead of just alking about it. 
>
don't get me started. <serious>

 :)

kenny

-- 
http://tilton-technology.com

Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film 

Your Project Here! http://alu.cliki.net/Industry%20Application