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:
- 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.
A backend for the above, built on top of OpenGL.
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