You might have seen this http://www.luna-lang.org/ and it looks pretty impressive.
My first thought is that the visual explorer is a hell of a modern REPL - quite a different class than my still beloved lein gorilla.
Anybody got to play with it and has comments to share?
5 Likes
Removed the “[OT]” from the topic as this is perfectly on-topic! 
I haven’t had a chance to play with it but I also saw it earlier today and it looks pretty interesting. I always have a hard time imagining that I will be as productive with text but that doesn’t mean it has no place.
Will definitely try to take this for a spin some time this week.
Fascinating. Given the acceptance of Javascript, we’ve got a clean path in from Clojurescript for component creation, though I’m wondering about whether it’s possible to recreate it using only Lisps.
I’ve used Max/MSP, Pure Data, and a handful of other node-based visual languages for a variety of tasks: music, animation, shader creation, general programming. I’m very excited to try Luna, but haven’t had the chance yet. So while I can’t speak to the effectiveness of their approach, I can say that I’ve found this particular visual paradigm to be quite fruitful and woefully under-explored. Here’s the recipe for success if you try one out:
- The language/environment needs to suit the domain of your problem. Max/MSP is a fantastic tool because of its standard library full of highly optimized DSP operations, not because it’s visual. So for Luna, don’t go into it planning to make a web app. Learn what it is designed to do, and try using it for that at first.
- You must give yourself a lot of extra time to get used to the new way of working with abstraction, following program structure, knowing what patterns are effective, etc. (Hey, there’s a familiar argument when bringing new folks to Clojure). Visual languages are a world unto themselves, so be ready for a bumpy learning curve.
- The language needs to be sufficiently ergonomic, or you’ll struggle to be productive even after becoming familiar with it. This is where many visual languages fail, but Luna looks most promising. But again, I haven’t used it yet, so for all I know it might still be a chore to work in. If that turns out to be the case, please don’t fault the visual paradigm — there exist visual languages in which you can work very quickly and with great fluidity, in which you can feel highly productive, because of the strong interaction design. But most programmers have written off the paradigm because of bad experiences (or the reputation thereof), due to languages like Pure Data which are painful and sticky and finicky. So we don’t see a lot of new visual languages being developed with modern sensibilities, so the vicious cycle persists.
No pressure, Luna!
7 Likes
I’ve just tried half an hour, did the included tutorial “Basics”. Now I completely agree with @ivanreese, as a complete beginner it’s disturbing. Still I understand how the stuff works in global principle already.
The tutorial is a bit rough in the edges, and the installer brings Luna Studio, a Atom-based environement. It’s slow and sluggish, UI needs a lot of improvement, but otherwise really interesting. Once I understand how to plot data I should try a live visualization of… something. Does anyone know a not-bloated and free HTTP JSON API ? I need a live dataset to feel the power of Luna.
What I like is the fact that each function is its own graph, with special inputs and outputs. Otherwise each node is connected to the other rather logically.
The language doesn’t have seem to have any type annotation, so it may be completely based on inference.
Will keep playing with it !
5 Likes
I’m writing this a bit reluctantly because my project is still vaporware (in the sense that some very important bits are missing), but I’ve started writing something similar to Luna in Clojure. It would enable a similar sort of visual programming, but an important difference would be that you would not get an one-to-one correspondence between text and visual views (the visual views would be less granular than Luna).
The other important aim of my project would be to be very keyboard driven with heavy inspiration from Emacs, so hopefully that would maintain some of the flow that comes from being able to stay at the keyboard all the time (instead of having to switch to mouse all the time).
Btw, Luna is written by Haskellers, so I expect its “scripting” language to be heavily influenced by Haskell if it’s not outright Haskell already.
6 Likes
Yeah — between Luna and Isomorƒ, it seems all the hip new experimental environments are being written by the Typed Empire.
I’m building a vaguely similar thing for my company (probably a year away before I’ll be sharing it, sadly). Here’s hoping more Clj people take up the experimental environment cause!
1 Like
Oof. I wanna love this - been waiting on news from it for a couple of years - but right now, it’s pretty much unusable on Windows, the only OS I have access to at the moment. Guess I’ll keep prodding the nightly builds and giving feedback.
The idea is strong - a simple dataflow language that emits a visual interface. It feels similar to what Pure Data tried to do back in the day, but with much stronger modern tooling and what seems to be a more reasonable selection of core functions to work with. Something I’m gonna keep my eyes peeled for.
1 Like
The concept is definitely intriguing. The big question is whether they can make it usable or not, and where it will be useful.
To me looks like a logical step forward from the “document” model made popular by iPython (and I’d say pioneered by Mathematica 30 years ago, but I’m digressing). I feel we need something more powerful than Excel for casual computation.
It sounds like your experience with Max/MSP is much better than that of Pure Data. How come? Is it because of the UX of PureData? Or is it the components that come with Max/MSP that are better quality?
I’ve used Max a lot more than Pd, but I haven’t used either of them in about 4 years, so take this with a serving of salt.
I’m very sensitive to aesthetics. I want the tools that I’m working with, and the materials I’m creating, to look and feel beautiful. Working in Pd, I found the code (nodes+lines) to look rather ugly. Max isn’t drastically better, but at least there’s clearly been more of an effort to make things look somewhat pleasant. I found it easier to create, select, and manipulate things in Max. I found the tools for laying out nodes more helpful. The way message and signal lines look is much nicer. Max’s debugging views are pretty (though I never found them especially useful). When it came to creating GUIs for my projects, I found the variety of inputs and meters and charts and other widgets in Max to be much more diverse and useful than what was in Pd. Pure Data feels like many open source projects — the core tech is remarkable and clearly crafted with love and obsession, but there’s not an equivalent degree of craft given to the GUI.
I also found it easier to create advanced systems in Max. I leaned heavily on the JS interop/FFI — for instance, to implement recursive algorithms for composing music, which would then be sonified by more traditional Max code. When I used Pd, I wasn’t aware of there being an “escape hatch” like this (though I might have missed it), short of reaching down to C (which I’m not fluent in).
The classic problem with node + arrow code is that the complexity of the graphical representation is simpler than the test representation for simple graphs, but grows in complexity much faster than text does. This makes graphs very attractive for demos and extremely painful for real work. Luna’s approach tries to get around this by giving two views on the code, but I suspect the better answer is another paradigm we haven’t seen yet.
2 Likes
Agreed. It feels like the Max & Pd approach (that Luna seemingly expands upon) is a local maximum. This breaks my heart, because I see much greater potential in the space and it feels readily attainable, but I don’t see that happening anywhere. Worse, I see people dismissing the whole notion of non-textual programming because of how poor the current implementations are.
In all the node-based languages I’ve seen, what we have are essentially text-based languages where you weaken naming — because hey you can just draw an edge, better than introducing & using a name, yeah? So that ties one arm behind your back. Then you have to write your text in these little boxes, making it frustrating to read and write that text. To work with those boxes, you need to constantly jump back and forth between the mouse and the keyboard. And while we’re making the ergonomics worse, how about we render all that text monochrome. Yuck.
But wait — visual languages can have dynamic dispatch, subroutines, code-as-data, arbitrary data structures. Any construct you can put in a text-based language, you can put in a visual language. When you go visual, you’re not limiting yourself in terms of capability. But you might need to be very imaginative to find a way to make the visual/spatial character of your language represent or benefit a given construct. That’s where Max (etc) fall down.
So I don’t think that the complexity issue you described is essential. I think it’s self-imposed by current visual language designers. Perhaps that’s because the handful of visual languages that got traction (and thus the benefit of countless hours of design & development effort) are created for people who aren’t computer scientists. These languages only need to be sufficient for solving a domain problem, not for advancing the art of the visual PL.
If I were making a visual language, I’d lean far more heavily on the word “visual”. There are countless commonly-seen facilities in other non-programming GUI tools that could find a nice home in a visual programming environment:
- Layers, a la photoshop
- Color-with-meaning, a la labels/tags in Finder
- Shapes-with-meaning — eg: using simple shapes to represent types, making it easier to see how data changes as it flows through your system, or what sorts of data goes where
- Animation-with-meaning — Max allows you to enter a step debugger mode that shows when messages move from one node to another, but you could do so much more by (eg) continually animating the shape/texture of edges.
For any notion in elementary graphic design, you can attach meaning. Allowing the programmer to choose for themselves what meanings these notions represent is even more powerful — now we’re in Isomorƒ territory.
The fact that current visual languages are built of monochromatic text, a few box shapes, and a few colors of line, is a tremendous failure of imagination.
There are so many great visualizations of complex systems in films (BS-ness, notwithstanding), and so many great mechanisms for interacting with complex systems in video games (Sim City for goodness sakes, not to mention Zachtronics, Factorio, The Witness…). But I don’t see any visual languages borrowing from the visual language of these more imaginative sources.
Luna is pretty, but it looks like they’re just implementing more-capable primitives in a largely traditional node-language environment. Even the ability to view your code as either a graph or as text is something Max/Pd already did.
At minimum, I want to see people doing for visual languages what Light Table tried to do for Clojure. We can surely go a lot further, but even this would be a good start.
5 Likes
You’re ranting to the choir here. And, happily, we’re not entirely alone.
For example, this Stéphane Conversy paper includes a fine pull quote on the matter – “[a] true visual language would then be a graphical language that actually leverages the perceptual system” – and proposes using Jacques Bertin’s Semiologie Graphique as the lens through which to see programming language representation. The quite similar follow-on paper from 2014 is Unifying Textual and Visual: A Theoretical Account of the Visual Perception of Programming Languages.
The idea of syntax-directed editors (where the syntax is a skin over the actual structure and the editor is generated from the syntax definition, a direction in which IsomorĆ’ also reaches) dates back to at least The Cornell program synthesizer from 1981.
This zoomable 3D interface for navigating Lisp code dates to 1993 (and is thus wonky and visually clumsy, but still a finger pointing in a particular direction):
Sean McDirmid’s whole career has been spent exploring this sort of thing:
(skimming through the demos is worth your time)
I could go on for quite some time with references in this space, but you get the idea. One thing I’d like to see more of in this space is mining the ~40 years of ideas that didn’t work because our machines and displays were too weak.
6 Likes
Hi @jackrusher, thanks for this info… could you ( when you have a sec 
) point out more references, readings etc… on this subject?
I am researching/building a tool for “systems analysis and synthesis” and a bi/modal textual/graphical representation is one of my main goals. Thanks!
Let me pile in here as well, @javi and @jackrusher. I’m also working on new tooling in this space, and I’m eager to absorb every resource, paper, library, talk, prototype, […] that I can get my eyes on.
1 Like
@javi @ivanreese Have either of you started a shared public document somewhere about the history of these sorts of systems? I’d be happy to drop some resources there. To start with, I really like what Shawn Lebron has done here: https://github.com/shaunlebron/history-of-lisp-parens
1 Like
I’ve been amassing a collection of links, so turning them into a public repo is a great idea. Today is pretty busy, but here’s a first step: https://github.com/ivanreese/visual-programming-codex
Feel free to flood the repo with “Links!!” issues, and I’ll gladly fold them in.
It’ll grow substantially when I have the chance to feed it more of my link collection, and I’m sure a proper organization system and sense of narrative will emerge.
If this being a personal repo causes you guys any consternation, let me know and I’ll spin up an org for it, and hand out invites.
4 Likes
@jackrusher @ivanreese apologies for the bad manners/late reply, I am finishing up the merge of 2 projects into 1.
I will be done in a couple of days and I will post a better reply then.
2 Likes
This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.