
Luna – Visual and textual functional programming language - interpol_p
http://www.luna-lang.org
======
wdanilo
Hi guys! My name is Wojciech Danilo and I'm one of the founders of Luna. The
timing for this news is a little unfortunate, because we are just before
releasing Luna as an Open Source project! However, it's great time to answer
some questions and give you a short update what has happened for the last
couple months:

1\. We've raised a seed round of $1M, so we can safely focus on product
development and shortly on community building! 2\. We've improved our core
technologies to be much more robust, open and extensible, including:

\- We've re-written our graphical interface to be much more open and
extensible (it was previously running on WebGL and now we base just on HTML,
so it will be possible to attach any HTML-compatible controls / visualisations
directly to nodes) \- We've implemented new, better type inferencer and
updated Luna compiler in many ways. \- And much much more, but I don't want to
uncover everything before the release, especially when it's around the corner
:)

I would love to answer your questions, so If you've got any, just post it here
and I'll do my best to cover it. Don't forget to singup for the list at
[http://luna-lang.org](http://luna-lang.org). We'd love to collaborate with
you during the upcoming release! :)

Cheers, Wojciech

~~~
amrrs
When you're talking about building a community, I'm wondering how are you
going to convince Data Scientists who are pretty much used to R and Python and
not any functional programming language, try Luna? Any plans for it? Like a
free course on Udemy or any mooc to take this to masses?

~~~
wdanilo
We are open to suggestions here. We know that Luna brings a great power to
Data Scientists but there have to be a good way to show this power to them. I
don't know currently what way would be the best and we've got a little time
until we do it. For now, the first milestone for us is to build community
around good programmers (including good programmers from the data science
field) and later target less technical people. Any suggestions however, are
very important to us!

~~~
marmaduke
I'd be interested in (and have some experience) in bridging Python with other
(data-heavy) languages, which would let you pull in a lot of functionality as
nodes in your graph, or expose your graph as functions in Python.

~~~
wdanilo
Great! I'd like to help make it happen. Please sign to our list and make sure
you read mails from spam folder. Let's be in touch after the release, soon.
Alternatively, just drop me a line at wojciech at luna-lang.org and let's stay
in touch! :)

------
Skunkleton
Here is the snapshot from when this was submitted to HN about a year and a
half ago: [http://archive.is/V2VwE](http://archive.is/V2VwE)

My question: what has changed? Has anyone addressed any of the fundamental
questions that were posed last time this was submitted? Are there any concrete
examples of how you might use this for general purpose programming?

~~~
sleibrock
That's more or less what I want to know. I've been subscribed to Luna for a
while but I haven't received any updates or news about it whatsoever. The
Twitter account is pretty dead. Even the images on the website seem pretty
sketchy since I doubt many of the images are actually real or represent
features of the editor. I've pretty much given up on this ever coming out.

~~~
wdanilo
We are alive! I'm really sorry for keeping you waiting for so long, we've been
doing our best to make everything happen in the best possible form and I hope
you will be happy with Luna after the release :) I'd be very thankful for any
feedback after the release, it would help us much!

~~~
sleibrock
Thanks for chiming in! Hopefully it works out for you guys! :)

------
TFortunato
Super super cool project! As someone who does robotics, I'm super eager to try
this, and to hopefully contribute to some open-source libraries for this.

A lot of work in robotics involves software that maps to this style well
(functional-ish, where data is being pushed through computational pipelines /
graphs), and I think this could be a killer development environment for things
like control systems, sensor fusion software, image processing / computer
vision, etc.

The fact that it is going to be open source, and already seems to have some
nice support for things foreign libraries, profiling support, and well as
visualizing of your data visually (that image processing graph example!) makes
me think you are going to get a good response to this. I also think there are
a lot of hobbyist type projects (RasPi level 'smart home' stuff, algorithmic
art / music, SDR, anything you see on Make / Hack-A-Day) who would love a tool
like this!

I'm very interested in checking this out, and in contributing packages /
libraries if that will be supported. Hoping to get access to the alpha!

~~~
whowouldathunk
> A lot of work in robotics involves software that maps to this style well
> (functional-ish, where data is being pushed through computational pipelines
> / graphs), and I think this could be a killer development environment for
> things like control systems, sensor fusion software, image processing /
> computer vision, etc.

LabVIEW

~~~
TFortunato
yep, and I've used Labview (and Simulink, and other graphical editors) in the
past for some of this.

Why I'm excited about this is: 1) It's open source, so we can extend it and
hack on it as needed. Thos is probably the biggest reason. 2) The dual textual
/ graphical representation is really useful in cases where you might want to
switch between the two, or one makes more sense than the other. You can do
some with text in some the other tools, but the last time I tried, it felt
like an after thought more than something expressly designed into the
language. 3) It looks to be designed as a general programming language,
focussing on having a good compiler, good tooling and a nice foreign function
interface. My hope is that this means we can incorporate it into our existing
code bases easier than labview, where it kind of wants to stand alone. As an
example, perhaps I have a large existing codebase for my robot written in C++
with ROS. Perhaps I could use this to create a new ROS node that does my
vision pipeline, by taking advantage of the fact it compiles down to native
code, and has a foreign function interface designed in from the start. (Or
maybe I'm dreaming, but my hope is it would be easier and more performant than
doing the same in Labview!) 4) Did I mention open source :-)

~~~
wdanilo
We would do everything we can to support such use cases. In fact we believe in
the same things TFortunato. I would like, however, to emphasize some things.
After the first release, connecting to foreign languages on the lowest levels
(like C++ foreign interface) will be possible but very hackish. Connecting
using serialized data will be of course very easy. Moreover Luna's backend to
compile to machine code needs still much love and this is our biggest
milestone after the release. I'm writing it just to ensure that I will not
"overpromise" anything, however the described use cases are very important for
us and we will support them as much as we can. Again, feel free to help us and
contribute :)

------
svtiger
May want to remove from your "About Us" bio: "hates Java Script" \-- can't say
I disagree, but you might alienate potential converts -- really should inject
as much positivity as possible. Any negative messaging will do nothing but
harm.

~~~
wdanilo
I prefer to alienate potential converts than convert JavaScripters! Just
joking of course. It is hard to hide hate to a non-language treated as a super
cool language. But you are right, I've never thought about it this way. I will
change it, thank you!

~~~
the_cat_kittles
in what way is javascript a non language? i write c, python and javascript- i
dont see how one is any more of a language than another? you are baselessly
pretentious

~~~
wdanilo
the_cat_kittles I did not wanted to hurt your feelings. Of course it is a
language. By saying it is not I just wanted to express my strong anty-JS
feelings, but they are of course very subjective :)

------
mastazi
So in the past I have used two self-proclaimed "visual programming languages",
Blueprints[1] and Max[2] and in both cases I found that it is actually harder
to be productive while dealing with UI elements than it is to simply write
code (as long as you have at least some rudimentary form of autocomplete I
guess).

However I have to say that, based on the little I've seen, Luna's UI seems to
be actually developer-friendly i.e. the UI elements go hand-in-hand with code
rather than getting in the way, I think it's brilliant, sort of Jupyter
Notebooks on steroids.

[1]
[https://docs.unrealengine.com/latest/INT/Engine/Blueprints/](https://docs.unrealengine.com/latest/INT/Engine/Blueprints/)

[2] [https://cycling74.com/products/max](https://cycling74.com/products/max)

~~~
crucialfelix
What is interesting here is that you can switch between code and visual
representation. All luna code can be looked at in either mode.

Max does allow you to use JavaScript or Java and they are doing a lot right
now with JavaScript interop/export.

~~~
mastazi
Thanks for pointing me in that direction, I should have looked at the JS
interop capabilities in Max.

------
athenot
Very nice! I feel this space is under-developped. Luna reminds me a lot of
Apple's Quartz Composer.

Visually representing anything complex is an immense challenge, but just like
code is broken down into units (files/functions/whatever), a visual tool that
can provide a fractal-like representation of a system would be awesome.

(I'm looking to dig deeper in this space for some pet projects.)

~~~
wdanilo
We feel the same way. As you have said, we use abstractions to hide complexity
in text-based source files, like modules, functions etc. We do the same in the
visual form. Every node in Luna is just a function, so you can "dig inside" it
(by double clicking it) and see how it is defined. We hide complexity just by
"collapsing" nodes together :)

------
daxfohl
I'd productize this more as the next level of "spreadsheet" than of
"programming language". These kinds of visual programming things always seem
to come out with lots of fanfare but then never get used for real work. The
spreadsheet, however, is by nature reactive, relational, visual, impromptu,
yada yada. But even though spreadsheet tech has added lots of functionality
over the years, it's still essentially based on an old paper grid.

I could see a product like this challenging that old basis with something more
modern. But it still has to do all the stuff regular spreadsheets can do too.
And ensuring that it can, and in an intuitive fashion, should probably be the
first priority.

~~~
mch82
Or start by doing enough of the stuff Excel can't do easily or at all and then
grow into what you've described. For example: * Plot 3d (x,y,z) and 4d
(x,y,z,time) graphs * Hook into data streams * Multi-user editing * JSON-like
data structures beyond 2d row-column data structures * Improved output
formatting

~~~
daxfohl
I'd be happy enough with floating sheets. To resolve those common things where
you've got two different sections, like an analysis with a summary section
below it. It's annoying because e.g. changing the column width on the top part
also changes the column width on the independent thing below it. A tool that
lets me put multiple independent sheets on the same page would be great. If
the tool can be programmed to run image processing algorithms on the same
page, that's fine too.

I'd view "IO" as almost equivalent to "Macro" in that instance. Though not
quite. I'd like to be able to have e.g. $A$1 be a filename and $A$2 be the
image in file $A$1, and that to be understood as a "pure" transform, even
though under the hood it's got to open the file. So "application-scope purity"
rather than process-scope purity.

------
indigo0086
Interesting. I wonder if this is the future of not only reducing the barrier
to entry to software engineering, but setting up a new tier of software
engineer for the unskilled. Rather, would software have lower barrier to entry
positions that are driven by piecing together software components like they
would a factory job. I'm sure for most software a team is only necessary,but
as software dominates our future, perhaps this is the bridge to unlocking more
opportunities outside of a higher skilled tier of manual coding. I'm just
talking off the top of my head, so I may be totally off base. Either way looks
interesting, and that futuristic interface is sweet.

~~~
stormbrew
This is one of those things that always seems like it ought to be the future
but for various reasons it doesn't take off. My high school computer class
used a programming language called ProGraph[1] that looked a lot like this,
but without the text representation, and it was neat but honestly it was
_more_ tedious to both read and write anything of even moderate complexity
than a pure textual form.

[1]
[https://en.wikipedia.org/wiki/Prograph](https://en.wikipedia.org/wiki/Prograph)

~~~
indigo0086
For sure without the text representation, or manual code aspect a language
would ultimately fail. I feel that languages that seek to "simplify" often
oversimplify and leave those that require more granularity (most programmers)
not to buy in. These languages can definitely offer a new paradigm on top of
existing languages but it requires some fine control to get mind-share and
ultimately take off. I'd say the real test of this, at least aligned with how
I see it's future, is recruit not developers but non-devs and see how
productive they can be in it, given they have a nice library of components to
work from.

~~~
stormbrew
I fundamentally despise this concept of 'non-devs'. There's just a cyclical
definition of non-devs as people who use non-dev tools and vice versa.

It's extremely common to dismiss tools used by certain classes of people as
non-programmer tools because of who's using them. Look at Excel, which is
basically a visual programming language that probably more people know how to
program in than know C. But because your boss or your project manager or your
sales rep uses it it gets dismissed.

Never mind that unlike these things that crop up every now and then people get
real work done by programming their computer with it.

~~~
tentaTherapist
Excel's programmability is vastly underrated for some reason. It's easily one
of the most high-level and successful languages ever, fulfilling a wide
variety of roles for countless people, so simple that a child could use it,
and so flexible that your boss probably does, too.

------
ajarmst
Given the name, I would expect this to be related to or built on Lua. That
doesn't appear to be the case. Is this echo accidental?

"Traditional software development is broken by design" is a pretty strong
claim, but the only support is a bunch of over-broad anecdotal claims about
what "always" happens. That's a bit offputting for some of us.

The phrase "Category Oriented Programming" is used like it's common
vernacular, which I don't think it is. Is it related to Category Theory? The
text seems to imply that the idea of mixing functional programming with
message-sending objects is novel. It really isn't.

"Unmatched performance and safety". Yeah. You want to be careful about that
claim. Going to need to see the independent evaluation results.

That said, for those who value diagrams highly, this looks interesting. I
wonder at what level of complexity the abstractions start to leak.

------
halflings
This is similar to Knime [0], which lets you build "workflows" visually, and
allow you to write custom blocks with Python or Java. The main difference
seems that you can represent the whole workflow in a human-readable (and
writable) format.

[https://www.knime.org/example-workflows](https://www.knime.org/example-
workflows)

------
agentultra
I find thinking visually to be quite limiting.

Although having a mixed textual representation is interesting. I sort of get
this with the Moose platform in Pharo which I use for analysis based work. The
most painful part of that though is interfacing with foreign systems. And
maybe Smalltalk... not a bad language but I've been bitten by the
Haskell/Lean/Idris bug. A seamless FFI experience as promised with this
language coupled with a toolbox rivalling Moose would be interesting!

~~~
crimsonalucard
What is text itself but a visual representation of something complex? I
repeat, text is intrinsically visual and just a restrictive form of the
alternative which is diagramming. Is it a pure coincidence that the english
alphabet happens to be the best primitive for representing programming
concepts?

I believe that there is no coincidence. English is horrible at representing
programming concepts. A limited set of characters, restricted left to right
reading and line based structures... is this really the best way to program?
Intuitively, things like recursion, data structures, processes, modularity and
objects etc, etc, are better represented with diagrams... Wouldn't Circles and
lines that can move diagonally across the 2D plane be better candidates as
programming primitives?

It's hard to say really. Functional programming is in itself a restrictive
form of imperative programming that gains power through restriction. It may
very well be that English as a programming primitive gains the same type of
power through restriction as well. Our brains have dedicated modules for
processing language as well as dedicated modules for processing geometry,
shapes and diagrams. Which module is better for programming?

Let's face it though, English as a programming primitive only became prevalent
for historical reasons similar to how javascript (a shitty, shitty language)
became prevalent. We like it partly because we're used to it.

There has got to be a better way.

~~~
agentultra
Math.

When learning graph theory it can be quite useful at first. But once you start
using set theory the graphical representation actually hides more information
than it gives and intuition starts to get in the way of us discovering useful
properties.

~~~
crimsonalucard
I think this visual stuff is perfect for functional (math based) programming
as composed expressions aren't easily readable as english.

I find language to be better suited for imperative procedures. Think about it,
I have a list of tasks, do I write that list in ordered English bullet points
or do I draw a diagram?

~~~
agentultra
I find simple math to be much more elegant and easier to comprehend then a
jumbled visual diagram. It's much easier to understand a universal
quantification in a standard notation than reasoning by visual analogies.

Programming languages tend to be a little less expressive and elegant. They're
more complicated too. For reasons of course... but I don't think I'm going to
be writing algorithms and data-structures in such a tedious notation as a
diagram.

Graphics are good for some things but programming I don't think is one of
them.

~~~
kustosz
Some things look best in text and it's fine. However, "programming" is a very
broad category, and definitely does not boil down only to algorithms and data
structures. I'd even say that most programming tasks in the world right now
are much less about complex algorithms and much more about everyday systems
plumbing. Sure, at some point you'll need to fire a complicated linear algebra
kind of algorithm, but before you get there, you need to get the data out from
some source, do some reformatting, decide which algorithms to run and when and
then send the results somewhere else. And for that, seeing what is happening
with your data the moment you try a solution, and deciding the next step based
on immediate feedback is great.

This is pretty much why we've gone with interchangeable representations
instead of going "visual only". The choice of the proper tools /
representations highly depends on the context, and we want to leave that for
the programmer's decision.

------
danyeaw
One of the examples I saw you guys give on YouTube is how complex things are
becoming, and you talked about the LOC of a modern car and this is a reason we
need visual programming. On your website you also discuss the limitations of
UML.

To design complex systems like a car, you really need to know not just the
functionality and the type of information, but also the structure of the
system. How do all of those systems on the car physically connect to result in
the behavior.

It seems like your approach would be really powerful for data processing,
since in that case I don't think the structure matters much. Have you thought
about how this could be applied to a complex system where structure is
extremely important?

------
mixedbit
How do you envision version control/code reviews with Luna projects? Can diffs
be explored at visual level or only source code level? If one developer moves
nodes around without altering any logic are such changes tracked in the code
repository?

~~~
kustosz
For starters we've made sure to make git diffs as readable as possible. The
visual data is kept at the end of text file (hidden when using our editor),
usually in a single line. So if you just move nodes around, one line gets
changed and it is clear what to ignore when scanning the diff, while making
sure to retain the changes in the repository. For later stages, we envision
much deeper integrated version control, including viewing git diffs in the
visual editor.

~~~
libeako
This sounds bad. Any info in the text related to the visual representation
will be unreadable i guess. Hiding such for diff review is helpful but not
enough. Because in merge conflict resolution one may not have the luxury to
neglect it.

------
kazinator
> _Traditional software development is broken by design_

Which is why Luna is entirely hosted within itself and needs a Luna
implementation to bootstrap.

We wouldn't want to ask investors to believe in any traditional development
after telling them it's broken.

------
zimablue
This idea will eventually work and be huge I think (I know visual programming
languages already exist but a commonly used one to emerge). As someone who
believes in metaprogramming and flexibility though I'm hoping for something
dynamic, not a heavy mandatory type system that compiles to Haskell.

~~~
wdanilo
We believe in something very similar, there are some differences though. Luna
type system is not dynamic BUT it is also not mandatory. Our whole standard
library does NOT mention a single type - all are inferred by type system and
you can, if you want, state them explicitly. To sum this up, we want Luna to
be simple to use, intuitive, but have a strongly typed backbone with power
similar to Haskell or Idris IF needed. Does it makes sense to you? :)

~~~
zimablue
Thanks for your response and that does seem like a nice compromise, but it's
still not perfect to me.

If the choice is <untyped>|<haskell>, it's better than just <haskell> but I'd
love some <gradually typed, allows side effects>

Good luck with your project, looks pretty cool

------
thecity2
I like the idea of category-oriented programming. Would be interested to see a
white paper on what that means.

~~~
kustosz
This feature is a bit of a misnomer, as it immediately brings up discussions
about category theory. That being said, the idea behind it is pretty simple,
yet powerful. Our typechecker will be able to track the shape of data on a
deeper level than usual types. Basically will be tracking the exact
constructors used to construct data, not just types – something that is a huge
pain in most existing typed languages. If you for example take Haskell, you
can have a data type with multiple different constructors, and even though you
may be certain that some of those are impossible to occur at some points in
your program, it is difficult to express that certainty on typelevel – other
than repacking to a different datatype, with less constructors, which then
need to be named differently and need repacking even if you're just calling a
function that expects a wider range of constructors, and thus is definitely
safe. However, due to the amount of work with more foundational layers of the
language, we've had to postpone implementing this feature until further down
the line. It is coming at some point for sure, though :)

~~~
tentaTherapist
That sounds like a horribly leaky abstraction if you mean that you're
literally going to statically track the call stack to attempt to verify
invariants. Hopefully it's just a misunderstanding on my part.

------
ruffrey
Is this related to the luna programming language experiment by TJ Holowaychuk?

[https://github.com/tj/luna](https://github.com/tj/luna)

~~~
mendelk
There is also a framework by this name that is (was?) being developed by
Asana.

Naming is hard in the global namespace!

~~~
samratjp
Yeah it was -
[https://news.ycombinator.com/item?id=2191800](https://news.ycombinator.com/item?id=2191800)

------
a-nikolaev
Looks like a lazy functional Python ) Very nice aesthetics of presentation.

There are a few things I am concerned, if you don't mind: I think that
actually visualizing lazy computation can be quite a challenge, because of its
on-demand nature. One might say that a lazily defined expression is computed
(and should be visualized) where it's used, rather than where it's defined.
There is a lot of substitutions going on under the hood, and computation is
not as clearly localized as it would be in eager evaluation. Also, the tight
binding between the code and the visualizations may limit your ability to
optimize code for efficiency.

The True / False switch looks cool, but it feels like you are cheating here a
little bit by using a boolean literal. Would it look equally nice if it's a
function call or some complex expression that is possibly not known yet (as in
a function definition)? I have a feeling that at the end of the day Luna may
require a very complex visual language that is not easier than the textual
alternatives.

But this is more like arbitrary concerns that will be hopefully clarified once
you release the whole system. Thank you for your work.

Thumbs up for exploring these new alternative for writing code. I think, it
may help us write better and safer programs in the future.

------
adgasf
Why implement a new language rather than a GUI on top of Idris, PureScript or
similar?

(That aside, very excited!)

~~~
kustosz
We needed to design everything from scratch to make sure the two
representations are truly interchangeable. Every design decision in the
textual language needs to be backed by its visual counterpart, and we found
this way of thinking impossible with any other existing language. Then there
is the problem of complexity of existing, typed, functional language. We aim
to make things as simple as possible, while not sacrificing the power of
types, in order to make the language accessible for a much broader audience.
I'm super happy to hear that you like it, make sure to sign-up for our
newsletter, so we can stay in touch once Luna is out :).

~~~
wdanilo
I would love to emphasize one of the thoughts from @kustosz reply: our main
goal is to make Luna simple and intuitive yet very powerfull. We've got super
cool type system on top of purely functional language, however we put our
hearts to make the syntax (both visual as well as textual) very simple and
intuitive. Neither of the mentioned solutions - Idris, PureScript nor Haskell,
Erlang etc are "simple" and "intuitive" to use unless you are really good
programmer.

~~~
tycho01
I'm reading the Idris book now, and one cool thing there is guessing bits of
implementation based on the type declarations (there written before
implementation).

I imagine in a visual environment, being able to make useful suggestions on
potential ways to use/combine different nodes/types would help as well as an
auto-complete for the user's intent.

I'm actually also a bit reminded here of MS Excel Power Query, which also
offered a GUI for data transformation, see e.g. [this
pic]([https://blogs.office.com/wp-
content/uploads/2015/07/6-update...](https://blogs.office.com/wp-
content/uploads/2015/07/6-updates-in-Power-Query-for-Excel-5.png)).

I bring this up because I see you covered visualizing the steps, while they
focused on showing the data (though after finishing a transformation the
script could be generalized into a reusable function). I wonder if adding a
dimension like that could be helpful for Luna as well.

If you target non-programmers, showing things as concrete as possible (e.g.
their data transformed by whatever function they just pulled together) sounds
like it might help make things even more accessible.

------
agentgt
Just some minor critiques.

What is confusing to me is if the visualization actually running the code or
is just static analysis of the code?

The reason I ask is if its running then what you have built is a language with
an absolutely awesome visual REPL. If it is please say its a language with
awesome visual REPL! A potential Excel for programmers killer. There are
languages that tried to do this (Squeak, and Racket come to mind) but they
were generally academic and more often for students/young adults (and not for
businesses).

However you say whiteboard through out your marketing which makes me think
brainstorming tools ala evernote, orgmode etc. I realize for VC they might
prefer whiteboard.

Whiteboard to me is sharing and not really a tool. It means I have to register
and create a profile when all I really want is a language with a powerful
visual REPL. (again just my point of view on marketing).

~~~
kustosz
Why don't we have both? And then some more. It is an awesome REPL with a bit
of Excel feel. Runs the code whenever you change it and displays the results
in real-time. It is also great for interactive data sources (like web
services), where you get the results as soon as they appear upstream. The
whiteboard part is super important too. Visual representation is great for
design and brainstorming. Even more so, when it provides runtime feedback
about your designs. And it gets even more important with collaboration. So at
this point we've got a collaborative whiteboard that actually runs the
computations. There is, however, one more part to the story. Neither
whiteboard, nor a REPL are well suited for implementing the final, production
software. We aim to blur the lines between the design and implementation
phases, allowing to deploy whatever has just been "sketched".

------
msd81257
I'd love to hear how this might be applied as a general debugger concept for
CUDA and the likes. To a layman like me, CUDA's GDB debugging interface has
always left a sour taste in my mouth due to the high amount of parallelism
that simply can't be displayed through a debugger entailed to be used only on
a single thread. I'd love to see someone working on (and I'm probably going to
take a crack at it myself ;) ) not just using this interface as a language,
but also as a debugging tool for other languages. Decomposition of CUDA (and
other -- thinking Erlang right now especially) programs into bite-sized
visualizations in order to program and debug would be invaluable for the
space.

~~~
wdanilo
It would be supper cool to debug CUDA with Luna, but keep in mind there is a
really long way until it will be possible. It is however very interesting path
and I'm super curious where it could lead us to! I'm willing to support it as
I can if you would like to try do it by yourself. You will be even able to cut
off our backend and use the GUI for your purposes, however more interesting
(and even probably also easier) way to do it will be to make some abstractions
in backend and build the graph using provided by us backend server, its API
and replacing only the interpreter / compiler plugins. To sum this up, a very
interesting idea!

------
FridgeSeal
This. Looks. Awesome!

I literally cannot wait to try this out on some data processing/number
crunching stuff!

The integrations with the likes of Python are super exciting as well - any
plans (even remote ones) to do the same with Julia?

~~~
wdanilo
I'm glad you like it! :) I'm very curious about your feedback after using
Luna, don't forget to keep in touch with us after the release!

We do not integrate with any language, because the visual representation is
just a different syntax for Luna. In fact we keep both syntaxes - textual and
visual with the same powers, so you can switch between them, but they are just
syntaxes for the same language.

Integrating with Julia (or other lang) would be hard because the language has
to be designed in such way that it will allow for such dual representation. We
put an enormous effort to design Luna this way. However it will be possible to
integrate Julia in such way, that some of the nodes would be written in Julia
and then even allow to in-place expanding nodes to small text-editors to
preview the code in place. It will however not be possible to translate Julias
code to graph or vice versa.

------
murukesh_s
Awesome, we need more visual programming languages coming out now. it's so
impossible to convince a programmer who never experienced visual programming
how useful/practical it can be.

I understand you are from a video processing background where visual
programming is widely employed.. We are also building a visual programming
platform, inspired from enterprise tools. Really interesting to see this
domain evolve.

------
mrkgnao
This looks really beautiful: what's it written in?

Also, "Num in IO", nice. Now we wait for someone to write a "(Num in IO) in
IO" action.

~~~
wdanilo
Hi! We write almost everything in Haskell. By the way, Num in IO in IO is
completely ok function signature - it means that you have a function that uses
IO to optain a function which will return a number while performing another IO
action :) However it is completely ok in Luna for the end user to type it
simpler, like `a :: Num` and the compiler will keep track of all "monad
transformers" under the hood.

~~~
rjeli
I think this is a really good idea -- many people, myself included, get really
excited about Haskell and then are turned off by the complexity of monad
transformers.

I would recommend that you focus on good error messages that explain monad-
related errors in "user land" and not force them to either guess about what's
wrong or suddenly learn all the stuff under the hood. It's a terrible
experience and you see it in C++ with incomprehensible template errors or any
kind of transpiled language like ClojureScript that gives you errors from the
underlying implementation.

~~~
wdanilo
That is a very good point. We treat "monads" in a very special way in Luna -
they have their own type section and we can analyse them and report errors
much clearer than Haskell can for example. This does NOT mean that we limit
them in any way. You are free to define your monads and convert them to
ordinary types or back as you wish :) But we normally dont describe them as
monads, just as "context", because it is easier to understand.

------
bussiere
I haven't tested it yet but i mind if this is possible to make microservice
with this ?

Like defining an port (like 80) an input (a json like {"example":0} make an
operation an return a value by the same port and json.

It could be an nice way to include micro service into a larger eco system or
make people collaborate using luna in larger project.

For python you may use hug or flask

That s an interesting idea btw

good job and good luck

------
be5invis
You say you have dependent types

OK, could you define this?

    
    
        data Eq : {a : Type} -> a -> a -> Type where
            Refl : Eq x x
    
        sym : {x : a} -> {y : a} -> Eq x y -> Eq y x
        sym Refl = Refl
    
        replace : {a : Type} -> {x : a} -> {y : a} -> {f : a -> Type} -> Eq x y -> f x -> f y
        replace Refl p = p

------
shalabhc
Examples on the home page have broken indentation, or just a multi-level
indentation that is confusing?

    
    
        class Point:
            x y z :: Int
          origin      = Point 0 0 0
          Point x y _ = origin
          print 'Origin XY coords are ($x,$y)'
    
    

(Why is `origin =` indented at all?)

~~~
wdanilo
You are right, all the last 3 lines should be aligned max to the left. We'll
fix that soon on new website!

~~~
shalabhc
Another thing, this example wouldn't type check unless it is verifiably a list
of non blank strings:

    
    
        print [s for s in lst if s.head != '_']
    

The section about dependent typing says `lst.head` would be a compile time
error in some cases.

------
pekr
Isn't it similar to what Eve tries to achieve? Well, what I like in overal, is
an attitude and courage to introduce new technologies! I come from the Red
language camp, which if I am not mistaken, is also being funded. So - good
luck, guys :-)

~~~
cmontella
Yeah, we have a lot of the same views about programming, but our focus isn't
on data science. We can definitely agree that the practice of programming in
the future won't look like it does today.

------
gfaure
Wojciech, this is incredible! The combination of expressiveness, type safety,
visual programming and API focus are pretty unique right now.

By the way, "Aggresive compile-time optimization" should be "Aggressive
compile-time optimization".

------
jancsika
Where are the node positions stored?

~~~
kustosz
We store them in a separate section in the source file, which is hidden by
default when editing. So a bare .luna file is a readable text file, containing
some metadata at the bottom, which is not shown when editing with our editor.
This way we achieve clear representation and full portability of the source
files.

~~~
jancsika
Nice.

A few more questions:

Is does z-ordering just follow the painter's model?

As a user am I allowed to place two nodes at the same x/y coordinate?

As a user am I allowed to position nodes in a way that creates a visual
ambiguity in the diagram (e.g., two or more perfectly overlapping edges among
nodes)?

Edit: As a user am I allowed to place a node at an x/y that lies within the
bbox of another node?

~~~
wdanilo
1) it uses painters model 2) you are allowed to place in the same x/y, but
we're looking for a way to indicate it to you. 3) you are able to place nodes
so the edges overlap, but we also are looking for a way to indicate it to you.

Keep in mind, that point 2 and 3 does not happen during your workflow
normally, so these are very rare situations. We want to support them just from
the "purity" perspective, but they are very low on our priority list
currently.

~~~
jancsika
So in terms of git, Luna users won't be able to comprehend the visual z-order
and positional changes by glancing at a diff. And those types of changes will
come freely in the normal course of development.

That means that Luna requires some kind of visual diffing step to reach parity
with the development flow of text-based languages. Otherwise developers will
get comfortable interpreting metadata changes as noise. In specialized
languages like Max/MSP that leads to spaghetti programs. In more general
visual languages it could probably even lead to security issues if an overlap
suggest a different visual data flow than the source code. (And judging by
Pharmaceutical TV commercials, people blithely favor the visual over the
written when there's a discrepancy.)

------
jtha
I truly hope you will succeed in your mission. It looks like it could solve so
many problems that I've come across as a result of confusion and
miscommunication when people with a common understanding step away from the
whiteboard and start coding. It can be so hard to align the implementation
with the visual abstractions we so desperately need to communicate as humans.

------
fareesh
Cool concept - is there an open source repo of some kind which shows how a
complex application (kitchen sink kind of app) is made?

~~~
wdanilo
Thank you! We will be releasing demos soon!

------
adamgravitis
Are you guys going to release something describing your concept of "category
oriented programming" any time soon?

~~~
wdanilo
We will try to cover it alongside the upcoming release! :)

------
pjdorrell
If Luna is dependently typed, can it be used to do theorem proving, eg like
Idris?

------
danem
I'm struck by the similarity to grasshopper. This seems to share many of the
same features such as visual profiling, visual / textual representation, live
previews etc... Has it inspired the design at all?

~~~
wdanilo
Grasshopper did not, but Houdini / Touch designer actually did.

------
libeako
I would like to subscribe to the news, but am afraid to use news-letter
services. I suspect they sell the addresses to spammers. Would you please
instead set up an atom feed or a primitive blog on Blogger?

------
polskibus
What is it compiled to? Does it target JVM, CLR, native code (if so what
platforms?) What is it compiled with? LLVM ? GCC ? Custom compiler? What is
the standard library like?

~~~
wdanilo
It targets few backends. Currently it runs on our VM, but we are working on
targetting GHC's Haskell Core (which then compiles to LLVM IR). Luna's
compiler is of course a custom compiler written in Haskell. Standard library
looks cool!

Did I answered your questions? :)

~~~
vopi
>standard library looks cool

What does that even mean? No offense, but like I haven't seen any demos on
your website and you are describing the std lib as cool? Not exactly
confidence aspiring.

It looks interesting for sure and looks really fun to mess around with
(frankly has a hobbyist high school programmer who likes systems programming,
I don't see a whole lot of use for me :))

Good luck.

------
dlitvakb
I'm super interested in this project! I'd like to see how interop really works
and how to get multiple data sources interconnected to produce amazing
datasets.

~~~
wdanilo
Im happy to hear that. We do our best to realease it soon and I'd love to
collaborate further with you then!

------
_RPM
Any relationship to TJ H's repo,
[http://github.com/tj/luna](http://github.com/tj/luna) ?

~~~
kustosz
Other than name – none at all :)

------
pekr
Isn't it similar to what Eve is trying to achieve?

------
cdevs
What beautiful black magic programming even despite the fact that I hate flow
chart programming like unreal and other game engines do.

------
toisanji
I'd like to see how the visual representation of larger non toy examples look.
Looks like a very cool project !

~~~
wdanilo
hi! Each node "contains inside" graphs of nodes. You can literally select
nodes and collapse them into one, new "function". This way you just raise the
abstraction level, just like in textual-sources, however in the graphical
environment it is just more pleasant to select nodes than re-factoring
functions in text :)

------
hustlechris
so when's the ICO?

------
sullyj3
Looks cool! Is the editing environment extensible enough to support an
embedded neovim instance?

------
Meai
It sounds like it wont compile to C or use LLVM, you have some kind of custom
VM?

~~~
wdanilo
We are not going to compile to C, however we will to LLVM IR (not directly
though). During the first release we will provide Luna interpreter (so yeah,
some kind of custom VM). We are however already working on the backend that
compiles Luna to Haskell's GHC Core
([https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Co...](https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/CoreSynType)),
which then gets different functional-programming related optimizations and
translates to LLVM IR.

------
247yak
anyone try bubble.is? Love to get a comparison on how this is better /
different.

------
pikachuaintcool
Pretty bad name, I thought it was a typo for Lua.

~~~
wdanilo
We use the name for a long time now and we love it, however I agree it could
be confusing. We failed, however, to find a better one.

I've got a crazy idea here! I know that HN has some magical powers, so if you
have any idea of a better name for a dual-representation, functional, visual
language, we'd be more than happy to talk about it and change it before the
release (after the release it would be too late)! :)

~~~
pikachuaintcool
I mean, I don't care if you keep it as Luna. Just saying you're gonna have
problems if you keep that name

~~~
wdanilo
I completely understand that, but we care about it very much and don't want to
have problems with it. Because of that I asked about help with the naming :)

~~~
etiene
I'm a huge Lua fan and I got excited for a moment thinking it had any
connection to it, then I was disappointed that it didn't, even if Luna does
seem like a great piece of tech!

Here goes some suggestions:
[https://en.wikipedia.org/wiki/Phoebe_(mythology)](https://en.wikipedia.org/wiki/Phoebe_\(mythology\))
[https://en.wikipedia.org/wiki/Zana](https://en.wikipedia.org/wiki/Zana)
[https://en.wikipedia.org/wiki/Notus](https://en.wikipedia.org/wiki/Notus)
[https://en.wikipedia.org/wiki/Jaci](https://en.wikipedia.org/wiki/Jaci)

------
jlebrech
I like to see a language that's a simple subset of ruby for example but the OO
is delegated to a graphical representation (boxes for classes, arrows for
methods etc..)

~~~
wdanilo
I'm afraid Luna is not for you then! However, I strongly doubt that
visualization of OO concepts will bring you a productive environment. I also
believe that the combination of functional programming and visual paradigm is
the way to go here :)

~~~
CyberDildonics
How do you do basic branching and loops?

~~~
wdanilo
Each node is a function, so if a node uses itself, you've got recursion
(loop). Branching like if is just few edges going into a node and the result
goes out :)

