Equivalent text and graph representation is the killer feature.
I previously looked at stuff like https://flowhub.io/ide/ which is a dataflow language spec and editor. Specifically the js version https://noflojs.org/example/ for compiling graphs into js for some canvas image pipeline work.
Each component has an underlying text representation that you can edit like you guys. But that representation isn't code. It's just the configuration of the node.
This isn't what I want! I want to architect the dataflow on a whiteboard, code it normally (a new language is okay), and then have it visualize the same dataflow for debugging (with help grouping/organizing if needed). Every programmer already does this in their head but without the visual aid.
(Focusing too much on the graphical representation is a mistake. There's only a handful of granularities that are worth whiteboard diagramming and people definitely don't want to code with a mouse dragging and zooming. But having the diagram at specific architectural level when you do need it is invaluable)
I haven't tried your product out yet so I don't know if you guys got it right, but at the very least you guys recognize the importance of "dual syntax representation" as a selling point!
people definitely don't want to code with a mouse dragging and zooming
Actually that is exactly what I want which is why I signed up for the Luna beta months ago. We have had flow based programming for a while in the synth and robotics communities and nesting diagrams within each other is the normal thing. For many tasks you can produce elaborate working interactive UIs without ever writing code. My favorite software allowed adding code in C and assembler, though then they shifted focus towards the robotics control market and reoriented it around Ruby.
There are two big advantages in working primarily at the graphic level: you can trace control flows visually and you don't have to know all the libraries and syntax. Instead you can select from a palette and find out what they do by using them, and it should be the computer's job to worry about syntax anyway.
iirc it's flowstone DSP, last time I looked there was still a free version though it's not an open source project. Would recommend to anyone as an example of good UI in this area
@anigbrowl I do not know flowstone DSP, but I see you were thinking much about GUI / nodes design. This is one of the topics I'm passionate about and I we want to make Luna the most powerful visual language available. I would love to chat with you about node design and your ideas. If you think it's interesting, I've just created a topic on our forum for this – I would love to read and discuss your thoughts there! https://discuss.luna-lang.org/t/nodes-design-discussion/69
arnioxux, thanks for sharing your thoughts here! I completely agree, that double representation is the killing feature of Luna. Personally, I do not believe we can progress in the domain of software design by removing the textual form. Because of that, we have designed Luna to be textual-visual, so tightly integrated, it is just one thing. For example, you can write any expression above our nodes, let it be `2+2` or `2+` (a function which will let you connect the missing argument to your node!).
However, I do not agree with your point that people don't want to code with mouse. Actually, connecting high level components visually, tweaking their parameters (with sliders, color choosers and other widgets) and observing how it affects the result you got is MUCH faster than writing code. There is of course some "base level". If you code something low-level it is much better to use code then. Where this "base level" is, depends on you and your preferences.
I would love to hear more from you after you try Luna and try to create something more complex in it! :)
Nice project, congrats. I think everybody here understands the idea behind your product (inspired by bret victor talk, fwiu). However, i think nothing would replace a nice screencast of what programming in this environment looks like. I didn't find it on your homepage, and i think it should be one of the very first thing.
I don't think Bret Victor ever did a visual dataflow language, did he? This doesn't seem like the kind of thing he would do, it is more in the spirit of Quartz Composer (especially in its liveness and explorer) as well as VVVV, among many others. It also reminds a bit of Unreal blueprints in the way it handles completions on results (just draw out from the output, and you get a list of what patches you can bring in to deal with it).
It does seem like a nice replacement to Quartz Composer (well, we have Facebook Orgami now), since Apple isn't going anywhere with that these days (though aimed at data processing rather than graphics and animation).
Bret Victor's ideas are a very strong inspiration regarding where graphical interfaces could expand in the future. We strongly agree with his principle, that people need an immediate connection with data they are working on. This principle is one of two foundations on which Luna was actually built. We have described our thoughts in detail in our blog post here: https://medium.com/@luna_language/luna-the-visual-way-to-cre....
> Is this "visual programming"? No. The term "visual programming" has had a well-established definition for several decades, and this tool is not that.
> A "visual programming language" provides graphical representation and spatial manipulation of the program structure. (That is, static "elements" or "operators", analogous to the "code" in a conventional programming language, or schematic components in a circuit).
> This is not the case with the tool here, which actually represents program structure as a fairly conventional list of textual instructions. The only direct manipulation of the instructions is merely in selecting them for looping, deleting, etc.
> Instead, the tool provides graphical representation and spatial manipulation of the program data. (Dynamic or "runtime" information, analogous to the values of data structures in a conventional programming language, or voltages in a circuit. In this case, the data is a picture.) The program structure is built up implicitly by directly manipulating the data.
Luna seems to lay firmly in the former category rather than the latter: it is firmly steeped in writing code to manipulate and visualize data, rather than manipulating data to get code. There isn't anything wrong with that, but I see a lot more similarities between Luna and Latour's Quartz Composer or Sweeney's Unreal Blueprints than I do with Bret's systems.
@seanmcdirmid
We are not yet there, but we develop Luna to target EXACTLY these use cases - program modification AND very direct data manipulation. We see Luna as an unified platform for building rich DSL's. An example of such rich DSL is what Bret Victor demonstrated in his talk. You can read more about rich DSL's and what Luna is meant to be in our blog post here: https://medium.com/@luna_language/luna-the-visual-way-to-cre...
Regarding your thoughts, Luna is a fusion of both approaches. When you create and connect nodes, you are manipulating the program structure - you define how data flows between components. However, every node has the ability to display an interactive results visualization and input data widgets. Basically these visualizations and widgets allow you to work directly with data – you can create canvas visualization which let you paint on it, you can create a 3D scene visualization which would allow you to not only inspect 3D scenes but also modify them etc. These visualizations can be displayed below nodes or can be detached to be separate windows and are defined as HTML/js snippets.
I guess at this point, I just see a nice VPL; it seems to have the liveness properties of Quartz Composer, at least, which, as you say, displays an interactive results visualization and input data widgets (though you might have to turn the patch around or mouse over an input pin). It seems to fit into Tanimoto's liveness level 4 taxonomy.
If you have some direct manipulation and gradual abstraction going on, I haven't seen it in your examples or explained in your docs.
Also, have you checked out Conal Elliott's Tangible Functionla Programming (Eros) work? It is a bit dated (2007) but explores being more direct in a Haskell-like language.
Hi @bsaul, our website is currently full of screencasts. If they do not load in your web browser, please tell us what is the browser and what system are you using. The ifrst screencast should appear in the website header - please wait couple of seconds and see if the movie will load there. In the meantime, please test it using Chrome! :)
@bsaul, video tutorials are a very interesting idea. In the first release, however, we have incorporated few toy-projects and interactive tutorial, which guides you step by step inside the product. Do you think video tutorials are better to understand / follow than examples or interactive tutorials ?
I would definitely prefer video tutorials, they would be massively helpful for me to learn. By the way, if anyone wants to make a youtube channel about luna, I'd subscribe, if anyone wants to make a udemy video course - I'd buy it =)
@rayalez thank you for your feedback! It is very interesting for me personally. I would not have thought that video tutorials could be better than interactive ones, but it is probably because of my strong personal preferences towards examples / interactive tutorials. On our short roadmap I see new demo scenes only, but we will talk internally about video tutorials tomorrow. If you think you would like to help us with them – by providing ideas or just helping us create them, we would be more than interested in collaborating with you! :)
Yes, video tutorials are very important for visual tools. I used to prefer books (and still do for digging deep into a tool) but these days to learn anything new in computing I prefer videos. That way I can just see how it works in 30 mins rather than wasting a few hours to setup environment, learn basic stuff and try it out.
If the video intrigues me then I invest time in setting it up and reading the documentation.
I wasn't thinking of a tutorial, but a demo. it's a bit different. The purpose isn't to teach me how to use the tool, but to understand and see what it will look like and what i'll be able to do once / if i ever learn to use it properly.
Then maybe i'll install the software, then i'll go to the tutorials (in that order).
@bsaul, oh I understand. I think we are not there yet. We do not have many ready use cases built in Luna. We will be working with our community to use Luna in real projects / create interesting examples. Then we would build a video showing Luna possibilities.
Right now think about Luna like about a new programming language with rich, visual representation and a very limited set of available libraries. If you are processing data that could be visualized or you are inspecting data, looking for the best way to modify / understand it - Luna could be the tool you are looking for.
I strongly encourage you to play with Luna, see example demo scenes and try to create something from your field of expertise. We would love to help you do it! Use our chat / forum if you have questions / problems. I would be more than happy to later create a video showing your system in work to demonstrate what Luna is suitable for! :)
* I can't see why I have to give my e-mail address.
* The Electron setup process is very nice! Though, I wouldn't have minded a lightweight installer, with little more than a wrapper around curl.
* After installing the software, I can't see it anywhere - nor from the XFCE app finder, nor in $PATH. I know I should read the documentation, but it'd be nice if I could at least find it from the app finder (it's a matter of adding .desktop files, I think?).
Thank you for your your impressions, we would try to improve it as much as we can. Answering your ideas:
1) You do NOT have to provide your email address, just type there anything if you don't want to provide your real address (it is not validated in any way), however, we would be very thankful if you provide your address, so we can track now how many people are using Luna and if there are any problems happening when you are using it. The detailed logs we collect are described here: http://www.luna-lang.org/alpha-data.html
2) Thank you! If you have any ideas how to make it more lightweight and still work across all platforms, while providing users with the easiest possible installation experience (double click and install using a graphical installer without any manual configuration), please tell us about it using github issues here: https://github.com/luna/luna-manager
We would love to simplify it if that would be possible! We were focusing on delivering unified experience across all platforms and it is important for us, especially when we will be targetting not only developers (but also domain experts, like bioinformatics, IoT developers etc) in the near future.
3) I would be thankful if you create issue regarding lack of proper XFCE support and tell us what the installer should do on XFCE. I know that it is working correctly under Gnome and KDE. You can find Luna installation in ~/.luna/bin/luna-studio/current/luna-studio :)
There is little (if any) virtue in developing a single installer to work on all platforms. People want a drag-and-drop app image for Mac, a PPA repository for Ubuntu and an MSI package for Windows and/or a simple "just extract and run" archive for their platform.
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.
This looks very cool! I especially like the geographical stuff, that being something that is dear to my heart.
I have a couple of questions that may sound trivial but are important to me. I haven't tried installing the studio yet, so please forgive me if installing it would answer these.
First, all the screenshots, along with the doc pages, use a dark theme with very low contrast: only 47% contrast on the body copy in the docs, and much of the text in the screenshots has even less contrast than that.
I know that low contrast dark themes are very popular, but younger developers are often unaware that they can become very hard to read as you get older or if you have less than perfect vision.
There's even been some research done on this; I don't have the source handy right now, but the basic idea is that dark themes cause your eyes' irises to open up wide, while light themes cause them to "stop down" with a narrower opening. And like a camera lens, many people's eyes can focus more sharply when they are stopped down a bit.
There is also the problem of switching back and forth between light and dark backgrounds. All of the web references I use day to day have light backgrounds; all my editors are set to light backgrounds, basically everything I do is that way because I find it much easier to see things. Switching back and forth to one app that uses a dark theme is hard on the eyes.
I did find the PDF version of the docs, and that uses a conventional high contrast light theme, so that is nice.
Somewhat less important, I'm curious whether the studio supports proportional fonts? I don't enjoy monospaced fonts and I find them harder to read than proportional fonts. This is not a big problem like the dark theme, but it would be nice to support any choice of font.
I should file GitHub issues on these, of course. Partly I just wanted to mention them here to help raise awareness among other developers that dark, low contrast themes can be a real accessibility issue for some of us.
OT: Do dark but high-contrast themes have the same issues?
I ask because, just to reduce eye strain in the other direction, I avoid bright screens where possible. Probably a side effect of often doing things late or even at normal times during winter. In any case, if I ever built a website it'd probably be dark-ish, but knowing about the pitfalls might help avoid them.
Even more off-topic, but in the interest of eyesight stuff - both switching between light/dark and dealing with bright screens have been basically unnoticeable since getting blue-filter coating on my glasses. Not sure I'd recommend it for color-sensitive work, but it's not problematic at all for programming and stuff like that.
Your comment about the blue filter got me thinking. I assume this filter reduces the amount of blue light, is that correct?
As I mentioned in another comment, I've found that many laptop screens have a pronounced blue-green cast out of the box. The worst ones we have here are a late 2013 MacBook Pro Retina and a ThinkPad X1 Yoga Gen 2 WQHD. These both are difficult to look at with the factory calibration, especially the X1 Yoga which I found literally painful to use in the first part of the Windows setup, before calibrating the display. Everything was an intense green that felt like it was burning my eyes. I can see why someone using a display like that might prefer a dark theme, just to knock out that awful blue-green.
But after I calibrated the display to a pure white, it looked beautiful, just like our other calibrated high-DPI displays.
One other benefit to calibrating displays is when using multiple displays. I use a 24" 4K/UHD display in portrait mode along with whichever laptop I'm using at the moment. (A portrait mode display plus a landscape display is a wonderful combination, for example an entire PDF page fits on the portrait display with no scrolling.) Having the colors look the same on both displays - especially the white backgrounds - makes things much more pleasing to the eye.
To your question about high-contrast dark themes, yes, I have the same trouble with those. Dark themes just don't work for me, nor do low-contract themes, whether dark or light.
@Stratoscope thank you for such a detailed comment. We are fully aware of the topics you've mentioned. I'll try to cover all your questions in the following points:
1. Screenshot contrasts – we will be working on providing setting desired contrast in Luna just by selecting a predefined one from a drop-down menu. We are not there yet, because to make it working properly it is a little tricky thing. However, please keep in mind that the visual part of Luna is one of the most important parts of the whole projects to us (and for me personally). Right now we provide a "default" dark setting, that is suitable for working long hours in Luna without making your eyes tired (please note that we do not use gray, we use red-ish color scheme there).
2. We know that such settings are not the best for everyone, especially for developers older than about 40 years. We would our best to provide appropriate settings, so you can either increase the contrast or change the theme to white one (or write your custom theme from scratch). In fact, if you navigate right now to our theme settings you can already see some contrast settings. They do not work properly yet, but you can see that we are slowly working in that direction. However, we do not want to just "increase the contrast". There is a lot of people who prefer lower contrast, as we ship right now. We want to do it the right way, so you will have control and will be able to easily fine tune the GUI to your preferences.
3.I've read the research you mention. It states in particular, that when your irises are more closed, it is much easier for you to track corners and edges, however your eyes are getting tired easier. Working with white theme a whole day could be a pain, so we started with default dark theme. It is also affected by our personal preference, but as I described above, it is VERY important to us to make Luna easy to work with for everybody in all conditions, which also includes white, high-contrast themes. Please, keep in mind that it will need some time to develop. We are still a small team and we've got some high-priority things on our checklist right now, like improving the typechecking performance.
4. Our docs provide white PDF, but also the HTML version provides a white theme - just click on the "A" latter icon on top of the docs and switch to the light theme there! :)
5. Proportional fonts are a little tricky by definition. The question is - if you really want to use them when writing code. What I mean is that what you write above ndoes could be any code snippet. It could be just a function name, but could also be any expression like `2+2`. We are currently synchronizing the text editor font with nodes font, so if you use monospaced font in your editor, the same font will appear above the nodes. Do you think it is a wrong approach? If so, how would you change it? The best way to tell us about it is to create a github issue / discussion about it.
6. As I described above, we are small team of developers on a mission to bring something incredible for data processing. We are very open for any improvement suggestions. Any suggestsion regarding how the GUI looks like and how readible it is, is very, very important to us. This topic is tricky, because we want to provide flexibility over how the GUI looks like. We would be also very thankful for any help on helping us improve it. So if you tell more about what you think on github issues, we can continue the disusion there. We will tell you in detail what are our ideas and we could then choose the one that is the best (allowing everyone to set up the theme for hes own preferences).
Thank you once again and im looking forward to hearing from you! :)
Thank you for the thoughtful reply! I will hop over to the GitHub issues for more detailed discussion. A few thoughts in the meantime...
I tried the A icon in the docs - thanks for pointing this out, I didn't notice it at first. The light theme is an improvement over the dark one, but it isn't very readable either. The problem is that nasty Quicksand font. It is very hard to read! I knocked it out and the page fell back to Helvetica Neue, which is much easier to read. The line-height: 1.7 seems a bit excessive too, but that is a minor thing.
I'm viewing the page in Chrome on Windows 10 with displays in the neighborhood of 200 DPI and display scaling set to 225%.
> Working with white theme a whole day could be a pain
It certainly isn't for me. I use light themes for everything - all my editors and other tools, all websites, everything.
I wonder if the idea of light themes causing eye strain may come from having improperly calibrated displays? I calibrate all my displays to a pure white background. This is essential for me, since most laptop displays I've used have a pronounced blue-green tint. The worst one was a ThinkPad Yoga Gen 2 WQHD that I helped a friend set up. Out of the box, the display had an intense green cast and was truly painful to look at. After I calibrated the display it was a pleasure to use.
I did try installing Studio on Windows after I wrote my first message. The darkness and lack of contrast in the installer made it feel a bit sad, as if it didn't really want me to see what it had to say. Alas, the installer got stuck at 34% with no files installed, so I didn't get a chance to try the actual app yet. I will revisit that when I get some time.
Of course this whole area is one where different people will feel differently - you guys love the current theme, where I find it very unusable. So I'm glad to hear that customizable themes are in the works, because I would have a hard time with the current one.
Regarding proportional fonts, yes, I use them for all of my coding, and have done so for at least 10-15 years. In particular, proportional fonts let me use a larger font size and still fit more text on the screen than I could with a smaller monospaced font.
I don't use monospaced fonts at all any more except for specialized situations like hex dumps. All of the editors and tools I use support proportional fonts beautifully. So my advice on fonts is simple: don't assume that proportional fonts are unusable for coding and development; give them the same support as monospaced fonts.
Looking at the animated screenshots, I don't see much there that would have any difficulty with a proportional font. The one possible exception is some right-aligned text. If you use spaces to line that text up, it won't work well in a proportional font. But if you use truly right-aligned text it will be fine.
Just want to say kudos for making design a priority from the start. Developers often underestimate how important design is to ease of use. Looks fantastic and excited to see where the project goes.
Luna is a visual language. It is important for us. How it looks like, how it behaves, how you feel with it, how fast you can work in it - these are the things which are most important when designing Luna. In fact, because of these things we have designed a new language instead of using existing one - then we would have to sacrifice some visual elements / behaviors and we do not want to do it.
We are small team, please support us as much as you can! If you want to see Luna succeed, help us do it by contributing to the project - both ideas as well as help with its development are very welcome! And I promise, we will do what we can to make Luna the most powerful and beautiful visual language ever created :)
The examples list failed to download, so I had the pleasure to try to program on my own (no, I'm not ironic, it's actually rather fun!) with the help of a bit of knowledge about functional programming.
The most important thing, i.e. the concept behind the language, is very cool. Though not a groundbreaking idea, the visual model is certainly an interesting outlook on understanding programming that goes beyond the trivial Scratch/flowchart software. The language itself seems to be very powerful, too, as is expected of functional languages. I like that functions can be defined on prototypes (eg. List.map) as well as its visual representation, though it took me a bit to figure it out ("why is it `list . map (+ 1)` and not `map list (+ 1)`? What's the `.` operator?", followed by "... oh, it's simpler than I thought").
The documentation is very basic - I wish the "Starting out" section included at least a hello world (eg. writing a function that returns `[1, 2, 3].map (+ 1)`, both in the GUI and in code). I can do that tomorrow (17/01 in the UTC afternoon), if needed!
The editor is okay, for a beta. It's quite "rough around the edges", with a few errors popping up here and there, but it's usable (though accidentally made it unusable, requiring a restart of the application, with a syntax error - but again, it's okay for a beta).
Anyway, it's a very cool project that I'll be keeping an eye on in the next months. Thank you for your work!
I love the concept of Luna and think the project itself was great,
However I feel you guys have chosen a poor approach to distributing it.
① I feel it would have been far better to implement the studio as an Atom plugin rather than a fork of Atom
② I feel having the compiler only available bundled into the studio is a mistake, there should be a pure CLI interface with minimal external dependencies so that people can use Luna in their existing CI pipelines
Thank you for the feedback! To answer your concerns:
1. Studio is actually a set of plugins for Atom, not a fork. It's just that we are shipping an Atom binary and make sure that it can work alongside a standard Atom installation, for a smoother experience. We understand how many people use Atom for their daily work and we'd rather not mess with that.
2. That's a perfectly valid point! We'll prepare a CLI distribution, but for the first release we wanted to make sure that Studio works well (the visuality is one of the strongest points we're trying to make after all). For now there's an option to build a command line client from sources, but a bundled version is coming soon :)
Regarding (1), this is a great way to distribute your language tooling. After a number of years using Atom, one thing that I've always wanted to see is a way to utilize multiple Atom instances all uniquely configured for a given use-case/language. For an editor that excels in customization, one thing Atom doesn't have is "profiles". I commend you for providing a Luna "profile" and I hope other languages/ecosystems consider using this approach.
@alexchamberlain Luna is not strongly connected to Atom. In fact, Luna gui runs in HTML and you are able to run it in your browser without Atom right now. However, we do not officially support it. We have chosen Atom just to bring a decent text editor to Luna Studio - thats it. We are planning to release web-based Luna version with some kind of web-text-editor in the future. It is not our priority right now (we want to focus on improving performance and delivering more rich data manipulators), however if you think you could help us with it, we would love to support it as much as we can!
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! :)
I was initially excited about this, because I'm a huge Lua user and fan, but then when I realised it was something other than the object of my love, was immensely disappointed it had nothing to do with Lua.
So I'd be one of those who'd suggest a re-branding, because the Levenstein distance is not big enough and there is too much potential for brand pollution on both fronts. Lua got to the moon first - you should shoot for another distant body, imho.
It sounds like you’re looking for a nicer version of Max/MSP. I’d certainly be keen to see Luna’s GUI applied to that domain, but I think it’d be better to hope that Max take UI / language design lessons from Luna than Luna add audio processing. The std lib in Max is so astoundingly rich — the number of highly optimized DSP ops implemented in C is going to be hard to match. Even if, say, there was a way to run Luna on the browser, so as to leverage the Web Audio API, you’d have nothing close to what Max has for processing.
But of course, Max’s UI and the design of their atomic language constructs really leave a lot to be desired. In this regard, it seems Luna is already flying circles around them. (Though I say this without having actually used Luna, so... grain of salt.)
Comparing the two is so fun, as it shows just how underexplored the world of node-based dataflow languages is.
> It sounds like you’re looking for a nicer version of Max/MSP
Exactly. Max/MSP is great and I really want to like it, but despite making several attempts at using it in my practice, it hasn't stuck yet. Max doesn't have enough abstractions to make in depth development enjoyable IMHO. After a certain point I get bogged down and long for a regular programming language with an IDE. I'd probably enjoy Max more if I was comfortable in C.
Max's std lib is rich and it would hurt to start from scratch in another environment, but you don't need that many DSP modules to start building interesting patches. An LFO, filter, ADSR and an oscillator get's you a long way towards a usable synth. And there are many open source libraries to draw from.
Have you played with the Web Audio API? It’s got all the primitives you need to build some really cool stuff (plug: ivanish.ca/diminished-fifth), and you have the full power of JS to build your abstractions atop... but you’ll almost certainly wish you had all those DSP goodies before long.
On that note, I wonder what sort of libraries people have written on top of Web Audio. That might be a viable leverage point.
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.
@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.
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.
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! :)
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.
I'm trying Luna under a non-admin account in Windows 10. I tried to install it for the first time and forgot to turn Avast antivirus off. It blocked tar2.exe execution, so I had to turn it off and reinstall. It downloaded and installed fine, but I can't figure out how to run it: there's no shortcut in Start menu. Does Luna create one, when installed normally?
@VladimirGolovin I'm sorry that you have bad experience with installation so far. Please report your issue to our bugtracker and provide as much information as possible. Windows support needs much love and we will improve it as fast as we can.
https://github.com/luna/luna-manager/issues
@cturner I'm sorry that you have bad experience with installation so far. Please report your issue to our bugtracker and provide as much information as possible. Windows support needs much love and we will improve it as fast as we can.
https://github.com/luna/luna-manager/issues
This looks absolutely awesome! Very excited to try it out. My biggest question that I couldn't immediately answer from the website is how well this deals with larger than memory datasets. Can it source data from a Postgres DB? A Cassandra cluster? Can I build/debug on local CSVs and then apply the dataflow to live data in an S3 bucket?
Hey, thank you! :) You can run computations on streaming data sources, and building computations on some local files and then running it as a part of a bigger, network connected pipeline is a very common workflow. As for connectors for specific services like Postgres or Cassandra, there aren't any libraries yet. All there is is bare networking, ready to be used for these. If you'd like to make that happen please let us know over the chat or at our forum, we'd love to assist you!
@marmaduke that is definitely something you can do in a library. Luna provides two backends - a runtime interpreter and native code generator (the later is not yet available in this release). Both have access to the most primitive OS APIs. If none of our standard libraries provide what you need, you can easily extend them either by writing it from scratch in Luna or connecting to Haskell libraries. We are working to allow you to connect to libraries in other programming languages as well and allow you to do it in the simplest possible form. If you have any further questions - how to do it, how it works, write to us using our forum: https://discuss.luna-lang.org/
I previously looked at stuff like https://flowhub.io/ide/ which is a dataflow language spec and editor. Specifically the js version https://noflojs.org/example/ for compiling graphs into js for some canvas image pipeline work.
Each component has an underlying text representation that you can edit like you guys. But that representation isn't code. It's just the configuration of the node.
This isn't what I want! I want to architect the dataflow on a whiteboard, code it normally (a new language is okay), and then have it visualize the same dataflow for debugging (with help grouping/organizing if needed). Every programmer already does this in their head but without the visual aid.
(Focusing too much on the graphical representation is a mistake. There's only a handful of granularities that are worth whiteboard diagramming and people definitely don't want to code with a mouse dragging and zooming. But having the diagram at specific architectural level when you do need it is invaluable)
I haven't tried your product out yet so I don't know if you guys got it right, but at the very least you guys recognize the importance of "dual syntax representation" as a selling point!