| @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? |
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.