We needed to design everything from scratch to make sure the two representations are truly interchangeable. Every design decision in the textual language needs to be backed by its visual counterpart, and we found this way of thinking impossible with any other existing language.
Then there is the problem of complexity of existing, typed, functional language. We aim to make things as simple as possible, while not sacrificing the power of types, in order to make the language accessible for a much broader audience.
I'm super happy to hear that you like it, make sure to sign-up for our newsletter, so we can stay in touch once Luna is out :).
I would love to emphasize one of the thoughts from @kustosz reply: our main goal is to make Luna simple and intuitive yet very powerfull. We've got super cool type system on top of purely functional language, however we put our hearts to make the syntax (both visual as well as textual) very simple and intuitive. Neither of the mentioned solutions - Idris, PureScript nor Haskell, Erlang etc are "simple" and "intuitive" to use unless you are really good programmer.
I'm reading the Idris book now, and one cool thing there is guessing bits of implementation based on the type declarations (there written before implementation).
I imagine in a visual environment, being able to make useful suggestions on potential ways to use/combine different nodes/types would help as well as an auto-complete for the user's intent.
I bring this up because I see you covered visualizing the steps, while they focused on showing the data (though after finishing a transformation the script could be generalized into a reusable function). I wonder if adding a dimension like that could be helpful for Luna as well.
If you target non-programmers, showing things as concrete as possible (e.g. their data transformed by whatever function they just pulled together) sounds like it might help make things even more accessible.
