281–290 of 331 posts
Isn't it similar to what Eve tries to achieve? Well, what I like in overal, is an attitude and courage to introduce new technologies! I come from the Red language camp, which if I am not mistaken, is also being funded. So - good luck, guys :-)
Earlier quoted context omitted.
> The problem I have with static typing (as widely implemented) Mainstream type systems are best ignored. If it doesn't have sum types, it's not a good type system. If it doesn't have generics, it's not a good type system.
More flexible static type systems can help, but they don't address the fundamental problem that they are trying to make a strong statement at development time about something that isn't known until runtime. This pushes dealing with the problem (of what if something isn't the expected type/is malformed/is missing/is incomplete) to the wrong place, causing unnecessary complexity, dependencies and bugs.
if true then 1 else "one"
So in the past I have used two self-proclaimed "visual programming languages", Blueprints[1] and Max[2] and in both cases I found that it is actually harder to be productive while dealing with UI elements than it is to simply write code (as long as you have at least some rudimentary form of autocomplete I guess). However I have to say that, based on the little I've seen, Luna's UI seems to be actually developer-frien…
Max does allow you to use JavaScript or Java and they are doing a lot right now with JavaScript interop/export.
OK, could you define this?
data Eq : {a : Type} -> a -> a -> Type where
Refl : Eq x x
sym : {x : a} -> {y : a} -> Eq x y -> Eq y x
sym Refl = Refl
replace : {a : Type} -> {x : a} -> {y : a} -> {f : a -> Type} -> Eq x y -> f x -> f y
replace Refl p = pEarlier quoted context omitted.
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 sacri…
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…
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'm actually also a bit reminded here of MS Excel Power Query, which also offered a GUI for data transformation, see e.g. [this pic](https://blogs.office.com/wp-content/uploads/2015/07/6-update...).
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.
Earlier quoted context omitted.
I mean, I don't care if you keep it as Luna. Just saying you're gonna have problems if you keep that name
I completely understand that, but we care about it very much and don't want to have problems with it. Because of that I asked about help with the naming :)
Here goes some suggestions: https://en.wikipedia.org/wiki/Phoebe_(mythology) https://en.wikipedia.org/wiki/Zana https://en.wikipedia.org/wiki/Notus https://en.wikipedia.org/wiki/Jaci
Earlier quoted context omitted.
How did you convince VC-s, that there's need for a new programming language? (I'm totally not saying there's no need, but since it's highly technical and I probably would fail at it I'm really curious)
We are not really making a programming language. So, err.. ok, we are. But it is "just" an engine. Luna is a data processing platform. It allows you to prototype, design and deploy data processing applications much faster than it is currently possible, while working in an elegant, interactive data visualization environment. Moreover, we are supported by many cool companies that want to use Luna for their purposes, in…
I love the visual/textual dual language concept - I've been trying to figure out a good solution where both work well and no information is lost from one by editing the other (eg if I create something visually, but edit it textually, does the layout get ruined?) and, at a glance, you seem to have largely solved this or at least managed to get it working well enough. Awesome.
I also like this as a tool for data processing. This kind of platform is something I've been wanting to build (and prototyped once a number of years ago even) for a long time. Couple it with a simple (and familiar) spreadsheet system and your golden (for my purposes - other people may think otherwise).
I haven't looked at Luna in any detail yet, really just glanced at the screenshots so far (I hope to read the material properly tomorrow), but one concern that jumped out at me was that the visual language semantics aren't clear to me. Of course, its probably unreasonable to expect to understand a new language without having read the documentation, so its unlikely to be an issue. I only point it out because I've seen a number of other visual languages claim to be super user friendly (even to non-programmers in many cases), when, IMHO, it really isn't unless you already deeply understand the concepts. I didn't see you making this claim though, so all good :)
Overall, I'm excited for this and wish you the best of luck. Hopefully you will choose me for alpha access so I can play with it ;-) :-P
Hi guys! My name is Wojciech Danilo and I'm one of the founders of Luna. The timing for this news is a little unfortunate, because we are just before releasing Luna as an Open Source project! However, it's great time to answer some questions and give you a short update what has happened for the last couple months: 1. We've raised a seed round of $1M, so we can safely focus on product development and shortly on commun…
Because I gave this some thought as well and don't see why not in general, but I don't know how luna works .. or if there are some restrictions I did not encounter yet ..
Earlier quoted context omitted.
If I had to guess, I would point out that JavaScript was originally hacked out in 10 days, and features a number of unforgivable flaws, such as a non-transitive equality operator, weird implicit conversions, or just plain trying to make sense of quite obviously nonsensical operations. To someone used to the mathematical rigour of typed functional languages, this is not even worth looking at. As far as I know, the suc…
No one is using the language Eich wrote "in 10 days" anymore, so that's a ridiculous comparison to make. You're dismissing all the effort TC39 has put into improving the language for many years.
Hi guys! My name is Wojciech Danilo and I'm one of the founders of Luna. The timing for this news is a little unfortunate, because we are just before releasing Luna as an Open Source project! However, it's great time to answer some questions and give you a short update what has happened for the last couple months: 1. We've raised a seed round of $1M, so we can safely focus on product development and shortly on commun…
You said, other languages can't really directly be transformed to graphical luna nodes, can you say why? Because I gave this some thought as well and don't see why not in general, but I don't know how luna works .. or if there are some restrictions I did not encounter yet ..
If you are thinking about visual language you have to think about many constructions that collectively give you user experience, including available basic construction blocks (how looping, branching works etc), structures, lambdas, every language construction, how you give hints to user what is possible and what is wrong and additionally how to do this real 2 way transformation of code and graph.
Luna infers types and displays colors according to them. We use algebraic data types, lazy evaluation, pattern matching and purely functional paradigm which suits graph visualization really well. We fine tune performance by allowing lazy data visualisation and many, many more things. I don't know how we can even visualize standard OO abstractions to be usable and pleasant to work in the visual form. It does NOT mean we did not think about it. We did for a long time.
Sure you can utilize Luna gui to visualize anything, including python code, but it would be insanely hard to deliver similar functionalities to what Luna offers out of the box (which is available by careful design of both representations).
I feel thin answer is very vague, but I hope I put a little light on how complex this task is. Did I answered your question (at last partially)?
