[bane]

I've worked with a few visual dataflow language tools like this in the past, and there's definitely an important place for this kind tools in many environments -- this is beautiful work! I haven't had a chance to check it out yet, but just want to throw in some support.

One of the problems I've seen with these tools in the past is that they tend to live in very niche places and not get much public exposure. I'm very happy to see a publicly available tool out there.

[wdanilo]

@bane, thank you for your comment. It is very important to us to work with people who already have experience with visual languages, so please, stay in touch with us and use our forum / chat to tell us about your ideas! We would love to help you create things with Luna!

Your sentence about visual languages that tend to live in a very niche places is a VERY important topic to me. In fact I think I've got a very crisp answer why it is happening:

1) Visual languages are mostly not open and free.

2) Most visual languages are designed for a very specific domain use cases (like sound processing, 3d graphics, etc). People are afraid of limitations! Unless I'm 100% sure that I'm working exactly in this niche, if I want to process data / create software I would never choose a domain specific visual language, because the probability I'll hit its limitations are too high to take the risk. This is why we have developed Luna as a real programming language, so literally if you are able to do anything in C, you should be able to do it in Luna!

3) Almost every visual language is designed just as components you can connect. That's it, they are not tightly integrated with textual representation. This often makes working in these languages tedious - you have to create many nodes to achive what you can within a single line. In Luna, however, you can use any expression to create node. You can for example create node `(2 + _).sqrt`. You will get a node, which will allow you to connect one input and send data to the missing place in expression. It allows you to keep your graph clean and small.

Moreover, we have described in detail why current visual languages fail to succeed in our blog post here: https://medium.com/@luna_language/luna-the-visual-way-to-cre...

What do you think about it?

[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! :)