Luna – A WYSIWYG language for data processing(luna-lang.org)
luna-lang.org
Luna – A WYSIWYG language for data processing
https://www.luna-lang.org/
86 comments
I love these. Here's one more: http://blog.interfacevision.com/design/design-visual-progarm...
You'll find that link, and a few other great ones like it, on the "Reflections" page of my codex: https://github.com/ivanreese/visual-programming-codex/blob/m...
My favourite is the "Gallery of Programmer Interfaces" by Jonathan Edwards: https://docs.google.com/presentation/d/1MD-CgzODFWzdpnYXr8bE...
I can also heartily recommend following Edwards on Twitter: https://twitter.com/jonathoda
My favourite is the "Gallery of Programmer Interfaces" by Jonathan Edwards: https://docs.google.com/presentation/d/1MD-CgzODFWzdpnYXr8bE...
I can also heartily recommend following Edwards on Twitter: https://twitter.com/jonathoda
Hey @spiralganglion, thank you for your wonderful codex. The signal:noise ratio is superb, and the referenced materials are amazing.
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.
Thanks! Gradually adding more screenshots whenever I get the time. Glad to know the format works well for you.
yeah, the list is very interesting to read. The screenshots are a plus !
Hi and thanks !
Why not include https://www.native-instruments.com/en/products/komplete/synt...
Reaktor NI since you have max/msp and pure data on the list.
Yep, I should add that to “Inspirations”
Max and Pd are included in “Implementations” because you can use them to do general purpose programming — they just excel at audio thanks to a great standard library.
Max and Pd are included in “Implementations” because you can use them to do general purpose programming — they just excel at audio thanks to a great standard library.
you should add Houdini, it's the biggest of them all.
Great suggestion. I love Houdini — such a neat twist on the traditional "one gigantic workspace" 3D software format.
Houdini is the best!
Also Substance Designer and Nuke.
Also Substance Designer and Nuke.
Have you seen https://machinations.io/ ?
I have not, and that looks amazing! Thanks for the recommendation.
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
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/) and Flolab (http://flowlab.io/).
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/) and Flolab (http://flowlab.io/).
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.
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.
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.
> 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).
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).
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
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.
My own dataflow language is described here: 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.
I would add that not only the license is quite expensive, but it has a confusing "syntax" that most often than not results in unmaintanable software.
> it has a confusing "syntax" that most often than not results in unmaintanable software
that is more that most people who program it don't put in the time or effort to program it in a professional way. personally, i do and was trained by people who did and do, and so i have seriously complex systems built out of it that are far more maintainable than other people's systems built out of python and c/c++, which are the unfortunately choices for system development where i have worked.
the point is, just like with any language, you have to settle on the (or an) idiomatic way of working in the language, and you have to be disciplined to develop modular, decoupled code. once you do so, i find that labview's dataflow paradigm actually makes it easier than most languages to develop dependable, robust, and maintainable code. the reasons that people like functional programming languages with immutability apply to labview.
people writing unmaintainable software in labview is a symptom of the people and not the language. every time labview is brought up in meetings as the target language, there is often a gut reaction by people, but to be frank, those people actually know very little of the labview language, have never used its OOP features, are not even aware of its debugging capabilities and tools, and thus, their opinion is moot. just because someone used labview in college in a trivial way but didn't like it doesn't give them a professional voice with regard to labview. all they usually want to do is develop unreliable systems using c/c++ or python because that's the "hardcore" way of doing things. and yet, it's those projects that are often pining for help in the end when things aren't working.
so yes, labview is different, but if you treat it differently, it can greatly increase your efficiency and ability to quickly turn around robust systems. i develop systems in time units of months, not years, and my software is well known to just work.
what would you say the "confusing syntax" is that leads to unmaintainable software?
that is more that most people who program it don't put in the time or effort to program it in a professional way. personally, i do and was trained by people who did and do, and so i have seriously complex systems built out of it that are far more maintainable than other people's systems built out of python and c/c++, which are the unfortunately choices for system development where i have worked.
the point is, just like with any language, you have to settle on the (or an) idiomatic way of working in the language, and you have to be disciplined to develop modular, decoupled code. once you do so, i find that labview's dataflow paradigm actually makes it easier than most languages to develop dependable, robust, and maintainable code. the reasons that people like functional programming languages with immutability apply to labview.
people writing unmaintainable software in labview is a symptom of the people and not the language. every time labview is brought up in meetings as the target language, there is often a gut reaction by people, but to be frank, those people actually know very little of the labview language, have never used its OOP features, are not even aware of its debugging capabilities and tools, and thus, their opinion is moot. just because someone used labview in college in a trivial way but didn't like it doesn't give them a professional voice with regard to labview. all they usually want to do is develop unreliable systems using c/c++ or python because that's the "hardcore" way of doing things. and yet, it's those projects that are often pining for help in the end when things aren't working.
so yes, labview is different, but if you treat it differently, it can greatly increase your efficiency and ability to quickly turn around robust systems. i develop systems in time units of months, not years, and my software is well known to just work.
what would you say the "confusing syntax" is that leads to unmaintainable software?
You are absolutely right and I should have been clearer on my first reply.
Most of my contact with LabView code was built by people that had no professional training on it. They use it to automate "simple" scientific experiments and create visualization dashboard, since they're mostly self-taught their software needs a re-write every 3 years. Again I believe you are right, that is mostly due to the programmer not being knowledgeable about the language itself.
Regarding the syntax, most of the LabView code I've seen was built by people with the aforementioned knowledge of the language, so It is possible that I've never seen good LabView code. But I never liked the looping and conditionals.
Most of my contact with LabView code was built by people that had no professional training on it. They use it to automate "simple" scientific experiments and create visualization dashboard, since they're mostly self-taught their software needs a re-write every 3 years. Again I believe you are right, that is mostly due to the programmer not being knowledgeable about the language itself.
Regarding the syntax, most of the LabView code I've seen was built by people with the aforementioned knowledge of the language, so It is possible that I've never seen good LabView code. But I never liked the looping and conditionals.
Alteryx is another one, and it's super popular in the business world.
LabVIEW is limited to the research and academic realms AFAIK.
LabVIEW is limited to the research and academic realms AFAIK.
Yours looks like Xod.io, one of the visual languages available for Arduino.
(We also do visual programming, though for algo trading.)
(We also do visual programming, though for algo trading.)
I haven’t seen that one yet. Looks neat. Algo trading is a really interesting application. I’m planning on starting out with a visual markup language editor (.json, .xml, etc) and continue with more advanced build tools if that is successful. I think it would be great to be able to visualize a dependency graph.
What has your experience with Xod been like? Have any advice?
What has your experience with Xod been like? Have any advice?
Cool! I've worked in this space for years as well. Another good recent article about visual programming is: https://divan.dev/posts/visual_programming_go/
Out of curiosity, what sort of work have you been doing in this space?
Almost a decade ago I worked on a visual web IDE called NudgePad, did some visual stuff for FirefoxOS, and a little bit of visual stuff at Microsoft.
Currently I'm working on a data science tool called ohayo (https://github.com/breck7/ohayo) that combines text coding with visual programming. It's geared toward similar use cases as RStudio, JupyterLab, Tableau or Observable, but takes a different approach.
At a higher level I'm working on Tree Notation: http://treenotation.org/. My not-at-all-humble contention is that this syntax is a breakthrough that will allow visual programming to become commonplace generally (it already is in some fields with tools like labview/excel/unity/tableau/etc) , because with it you can create programming languages that have the property that the code written by humans or machines(visual tools) is the same. Hence, whether you write the code by hand or use the visual tool, you'll still have great, clean code. With current EBNF languages or XML/JSON/etc languages the interaction between humans and machines is a mess.
For a decade I've also researched programming languages extensively and have a ton of data on over 10k languages at this point.
Currently I'm working on a data science tool called ohayo (https://github.com/breck7/ohayo) that combines text coding with visual programming. It's geared toward similar use cases as RStudio, JupyterLab, Tableau or Observable, but takes a different approach.
At a higher level I'm working on Tree Notation: http://treenotation.org/. My not-at-all-humble contention is that this syntax is a breakthrough that will allow visual programming to become commonplace generally (it already is in some fields with tools like labview/excel/unity/tableau/etc) , because with it you can create programming languages that have the property that the code written by humans or machines(visual tools) is the same. Hence, whether you write the code by hand or use the visual tool, you'll still have great, clean code. With current EBNF languages or XML/JSON/etc languages the interaction between humans and machines is a mess.
For a decade I've also researched programming languages extensively and have a ton of data on over 10k languages at this point.
Cool, I started working on something similar a while back but I didn't get past handling generics. Like if you have a node<T> with two T inputs and a T[] output, then when you attach a number to an input, the other input's type becomes number too and the output becomes number[]. That could need to propagate to connected nodes, too. Also when you disconnect a node, you would want to determine whether T must still be a number.
Is that something you're handling in your project? Do you have any pointers?
Is that something you're handling in your project? Do you have any pointers?
Devev is written in TypeScript and the TypeScript compiler is open source so I’m able to leverage it directly. That, in addition to the GitHub project ts-simple-type takes care of most of my difficulties.
However, I don’t support generics as first class citizens in the node editor yet and probably won’t for V1. I can detect that an input/output is a generic but I convert it to any before use.
If your project is based on an existing language I’d recommend taking a look at injesting compiler tools if they are open source.
However, I don’t support generics as first class citizens in the node editor yet and probably won’t for V1. I can detect that an input/output is a generic but I convert it to any before use.
If your project is based on an existing language I’d recommend taking a look at injesting compiler tools if they are open source.
I have been successfully using Node-RED for quite some time now (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 :/
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 :/
> 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/]
Like this: [https://nodered.org/docs/user-guide/projects/]
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")
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")
I don't know... I look at this and I just see an alternative front-end for a spreadsheet program.
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.
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.
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.
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.
> 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.
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.
Spreadsheets are an example of incremental computing(see adapton for formal research).
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
You lose many potential clients just for that alone
Is this what you are referring to?
https://luna-lang.org/alpha-data.html
That page's disclaimer makes it look a bit more benign. THe install wizard's disclaimer did not show the bullet list.
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.
What did it say?
> 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.
Is this true? This is not my strong domain but I'm sure there are such programming languages.
All programming languages can be reduced to an abstract syntax tree as the canonical ("equivalent") representation of a program, with visual and textual views. I'm sure there are prior examples - HyperCard, Max/MSP, ..
Edit: Gotta say, I love x3 the design/aesthetic/presentation of the Luna language.
Edit: Gotta say, I love x3 the design/aesthetic/presentation of the Luna language.
This is not true. GameMaker does this at the very least. You can swap between the visual and direct GML language whenever you want.
I seem to remember a visual javascript thing which had the same feature.
I seem to remember a visual javascript thing which had the same feature.
The Scratch programming language has an unofficial text syntax called Tosh: https://tosh.blob.codes/
The in-development GP language can alternate between blocks and text: https://en.scratch-wiki.info/wiki/GP_(programming_language)
The in-development GP language can alternate between blocks and text: https://en.scratch-wiki.info/wiki/GP_(programming_language)
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.
Unreal Engine's Blueprint language has an equivalent plaintext form. You can copy nodes from the visual editor, paste them to a text editor and vice-versa. I think it's more a form of serialisation, but code is data is code...
For example: https://blueprintue.com/blueprint/h6gkslt6/
For example: https://blueprintue.com/blueprint/h6gkslt6/
I guess this hinges on exactly what meaning is hidden in the word "equivalent", I could imagine that a very tight coupling of text and visual forms would be novel.
Yes, exactly. Depending on the definition of "equivalent", Puredata[0] may or may not qualify as well.
[0]: https://puredata.info/
[0]: https://puredata.info/
Does Pd have a textual representation intended to be human readable?
I guess only Miller Puckette can provide an answer about the intention.
It also depends what we consider human readable: Does it mean that some or many or most humans can read it? It's a custom plain text format[0] that is perhaps a little bit less readable that HTML. I have been reading and writing Pd patches in textual representation (and I'm human). Not sure if that's an answer to the question.
I've seen a Scheme editor that does visual representation, slightly similar to Scratch, but can't remember the name of it.
AsciiDots is both visual and textual (although it's not two different syntaxes).
[0]: https://puredata.info/docs/developer/PdFileFormat
[1]: https://github.com/aaronjanse/asciidots
It also depends what we consider human readable: Does it mean that some or many or most humans can read it? It's a custom plain text format[0] that is perhaps a little bit less readable that HTML. I have been reading and writing Pd patches in textual representation (and I'm human). Not sure if that's an answer to the question.
I've seen a Scheme editor that does visual representation, slightly similar to Scratch, but can't remember the name of it.
AsciiDots is both visual and textual (although it's not two different syntaxes).
[0]: https://puredata.info/docs/developer/PdFileFormat
[1]: https://github.com/aaronjanse/asciidots
Everything is saved as plaintext, but it is not meant to be readable really. here's an excerpt from some of my code.
#N canvas 340 73 884 380 10;
#N canvas 0 0 1362 686 sendchord 0;
#X msg 241 135 60;
#X msg 240 167 64;
#X msg 241 200 67;
#X obj 191 173 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144
-1 -1;
#X obj 283 450 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144
-1 -1;Hello world in Pd:
#N canvas 0 0 100 100 100 10;
#X obj 0 40 print;
#X msg 0 20 hello world;
#X obj 0 0 loadbang;
#X connect 1 0 0 0;
#X connect 2 0 1 0;
You've got 20 magic integers with no explanation in the source. Java version does not contain that.
Yup. Magic integers are bad for readability. So are "magic phrases", like public static void.
I think the readability of Pd is horrible, but the question was whether it was human readable at all.
I think the readability of Pd is horrible, but the question was whether it was human readable at all.
I don't think they're in the similar category at all. Keywords are part of the syntax - if you know what they are in one place, you know what they are in another. (even if they have multiple meanings) Magic numbers are use-specific and you need extra context to understand them. They're part of the code, not the language itself - although the language can help the situation by enforcing naming in some cases.
Well, I think many programming keywords have a form of meaning that you need extra context to understand. How would I intuitively could guess what 'public static void' was, withing having any idea about OO or Java? I mean, 'void' is perhaps OK, but don't tell me you could understand 'swing' with no context, just by reading the word?
Yeah. Its purely hype on luna's part.
Very cool. Makes me think of Bret Victor's work.
http://worrydream.com/#!2/LadderOfAbstraction
This is the kind of visual programming I'd be ready to buy into.
http://worrydream.com/#!2/LadderOfAbstraction
This is the kind of visual programming I'd be ready to buy into.
>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.
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.
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.
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.
An abstraction of what? If the paradigm is dataflow - i.e. capable of running directly on (hypothetical) dataflow hardware - a graphical representation is more natural than a textual one.
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.
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.
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.
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/
- 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/
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
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
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.
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.
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.
still interesting, but i don't do much data science, so will probably never get a chance to use this.
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/.
As far as I remember the history correctly, Luna is a spin-off project from Flowbox development - https://flowbox.io/.
Does it support any kind of HPC job launching feature?
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.
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
How is it different from other ETL tools?
This looks interesting and I tried to play with it but the colors are so dark and everything is hard to see.
I sound like a broken record but accessibility makes sites better for everyone, not just disabled people!
I've seen it so many times on HN, i wonder if anyone uses it in production?
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.
Pretty nice looking website. Smoother performance than most pages with "fancy scrolling" I often see.
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.
Would be great to just hit "Enter sandbox" or "demo" or see a tutorial without the download.
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.
Pretty cool
I didn't take a look deeply but that graph looks like function composition. Looks like luna is a functional programming language.
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