
Luna – A WYSIWYG language for data processing - tillulen
https://www.luna-lang.org/
======
spiralganglion
Plug — for anyone researching or otherwise interested in visual languages like
Luna, I keep a collection of projects, papers, talks, references, and other
related media here on Github: [https://github.com/ivanreese/visual-
programming-codex](https://github.com/ivanreese/visual-programming-codex)

As for Luna, it seems like they've gone quiet for the past while, though I
believe they're still hard at work on the project. Hopefully they can improve
the stability and performance of the program, because to date I've found it
almost unusable.

For a similarly interesting project (albeit not visual in the same way), I
recommend people also take a look a isomorƒ:
[https://isomorf.io](https://isomorf.io)

~~~
breck
Wow, thanks for putting that together. I think this is the best list of visual
programming tools I've seen to date. Very easy to scan with the images in
there.

~~~
spiralganglion
Thanks! Gradually adding more screenshots whenever I get the time. Glad to
know the format works well for you.

------
tyleo
Luna looks great. I've been doing work in this area myself and hope to launch
my own visual programming environment next month or so:
[https://imgur.com/a/zLS1g0t](https://imgur.com/a/zLS1g0t)

Unlike Luna though, my own environment does not have a dual-syntax
representation. It can import functions from TypeScript though and export them
as nodes. I also plan to target build tools rather than data processing.

I'm excited to see so much progress being made in this area. Two other
examples are NoFlo ([https://noflojs.org/](https://noflojs.org/)) and Flolab
([http://flowlab.io/](http://flowlab.io/)).

~~~
nikofeyn
everybody always seems to ignore the most advanced and general purpose visual
programming language/environment, that being labview. i suppose it is probably
because it sits behind an expensive license.

~~~
DonaldFisk
While doing research for my own dataflow language, I've had a look at LabVIEW.
There's plenty of online documentation available, but I didn't like some of
its design choices, e.g. how iteration and conditional statements are done is
overly complex. There are natural ways of doing these in dataflow which
LabVIEW doesn't use. Also, type inference is actually simpler to implement in
visual dataflow than it is in text-based languages, yet LabVIEW lacks it
(unlike Luna, and the dataflow language I'm still developing). Finally, every
dataflow program is a directed graph, which is the most general data structure
there is, so it really ought to be a fundamental data type - like Lisp's
S-expressions are.

However, LabVIEW is one of the oldest visual dataflow languages (AFAIK only
Prograph is older), and it's certainly worth learning about if you're
interested in visual and dataflow programming.

~~~
nikofeyn
> I didn't like some of its design choices, e.g. how iteration and conditional
> statements are done is overly complex. There are natural ways of doing these
> in dataflow which LabVIEW doesn't use.

would you mind elaborating? i would be interested to see what you mean. if you
are thinking of more functional ways like maps, filters, folds, and the like,
i have done that in labview. there is limited support though since labview
doesn't have lambdas, but you can pass around functions. however, that being
said, i don't really see a problem with the for and while loops in labview,
and i can't see how they are overly complex. they are about as simple as it
gets. condition structures could be improved, but i also don't quite see a
vastly different way to do it but rather tweaks that could be made.

> Also, type inference is actually simpler to implement in visual dataflow
> than it is in text-based languages, yet LabVIEW lacks it

i am not for sure what you mean here by saying labview doesn't have type
inference. labview is constantly running a type propagation algorithm that
checks whether all the types are hooked up correctly. additionally, labview
has malleable VIs, which is even more advanced. you can develop functions that
are polymorphic across types. you could do this before malleable VIs using
polymorphic VIs, but you had to manually create them. now, when wiring a type
to a malleable VI, labview will dynamically (at edit time) adapt the malleable
VI's types, primitives, and subVIs to adopt the new type. if it can't, it will
warn you. you can also wrap code with a type structure such that different
code is tried depending upon the type. again, it will check if a wired up type
has a given structure case that fits. it is similar to pattern matching on
types.

> Finally, every dataflow program is a directed graph, which is the most
> general data structure there is, so it really ought to be a fundamental data
> type - like Lisp's S-expressions are.

i agree that there should be a more fundamental type. i am not aware of any
language that does so, and even in the text-based world, lisp and scheme stand
alone in this feature (not surprising i like those languages as well).

~~~
DonaldFisk
Apologies for being mistaken about type inference, and thanks for correcting
me. Is this a recent addition, or was it present when first released?

My own dataflow language is described here:
[http://www.fmjlang.co.uk/fmj/tutorials/TOC.html](http://www.fmjlang.co.uk/fmj/tutorials/TOC.html)

The pages are incomplete as I've since added new functionality to the
language. I'm working alone, and have other commitments, so progress is quite
slow. It's a research project, and I'm not planning any release until I'm
happy with the language, and enough other people are sufficiently interested.

For iteration and conditional statements, FMJ doesn't require any separate
constructs or use syntactic sugar. Iteration is done by feedback, when and
unless by conditionally outputting other inputs depending on the value of the
first input.

My aim was to build a language capable of running directly on hypothetical
dataflow hardware, with the minimum of syntactic sugar, and I've mostly
achieved that. I'm now looking at problems for which dataflow machines would
be better suited for than conventional hardware, and by implication that
dataflow languages are better suited for than conventional languages. I'm also
looking for ways of reducing clutter (edges crossing), which is a problem with
graphical languages.

Regarding directed graphs as a fundamental data type, I haven't done much in
that regard yet, but it's high on my list of priorities.

------
deforciant
I have been successfully using Node-RED for quite some time now
([https://nodered.org/](https://nodered.org/)) :) really like it so far, great
tool to quickly add simple and complex health checks to your systems and
automate various tasks that no necessarily deserve to have their own services.
Kinda like your own FaaS platform (mine runs on an Intel NUC).

Luna looks great and I actually think I initially saw it and then I was
looking for it but couldn't find it, ending up with Node-RED. I might give it
a try, however I didn't see any mentions of how it integrates with Git :/

~~~
d21d3q
> I might give it a try, however I didn't see any mentions of how it
> integrates with Git :/

Like this: [[https://nodered.org/docs/user-
guide/projects/](https://nodered.org/docs/user-guide/projects/)]

------
PaulHoule
There are quite a few "boxes and lines" tools out there such as Alteryx,
Actian, LabView, KNIME, etc.

Many people swear by them.

I like that Luna has a text syntax.

I also like that Luna supports building graph functional blocks that can be
nested inside other graphs. That's a missing link in other tools of this type
that limits the scale of what you can do with them.

I'd like to see a tool like this which has something like a JSON document
going over the lines, but that might be asking too much. If the objects going
over the lines are basically relational rows you can do columnar execution at
very high speed. The Actian people have looked at alternatives to what they
do, but I think they haven't extended the data model past relational because
they couldn't get it fast enough to compete with their own product.

(e.g. a classic "disruptive technology")

~~~
Retra
I don't know... I look at this and I just see an alternative front-end for a
spreadsheet program.

~~~
crimsonalucard
Spread sheet programs are functional languages. Luna looks to be a functional
language, hence the similarity.

Spread sheet programs just have a bad rap of being used by non-programmers,
and limited functionality outside of the spreadsheet universe. Ignoring the
caveats mentioned, the principles of spreadsheet programming are
programmatically sound. Spreadsheet programmers are functional programmers.

~~~
PaulHoule
More to the point, execution of a spreadsheet does not progress in one
particular direction, rather when you update the data the engine can figure
out what cells are affected by the change. Business rules engines work in a
similar way, Prolog works in the exact opposite direction.

The trouble w/ spreadsheets I think is organizational. Some things are an
exact match for the 2-d grid, other things (say you fill out 5 numeric fields
and then calculate with scalar formulas to produce a similar dimensional
output) are easy to express with it (even if tk/solver is a better fit.)

Then you rapidly go over a cliff where you don't have the organizational tools
to handle it -- tuple and set values programming (eg. Matlab, Sql) is one
answer, object oriented is another.

~~~
crimsonalucard
> _More to the point, execution of a spreadsheet does not progress in one
> particular direction, rather when you update the data the engine can figure
> out what cells are affected by the change. Business rules engines work in a
> similar way_

Functional programming does not progress in a particular direction either.
What you describe is spread sheet programming, but it is also a description of
functional programming.

>Then you rapidly go over a cliff where you don't have the organizational
tools to handle it -- tuple and set values programming (eg. Matlab, Sql) is
one answer, object oriented is another.

It's not so much organizational tools vs. a different style of thinking. OOP
and sets can be used in both spreadsheets and functional programming (think: a
spreadsheet column can be thought of as both a set or a object struct and thus
both paradigms can be applied). Procedures and ordered steps cannot be used in
functional programming nor spreadsheet programming, hence the term "procedural
programming" which is what I think you are actually referring to in your last
statement.

------
jordache
Looks interesting. Then I saw the data collection disclaimer during the
install wizard. Deleted it in a instant.

You lose many potential clients just for that alone

~~~
rygxqpbsngav
Is this what you are referring to? [https://luna-lang.org/alpha-
data.html](https://luna-lang.org/alpha-data.html)

~~~
jordache
That page's disclaimer makes it look a bit more benign. THe install wizard's
disclaimer did not show the bullet list.

~~~
SamBam
They should put in an opt-out checkbox. Many people are happy to give small
orgs basic usage data to help them improve their product, but most people
don't want it forced on them.

------
jgtrosh
> Luna is the world’s first programming language featuring two equivalent
> syntax representations, visual and textual.

Is this true? This is not my strong domain but I'm sure there are such
programming languages.

~~~
TheAsprngHacker
The Scratch programming language has an unofficial text syntax called Tosh:
[https://tosh.blob.codes/](https://tosh.blob.codes/)

The in-development GP language can alternate between blocks and text:
[https://en.scratch-
wiki.info/wiki/GP_(programming_language)](https://en.scratch-
wiki.info/wiki/GP_\(programming_language\))

~~~
DonaldFisk
Scratch is a textual language with a visual editor and representation. Having
two easily readable, equivalent, representations for dataflow programs is a
lot more of a challenge.

------
lloeki
Very cool. Makes me think of Bret Victor's work.

[http://worrydream.com/#!2/LadderOfAbstraction](http://worrydream.com/#!2/LadderOfAbstraction)

This is the kind of visual programming I'd be ready to buy into.

------
ComodoHacker
>WYSIWYG language

Please, let's refrain from such awkward terminology. "Graphic language",
"visual language" are fine. "WYSIWYG data processing" is okay. But let's not
forget any graphic syntax is an abstraction.

~~~
pierrec
Yeah, I'm not sure how the term applies here. If you're using Luna to make a
program that generates output, "what you see" (the node graph) is definitely
not "what you get" (the output). Maybe you can have an inline preview, but
it's not what you're editing.

WYSIWYG describes domain-specific tools that let you manipulate the final
product directly (or a draft of it), without having to look at any kind of
source, be it a node graph or source code.

------
ebg13
I find the writing style on the site and in the docs to be extremely verbose.
My kingdom for some up-front concrete data examples without having to wade
through an essay.

~~~
PaulHoule
I don't think English is their native language. They should probably hire a
tech writer.

Also, tutorials and examples are the Achilles' heels of GUIs. I remember back
in the 1990s when you'd go to a bookstore and find 1200 page tomes full of
screenshots that would tell you how to do everything in Word 95.

Something that is "just run this script" in a CLI is a 20-page checklist with
screenshots with a GUI.

------
agentofuser
Neat! Anyone with more understanding can point out differences with
statebox[1]? Both seem to be:

\- visual and textual

\- purely functional

\- dataflow-like

I get the feeling that statebox might not be turing complete (guaranteed
termination) and have a stronger focus on formal verification. Also, it
doesn't seem to have a visual editor yet.

[1]: [https://statebox.org/what-is/](https://statebox.org/what-is/)

~~~
wires
hi,

I know Statebox pretty well :)

Luna not super well, but I did beta test their first release (and some later
versions), cool stuff.

Anyway, the two are (feature wise) very similar, as you noted:

\- both have textual/visual representations, \- are typed FP languages, \-
access to FFI/effects, \- diagram nesting

But Statebox is _not_ data-flow, it's more about "control flow" or "multi-
party protocol execution". (You could do data-flow with Statebox, but at the
moment that's prohibitively inefficient.)

Where Statebox takes a different direction (I think) is in basing the language
on established concepts from category theory and focussing on
'generality/compositionality' ; specifically, our diagrams are not "graphs",
but (morphisms in) categories.

This difference is very very subtle, in fact, seems totally irrelevant if you
want to visual programming (see the nice codex, clearly it works using
graphs!)

but it becomes more important when you want to diagram's to be "universal". at
least in principle, the Statebox language should naturally and compositionally
translate to any kind of hardware ; we want you to be able to program smart
contracts, p2p-systems, JS frontends, digital circuits, heck, maybe even slime
molds, all from the same diagram.

Luna certainly has more features at this stage.

(also, our editor is under heavy development and not yet published, we are
aiming to release some things around the statebox summit in september)

Maybe it's fair to say: Luna is like a better NodeRED, Statebox is
conceptually closer to something like homotopy.io / globular.science ?

Hope this clears things up a bit

------
didibus
I think the question I've always had with these visual languages is if they
target user friendliness and ease of use in the hope that non-programmers can
use them? Or do they actually think it'll be more productive for professional
programmers than text based languages?

I think for the latter, it'll be really really difficult to achieve. I can
maybe see the former, but I also worry for the former, these are too general,
and domain specific graphical tools will always dominate.

------
holtalanm
this has been posted on HN at least 4 other times in the past three years.

still interesting, but i don't do much data science, so will probably never
get a chance to use this.

~~~
TeMPOraL
Maybe you're interested in movies then?

As far as I remember the history correctly, Luna is a spin-off project from
Flowbox development - [https://flowbox.io/](https://flowbox.io/).

------
daemonk
Does it support any kind of HPC job launching feature?

------
JaimeThompson
How does Luna make money? I am worried about the possibility of features being
moved behind a paid version after people are tied to the product.

~~~
maxyme
They posted about this on HN before, basically they are VC funded and would
like to make their money back by providing community support and paid
features.

[https://news.ycombinator.com/item?id=14613264](https://news.ycombinator.com/item?id=14613264)

------
LudwigNagasena
How is it different from other ETL tools?

------
itodd
This looks interesting and I tried to play with it but the colors are so dark
and everything is hard to see.

~~~
stevenpetryk
I sound like a broken record but accessibility makes sites better for
everyone, not just disabled people!

~~~
rofrol
dark background is bad for eyes

~~~
blunte
For working late at night with low ambient light, "dark mode" styles are not
so bad. But in normal daylight, or worse - outside - dark mode UIs are
terrible.

It's a fad that I wish would stop propagating.

------
pankajdoharey
I've seen it so many times on HN, i wonder if anyone uses it in production?

------
wut42
The discord widget that eats part of the screen on mobile is very annoying -
besides the fact that another OSS project is using proprietary communications
systems.

------
skohan
Pretty nice looking website. Smoother performance than most pages with "fancy
scrolling" I often see.

~~~
Cilvic
Only nit bit from me is that the animations are playing a bit too fast to
follow along what's happening. Maybe that's intentional to "tease"? I would
want to slow them down a bit.

Would be great to just hit "Enter sandbox" or "demo" or see a tutorial without
the download.

------
DonaldFisk
It would have been a good idea to contact the developers before posting a link
to their project, to involve them in the discussion, and allow them to clear
up any misunderstandings about their work.

------
badsavage
Pretty cool

------
crimsonalucard
I didn't take a look deeply but that graph looks like function composition.
Looks like luna is a functional programming language.

