Mike J. Bell wrote:

Hey Kenny...I've got sort of a philosophical question for you. (I'm much more interested in the intent of Cells rather than the mechanics, even though the mechanics define the intent...I'm sure you know what I mean).

The spirit of Cells seems to be to very much like the declarative functional world of spreadsheets (ok, I cheated and actually *read* that in the docs. =). If I were to start a new project (and thus legacy code/app is irrelevant), why would I use Cells and not Haskell or some other pure lazy functional language?

If the answer is along the lines of "CL is super cool 1337 d00d, why use anything else" that's fine. What I'm digging for here is any major philosophical differences between using Cells (and I mean *using*, like building your entire app on as much Cells functionality as possible and not mixing paradigms)

aside: actually, I think it would be hard to mix paradigms. I always point out that Cells is a slippery slope: use them a little and pretty soon you have to use them for everything.

the paradigm is not "lazy functional", it is "dataflow". In my apps, all input gets fed into c-input cells, and all application behavior is manifested by def-c-output methods. The web of cells is a working model where slots have causal power over other slots.

The feel of the /programming/ is spreadsheet-y, but the result is, again, a working model. Working in the sense that one simply SETfs an input cell and the whole model reacts /and/ behaves automatically, according to the supplied rules. Of course, a spreadsheet is also a working model.

getting back to the slippery slope, I am not sure how one could combine imperative, programmer-oriented control with the automatic dataflow engine -- where would one put the hooks?

and purely functional, declarative, lazy languages. What's the discriminator?

Sorry, I have never used anything like Haskell, so I have no idea what it feels like or how to compare, other than what I said above. But maybe this will be close (my apologies if I am muddying the waters): if you have a lazy functional language, the control lies outside the declarative authoring, because, as I understand lazy, nothing happens until someone asks. So there must be a control flow programmed some other way (imperative?) which finally does the asking. In which case one is not really getting all the benefit possible out of the declarative approach.

kt