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/
@moondoge, if you don't want to provide your mail, just write anything in this field, we do NOT validate it in any way. However, we would be very thankful if you provide your real mail address, so we can track how Luna is used and improve the experience. Every data we collect is described here: http://www.luna-lang.org/alpha-data.html . We try to collect only insensitive data, that tell us how Luna is used and how well it performs.
Software that collects and sends back any form of information is a big no-no unless it's opt-in. It's not acceptable when vscode does it. It's not acceptable when .net-core does it. It isn't acceptable when Luna does it.
If you want your users to help you learn how Luna is used and preforms in real environments, you ask for them for feedback rather than forcefully extract it.
Having telemetry enabled by default (or much worse, being mandatory) is disrespectful. It's also a fairly good indicator of what you think of your users.
I totally agree with you on the mandatory part, I’d hope it would be widely accepted that opt-in is the way to go in such cases.
Although I need to point out there’s a huge difference between what people say vs what they actually do (see https://www.nngroup.com/articles/first-rule-of-usability-don...) and I can’t imagine an effective product development process that ignores the actual usage data.
I find your comment much more "disrespectful" than telemetry enabled by default. Did you read the mention that it was done for beta phase ? If you're not happy with that, then do not use beta, ask politely if it can be removed or made optional for final release, and stop whining and acting disdainfully.
@executesorder66 I am sorry if you feel we don't respect our user's privacy. We do and we are always searching for the best solution. We did not make the field optional, because we were sure it will not be a problem when testing the beta product. We will release soon a fix which would allow you to progress without providing the mail. The anonymous usage statistics will be optional and disabled by default when Luna will hit the stable release. Does it solve your issue?
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.
It's a beta. You're helping them test it, so them collecting usage/statistics is completely fair. If you don't want to take part in the beta testing, don't install the beta and wait for the full release (which the creator said elsewhere in the thread won't require email or data collection).
In saying that, I do think a sentence above the email field saying "By taking part in this beta, you're helping us collect data to improve the product for final release, which will not require your email address or do data collection unless opting in" or some such.
It's still in beta. It's common for betas to do that, so you can have enough information to fix problems that might occur. Unless the beta is already a RC and is basically just released for advertising reasons...
This looks more complex, harder to reason about and harder to make than just writing the code. And it only gets worse as complexity increases. But of course I've got way more mileage writing code than doing this.
@kabes there is a BIG difference between Luna and NoFlow. Luna is purely functional, immutable, lazy, has double representation you can switch any time. NoFlow is visual layer over imperative, mutable JS without ability to swithc reprs. These features dictate how easy it is to do something in the language. You cannot judge a language by trying another slightly similar, its like telling "I don't like Python. I've been programming with Cobol and it was awful. Python is also textual so it's a no-go for me". I strongly encourage you to try Luna and I would be more than happy to discuss your thoughts about it. In fact, there are many people who prefer working in Luna's visual environment when processing data, discovering what is inside data and building high-level components. If you're building something low-level it is sometimes easier to do it in text - you can then just write Luna code instead and use nodes for high level data processing.
"Freemium language" is not an option. The language is, and will be free and open source. I cannot even imagine any other option, particularly after open sourcing the codebase. Premium tools and services is the way to go for us and we don't feel that would be detrimental for Luna. It ranges all the way from simple consulting services to running a Luna based cloud environment, but there is no threat for Luna as a language in that. On the contrary, this kind of support usually helps boost the technology.
Yea, having a first mover advantage on every major product in and around the language is how they profit. Sort of a pretty old racket actually. Create a brand new market vertical, and then build the ecosystem for it before anyone can even access it. It's kind of like pre-mining a crypto currency. Except that in this case it's actually useful and a primary way for the field to move forward, indeed many of the most useful languages in the world start like this.
Probably the editor will have domain-specific add-ons and libraries developed and supported by the company. They can also provide workshops and certifications if the language gets more popular.
This looks like it might a good fit for data flow/transform/etl type workflows.
1. Does this work in a clustered/distributed environment?
2. Does this integrate with Hadoop/Mapreduce/Yarn/Kafka?
3. If it doesn't integrate with hadoop, how hard would it be to integrate it, do you think?
Hey! There isn't any out-of-the-box support for distributing Luna programs over the network or any library for that yet. We'll get there eventually, but this is too early a release. As for integrating with Hadoop and others: the networking libraries are already there, so there is always a way to integrate. There aren't any adapters yet, so creating one is as hard as wrapping the necessary network calls. If you'd be interested to get deeper into that, I'll be happy to assist you. Just let me know over our chat or forum and we'll make that happen :)
We understand how important it is for Luna to be able to use Python (and JS) libraries and we will try to get to work on that asap. Please note, however, that the core Luna team is fairly small, so we have limited capacity (although I would like to make it my personal goal to create the Python ffi). That said, any community effort in this area is more than welcome, you can check the code on our github org: https://github.com/luna
Agreed. Also, if the goal is to use this with data-processing workflows, interop with Python and R would be really helpful. Not that I have any idea how easy or difficult that might be.
This thing is a nightmare to install and uninstall. The installer is 170 megs and downloads god knows what, there is no uninstall, and when you try to do it manually you see it spawned three or four processes without letting you know. This is incredibly amazingly malware like if you ask me
The installer is 170mb after unpacking - it is just an electron app (for providing you GUI) connected to our installation manager. The command line installation managar is very lightweight (around 2mb) - we will provide it as an alternative to the graphical one. We will try to make the electron app smaller.
The installer downloads Luna Studio - The graphical environment and Luna compiler and installs it on your computer (according to our docs: https://luna-lang.gitbooks.io/docs/content/installation.html). If you want to uninstall it at the moment, just delete the ~/.luna folder - that's it. We will provide option for it in the next installer releases. What spawned processes are you talking about? We spawn processes for our typechecker and other services (like undo-redo manager), but they should be killed if you exit Luna ... until you are on Windows. When you are on Windows the processes are registered globally in order not to ask for root password everytime you start Luna Studio. We would love to chat with you about how can we improve it, Windows support needs the biggest love right now.
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.
Pretty browseable directory, to be fair. But yeah, would be nice with some more clear indication of where the installation is going, from the installer. Now I found the location in this thread.
Samuell, please note that we are shipping Luna together with Atom.io app. Look at `.luna/config/luna-studio/1.0/atom/packages/luna-studio/lib`. The main Luna Studio lib is around 35mb on my computer. There is also a compiler and some small plugins. Everything else are npm's node_modules and Atoms ecosystem. We will distribute Luna Studio without Atom in the future, then it will be super-lightweight.
I find myself using Luna instead of Python (with Jupyter) when I want to process/visualize some data, quick’n’dirty. Seeing the data flow through my program helps me wrap my head around it quite quickly. And the built-in visualizations are nice :)
It can make an interesting addition to Cardano (ADA) smart-contracts platform for designing visually formally safe programs for their distributed virtual machine.
@Vesnica, we would address this issue tomorrow (it's 2 am here and our team is slowly falling asleep!). I've created an issue for you, so you can easily track its progress here: https://github.com/luna/luna-manager/issues/111 :)
Wooohooo, I'm super happy and excited that you made it!!! Was already losing hope, and now what an awesome surprise! :) Huge congratulations, getting from prototype to shipping is hard, and you know it well enough :) Hope I'll have a chance to dabble with it ASAP!
By the way, have you sent a notification email to your alpha subscribers? I don't seem to have gotten anything in my inbox... only found via HN (just when I was starting to ponder if I should try harder to overcome this addiction...)
Hm, and maybe are you planning some kind of release party or something at your office or somewhere in Kraków? :) Or did you already have one? :)
Hey! For now the best way to interact with Postgres is, I think, using an HTTP wrapper server. A better way to do this needs to be created. Maybe as a community effort? ;)
@garyclarke27 if you are interested in helping us create such binding, we would love to support your effort as much as we can. Just tell us about it using our chat / forum (http://chat.luna-lang.org) or (http://discuss.luna-lang.org) and we will figure out the best way to make it happen! :) The basic building blocks are already there!
Hi Wojciech. I suspect that an ‘out of the box’ integration with Postgres plus options for some of your text representations to be expressed in SQL instead of your language would be a killer feature. No ORM though - I love SQL - I would happily pay £1000’s for such
I for example come from a finance background - now I design ERP / CRM software for my own company, I have a UI team but I would like to express some UI myself, to get immediate feedback, to iterate rapidly, a WYSIWYG tool would be perfect for me. I have total expertize with SQL an Excel, but not so much with Javascript. SQL and the Relational Model can be purely functional if immutable, ie insert only, I also use graphs a lot in my schema, they are just relations, Postgres can build closure tables remarkably quickly to create indexes for instant path queries.
My main constraint is time not cash, can your system easily interact with a REST endpoint? Postgrest (written in Haskel) makes these quite easy to setup. I auto generate SQL language functions for all data inserts, no direct to table allowed. So interaction with Views and Functions is my main requirement.
It would be interesting if we can construct software with a UI like this but based on an SSA IR or downright CPU instructions instead of another high-level language.
@e3b0c The GUI lives here: https://github.com/luna/luna-studio. It contains code which speaks with our compiler and infrastructure and we will probably extract the barebone GUI to separate repository soon. Anyway, you can play with it and we do want to support such use cases, because it will make the interface even better and would bring benefits to both Luna and your low-level system :)
What the site promises looks INSANELY COOL but the app doesn't seem to work actually. Errors behind every corner, 100% CPU load all the time and the tutorial won't finish loading. This is not beta, this is pre-alpha at best. I really hope it's going to be fixed in near future, can't wait to actually try applying it.
We don't have a webserver library yet, but a simple one is coming soon (probably this or next week). As for package management – well, we figured it's to good have some packages to manage first and not to rush into that. It is also a nice effort for the community, if there would be anyone interested in contributing such a system (thus earning eternal fame ;))
Luna is general purpose so it would be possible right now to rewrite the compiler from Haskell to Luna, but there is no plan for it simply because it would give us no benefits at the current stage. I agree that it should be done in long-term vision, just because it is "pure" and "beautiful", but do not expect it to happen anytime soon.
this is the programming language for the touchscreen generation, every language until now was born from keyboard use. brillant.
I've wanted to see any language have an ast represented visually, then when you save changed to that visual representation it would save back to the original file format, this is very close to what I was thinking of.
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 :)
If we think about a programming language then it's universe is what a program can actually do. Luna is a general purpose, real programming language. If you are able to code something in C, you should be able to do it in Luna. From this perspective, Luna is "limitless". In contrast to DSLs or almost every other visual programming language Luna is not limited by it's design. However, if such sentence is a real issue for you or other people, we would change it! What do you think? :)
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.
"many recent innovations in programming language design, such as higher-order functions, non-strict semantics, algebraic data types, object oriented programming and sophisticated type inference engine"
@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?
None of those are recent innovations in programming language design. Higher-order functions, in particular, have been part of mainstream programming for so long.
Cool looking project. Unfortunately my browser (Firefox) is really struggling with scrolling on the overview page... It keeps getting stuck while scrolling past the "powerful engine. Limitless" block of text.
Agreed, the project looks neat! I didn't have issues with the scrolling, but the page took about a minute to load and render on my 100Mbps connection. Chrome pulled down around 32MB of data to load the page, so no wonder.
At some point, a slick experience becomes a hindrance when it comes at the cost of load time, and this page blew past that point and then some.
The main culprit looks to be high-res PNGs with transparent backgrounds, which are ~2MB each. If you can get away with lightly compressed JPEGs with the same background colour as the page, you'd shave the majority of this baggage off. Obviously it won't look quite as good, but it's all about balance :) Just my two cents.
It's very laggy in Chrome as well. In fact, in chrome dev tools, if you open up a rendering tab, you can click on "Scrolling performance issues" and it will highlight parts of the page which might cause scrolling lag. Not surprisingly, it highlights mouse wheel listeners.
