[bane]

At the moment I'm too swamped with other things to give this the dedicated look it deserves, but I'm going to try and get a couple of my staff to give it a look-see. We do lots of data processing tasks in different domains and often need to figure out and then establish long processing pipelines quickly.

One of the problems I think with these kinds of languages is that the dev environment and the run-time environment end up being the same. Which means that users of the pipeline also need to have the entire dev environment installed which rarely makes sense. (I don't know if that's true here, but it's something to think about). This compounds with the vendors of these tools are often stuck back in old business models and want thousands (or tens of thousands in some cases) of dollars for each license, even if all a user is doing is running a model somebody else built. It would be like requiring everybody who wants to run software on Windows needs to buy and install the entire Microsoft Visual Software development suites.

I really agree with #3, often these tools come with some kind of palette of modules that you wire together and making new modules is a huge pain or impossible. It looks like Luna is taking a very different approach. I think figuring out how to integrate the dataflow models into some kind of repository of library of models and provide some kind of change control is going to be really important as well as my experience is that these models usually end up being treated like Microsoft Excel documents and just emailed around and dying on people's hard drives.

[wdanilo]

We are constantly working on allowing Luna to produce executables as alternative form to interpretation mode. It will definitely be possible to output executable from Luna graph without requiring end-users to have any runtime installed!

Regarding point 3 - I do agree that well designed library management will be very important. We are right now designing it and are looking for people who want to help us implement it! :)