Luna 1.0 Beta is out
luna-lang.org
luna-lang.org
my two cents.
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).
> 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.
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.
Does it make sense to you?
If you have some direct manipulation and gradual abstraction going on, I haven't seen it in your examples or explained in your docs.
I know some people prefer video but I strongly prefer text and examples.
Feel free to add video as well, - just wanted you to know at least some of us where happy :-)
If the video intrigues me then I invest time in setting it up and reading the documentation.
Then maybe i'll install the software, then i'll go to the tutorials (in that order).
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! :)
What do you think about it? :)
The real-time speed probably doesn't make for a nice animation but it would definitely be easier to follow.
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 :)
* 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?).
Answering a little more serious, the installation path on any Unix system is described in our documentation here: https://luna-lang.gitbooks.io/docs/content/installation.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 :)
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.
Thanks, and I look forward to checking this out!
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.
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.
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! :)
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.
Could you comment on your business model? In particular, how's the company intend to draw in revenue?
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.
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 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!
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.
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! :)
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
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 :)
What do you think about it?
* Is it possible to work with incoming data in real time?
* Is it possible to use MIDI and audio as data sources?
* If so, can the applications also output MIDI and audio in real time?
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.
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.
On that note, I wonder what sort of libraries people have written on top of Web Audio. That might be a viable leverage point.
We would love to help you create what you need!
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! :)
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.
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.
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.
Moreover, we have described in detail why current visual languages fail to succeed in our blog post here: https://medium.com/@luna_language/luna-the-visual-way-to-cre...
What do you think about it?
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.
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! :)
This application will not run without providing an e-mail address. It also forces data collection.
I will not use such software.
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.
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.
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.
So why don't you just make it a non-required field? I don't appreciate your attitude towards user privacy, so I will never use any of your products.
> We will release soon a fix which would allow you to progress without providing the mail.
If this happens, then you have indeed solved my issue, and restored my confidence in the human race. Thank you.
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.
By the way, I've made an unofficial subreddit:
https://www.reddit.com/r/LunaLang/
Could be useful to share projects, ask/answer questions, etc.
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.
Did I address your concerns?
As you can see, we are open for discussions here and we are still looking for the best model, so we would love to chat about it! :)
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?
I understand that it's 'coming soon', but what does 'soon' mean in this case? Not having anything for this is a fairly large omission, IMO.
671M .luna/
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.
Does it make sense to you?
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? :)
We've sent the mails, could you double check if it is not there?
There was a thread about party in Krakow on our Chat, lets discuss it there! :)
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.
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 :)
I think at very least it is limited by the known universe. :)
These lies are unnecessary.
All of theses "features" were present in the 80s and 90s...
There's no need to be like that regardless of how wrong someone is, and it's against the site guidelines, so please don't.
Instead of swiping at someone, why not explain how they're wrong? Then we all learn something.
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.