wdanilo

Hi, I'm Wojciech, one of Enso founders! We are just preparing for Enso 2.0 release. If you want to play with it, you can download the current build from our GitHub releases page (https://github.com/enso-org/ide/releases) and see intro tutorials here: https://www.youtube.com/channel/UC4oMK7cL1ElfNR_OhS-YQAw :)

Hi, congratulations on the release! I admire your dedication - the amount of work you had to put in this project as a single developer is huge. I'd love to chat, but I can't find any contact info, would you be so nice and just ping me via wojciech.danilo@enso.org? :)

Hi, Enso team here! Luna 1.0 (long time ago) had serious uninstall problems on Windows because of auto-restarting daemon processes. It was fixed long time ago. Enso uses a completely rewritten services architecture (as well as rewritten compiler and GUI) and something like that should never ever happen again.

In case anyone is interested, here is a more formal description of positions we are looking for: https://github.com/luna/hiring

LUNA (http://luna-lang.org) - write to us! :)

I'm one of the founders. We are looking for senior compiler engineers (GraalVM) and senior WebGL developers (Rust ) in our team. We are doing a visual programming language for data science and we just got funding of $2.5M. We'd love to chat :)

Hi! I'm Wojciech Danilo, one of the founders behind Luna language ( http://luna-lang.org ). I'd love to share with you our blog post about why actually visual programming languages could be very useful: https://medium.com/@luna_language/luna-the-visual-way-to-cre...

We've been building visual languages in the past for people in different industries, including Visual Effects one. Watching people with limited programming skills to create outstanding things on their own is truly amazing.

Topkai22, I love your attitude. This is exactly how we should look at visual programming languages. They allow people to create something, which was so far not accessible for them. In surprisingly many cases, it's completely enough!

I also understand why people dislike this idea. In many cases, it's really hard to extend something created by non-professional-programmers. I'm one of the founders of Luna ( http://luna-lang.org ), which is a visual programming language blending the boundaries between visual data-flow designing and conventional textual programming.

As a contrast to the mentioned article in this topic, I'd encourage people to also read our blog post about why visual programming could actually be very useful: https://medium.com/@luna_language/luna-the-visual-way-to-cre...

Thank you jakelazaroff for mentioning Luna <3 ! We, at Luna, are trying to blend the difference between text and visual programming, allowing people to choose the best tool for their use case – visual representation for high-level system modeling and textual representation for low-level components.

Personally, I've been creating visual programming languages for years for such domains as visual effects, allowing artists (people with very limited / none programming skills) to create outstanding physics simulations systems or automated geometry processing by their own. Seeing people being able to create something that was so far not accessible for them is amazing.

Readers of this topic might also be interested in reading our blog post about why visual languages are actually very useful here: https://medium.com/@luna_language/luna-the-visual-way-to-cre...

Hi guys! I'm Wojciech Danilo, one of the early Flowbox founders. I'm not actively working there right now (I'm working on http://luna-lang.org), but I truly love these guys. They are brilliant engineers, full of passion and they create an awesome software.

Flowbox is a node based VFX platform allowing for the fastest rotoscoping and image compositing on the market. If you like Houdini-like workflow, you should fell in love with the ideology here. Seriously, check out the video: https://www.youtube.com/watch?v=hwLcevH1VH0

There is a live webinar about Flowbox by Mikolaj Valencia (CEO) TOMORROW here: https://web.facebook.com/events/666426783714447 , so please join us there!

We'd love to answer any questions here as well! Thank you for your support! :)

Thank you <3 Btw, please help us with anything you can. We are working hard to bring (spoiler alert!) Luna 2.0 to reality and any help regarding documentation, tutorials, integrating Python / R, libraries in Luna, gui widgets is more than appreciated!

It seems that this problem is connected to firewall / blacklisting. Please contact us and we'll figure out whats happening.

There are some other lessons too, especially regarding Haskell. Basically the sad truth is that if you do not benchmark literally every single line, you can suddenly get MUCH worse performance than expected. Sometimes GHC's strictness analysis does not discover that it can unbox some things and you land in a boxing-unboxing loop or you hit some of optimization bugs (during the work on performance we've reported over 10 GHC bugs and even implemented our custom graph memory manager). So one of the biggest problems that we encountered earlier was that actually the GHC performance is MUCH harder to predict than you think and you have to take extra care of it while building your software. Of course using Haskell pays off in other areas, but performance is tricky.

Thank you! It is so heartwarming to read such comments as yours. We are doing everything we can to bring this idea to reality. Please check out some of our Luna live session coding screen casts here (enable 1080p mode): https://www.youtube.com/watch?v=8_pi7LYpDYw&feature=youtu.be

We're collaborating with few companies, but we cannot share detailed info just yet. If you are interested in using Luna on production, please let us know and we will provide support for that!

Yep! It was not meant to be public, but unless we've got proper tutorials, please check this out: https://www.youtube.com/watch?v=8_pi7LYpDYw&feature=youtu.be

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

Thank you! We will do our best to make Luna the most powerful visual language ever created!

When we are thinking about simple installation process, you are completely right! However, when creating Luna, we were aware that if it will be used in real-world environment and people will create big projects using it, we would need to handle installation and updating in a very careful way. So our "installer" allows you to install and manage many Luna versions side-by side and switch between them on demand. So if something stopped working after an update, you can be sure that switching to previous version would work. These kind of tasks are handled by Luna Manager currently, which is connected to the simple Electron GUI. So even if we provide such "native" installation functionality, we would need some lightweight gui system if we would like to keep this secure installation management. We will definitely look for more lightweight solutions here.

I've described it in detail on our blog post here: https://medium.com/@luna_language/luna-the-visual-way-to-cre...

We didn't have thought that Electron have such big size overhead when choosing it. In fact we just wrongly assumed that it will be lightweight. We will make the installer lightweight in the future, however there are much more important tasks on our todo list now, so we will do it slowly. We provide very light command line installers as well, so you can use it instead as you wish. Regarding these libraries, we want the installer to evolve into bigger app in the future - allowing you to install many Luna versions side by side, uninstall them or switch the current version. Moreover, we wanted to provide unified experience across platforms. It seems that something like QtQuick will be better suit here, but I haven't investigated it good enough yet to be sure it is the best choice.

@cakoose, would you be so nice and elaborate more why do you think we are lying? It is very sad to read such comments, seriously. We were doing our best to bring Luna to our community, so why are you talking that we were lying about anything now?

akavel thank you, thank you! <3

We've sent the mails, could you double check if it is not there?

There was a thread about party in Krakow on our Chat, lets discuss it there! :)

Here is the topic on Luna monetization on our forum: https://discuss.luna-lang.org/t/how-is-luna-monetized/46/9

As you can see, we are open for discussions here and we are still looking for the best model, so we would love to chat about it! :)

Of course we will do it. We are building this product for years and we are releasing it as Open Source project because we believe we can truly impact how people are able to process data. We do this because we want to contribute with Luna to how you currently work. In other words, we really do Luna for you, our users. We have to collect data to know if we are heading in the right direction, that's all. If we collect it in such way that it disturbs you, then we have to fix that! Here is related issue I've created for it: https://github.com/luna/luna-manager/issues/118

I do not promise it will be resolved tomorrow, because we've got some high priority bugs regarding windows installation, but I'll ask our team to resolve it faster than later.

<3

Hi! Do not do another front-end! Use ours, here it is (with some additional code, we should move to separate repos soon): https://github.com/luna/luna-studio

It would benefit both worlds - you start with something working and well designed and if you improve it in any way, we would be happy to have your contributions :)

Regarding business model - everything is free. We will provide some paid hosting solutions in the future / paid libraries for very specific domain use cases.

Actually it is not intentional. We do not have any connection to Lua. The name "Luna" was used from the beginning of the project, people started recognizing us with it and we simply love this name so it stayed with us.

If such confusion would be often, we will change the name, however, we've got few comments that this name could be confusing but in fact nobody ever confused it.

We are still open to change it and are actively looking for any kind of replacement. If you have any idea of a name that would be suitable for such a language, I would be more than interested in hearing it.

Moreover, I just opened a thread on our forum to discuss names propositions. If you've got any ideas, please share them with us! :)

https://discuss.luna-lang.org/t/luna-the-name/73

We'll fix that. I'm sorry you had bad experience with it.

@jlebrech thank you! :)

Regarding the AST topic: Luna does use AST for the translation - if you modify the graph, an AST-diff is created, applied to the AST and then AST-diff is created and applied to the text. If you cange text, the AST-diff is applied to the visual form. The visual graph is not direct AST visualisation because it would be completely unreadable :)

We believe it is. Such comments as this one give us always super-powers, thank you. We will do everything we can to make Luna the most powerful visual language ever created.