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.)
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 :)
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.
I'm not sure what the idea even means, or if it really warrants a separate paradigm than OOP. Is it related to category theory? Frustrated that a 'new' paradigm got dropped on me with only a couple sentences of explanation.
It's not a bogus! We are FP enthusiasts and the word "category" has really strong connections to our type system. However, the name might be a little misleading so we've already changed it. Anyway, we treat our types as categories. For example 1 belongs to a singleton category 1 (thus you can write 1 :: 1) but it also belongs to category of positive numbers or all numbers in general, thus again you can write (1 :: 1 :: Nat :: Int :: Num :: *). I hope you see now connections to category theory. However the name itself, as I noted above, could be misleading so we need to change it.
Yes it is, `1 :: 1 | .. | 10`. The pipe combines categories, so you can as well write `1 :: 1|2|3|4|5|6|7|8|9|10`. Both of the forms are however not yet supported in the main branch of official compiler and will not be supported during the first release yet.
I wouldn’t say it’s bogus, and there definitely wasn’t any malicious intention behind it, it’s just that finding a name for such a property is super difficult. As I’ve written above, it’s about having fine-grained control over the data (object) constructors. It turns out most words synonymous to “type”, “kind”, “category” etc. (as understood in the wide sense) are already taken by mathematical / programming concepts. We will, however, change the name, as it causes way too much confusion :).
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 :)
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.
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 :)
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.
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.
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.
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.
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.
Visual programming languages lower the barrier of entry for _programming_ not software engineering. There are many mature and successful examples of visual programming languages that do just that (LabView, Scratch, etc...)
This is what I was thinking. Any critique of this approach may want to keep in mind this isn't necessarily going to replace what software engineers are doing now, but rather expand what is done by others by lowering barriers.
Here is the snapshot from when this was submitted to HN about a year and a half ago: 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?
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.
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!
My guess is they ran into problems with syntax. If they alter their language slightly to be an ETN, it could help. Happy to chat more if any of them are reading.
Actually we did not run into problems with syntax! The syntax we were presenting last time has changed only slightly. I'd be happy to chat more about it! You can grab me here or message me directly at wojciech at luna-lang.org :)
Hi! I'd be happy to cover any of the fundamental questions you are refering too. I was trying to cover them last time, but if there is something uncovered, I'd be more than happy to fix it :) Would you be so nice and specify what are your concerns?
Regarding the questions, I've just put some small summary of updates on the top level of this thread. Regarding real world applications, Luna will be well suited (but not limiting to) to interactive data science, creating custom data visualisations, microservices management, rapid prototyping of any data processing networks (inlcuding IOT systems) and of course graphics or sound processing.
Hey, super excited to hear that all of this is being open sourced. Visual programming isn't something I have had positive experience with in the past, but it seems like you have introduced new concepts and new UX that may change that. I would love to read a technical write up about the design of the language.
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!
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.
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.
IMO the graphical representation some times removes accidental complexity by not needing names or producing orderings. eg. To write a non-tree graph you always need to introduce local names unless you use something like SKI combinators. When proving the Kuratowski-Wagner theorem for example, I'm pretty sure the diagrams and the language-form help each other without either being strictly better.
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?
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.
Are you familiar with category theory? I've been finding it very helpful for processing things visually. Considering this is "category oriented programming," I'm betting they find it helpful, too ;)
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.
What's funny is when we program we use ASCII art (indentation, things like the fact that [ and ] cause symmetric "box" look) to help us. If text was really all we needed, writing minified JS directly would be ok. Given a keyboard and a mouse, this was the fastest way to create nested boxes (ASTs) that have non-tree links (names): type out a serialization of it that your fancy text editor automatically ASCII-artifies.
I think it really depends on the kind of problems you are trying to solve: expressing programs visually is very common in signal processing (see for instance GNU Radio and Pure Data) because the flow of the signal through different components is one of your main concerns. Also having easy to tweak parameters in the form of knobs and sliders widgets, or adding for instance an oscilloscope node anywhere anytime, aids your development workflow a lot.
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.
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?
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.
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.)
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!
> 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.
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 :-)
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 :)
LabVIEW is great, however I'd love to just roughtly outline some important differences:
- Luna works in a purely functional environment, which allows for much more clear and easier to understand graphs. Moreover it enables us to run computations in parallel automatically (without any input from the user, however we will be supporting it very slightly during the first OS release).
- Luna allows you to convert between textual and visual representations - in both ways, always.
- Luna is a real programming language, so it is not just a pack of predefined components. Every component is created out of other components (or functions, you name it), so you can always go as deep as you want or just connect functions from other languages.
- Luna allows you to collaborate in many people on one, visual canvas.
Hi! I'm always very happy to hear that Luna would help in a domain that I personally don't know much about! :) I would be very happy to collaborate with you. Contributing to Luna in any form, including creating libraries is more than welcome and we will do our best to help you achieve your goals with Luna, so let's stay in touch, we are working hard to make release as fast as we can! :)
Thank you, I will! If something happens and after the release I will accidentally forget about reaching you out, just write me an mail to wojciech at luna-lang.org. I'd be more than happy to collaborate with you! :)
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..)
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 :)
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 :)
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. We'd love to collaborate with you during the upcoming release! :)
Answering the question more directly, we will be providing payed support and hosted computing environment with automatic scalability in the future, however now we will be focusing on building community and helping everyone gain from what Luna has to offer, keeping Luna completely open source and free.
What kind of plots can you make with this? This has real potential in the big-data and scientific fields. Plotting is hard and if you can easily tie together many data sources and models that are popular onto time series and geospatial plots this will be a winning combo go scientists.
You can connect to our data ANY HTML/JS compatible visualisation. Moreover Luna has some basic (and they are getting better with every day) bindings to drawing over webgl canvas, so you can define visualisations using our nodes. We will be showing examples how to define efficient heatmaps / custom plots using few nodes interactively in Luna. We will be more than happy to collaborate with you and anyone interested in data visualisations soon, so lets stay in touch! :)
If you can, internally, handle adding together multiple data sources you'll win in the academic space with something like this. Especially if you can choose a Python syntax for the "code" portion.
In scientific spaces you have many data sources that all mean completely different things. They are all recorded in different coordinate spaces (mag, distances, polar, etc) and you want to plot many of these things into the same plot and have them go where they were meant to be.
If you could generate 3D plots as well just by flipping a switch that would be a huge plus. The hard part is that we have many modeling softwares that are written in strange ways and in strange formats. One example of a very popular model with a difficult interface is the IRI (http://irimodel.org/). If you could just link a node of "IRI" into "Earth Plot" then that would be awesome.
We would not rewrite anything again soon :) We decided to rewrite it because of all the gains we gather from it (including both features as well as much increased speed of development) and it already (almost) payed off.
There are no hold-ups really. We just want to release Luna in a form when you will tell "oh, that's a cool project I would like to contribute to" rather than "interesting, let's wait until it is usable". We are right now finishing installers on all platforms, making examples and working on new website. I don't want to set a deadline, but we work hard to make it just "around the corner" and a you can see, we're almost there :)
Really cool you chose to do an image processing demo with the "color grading" example. That is such a natural fit for visual programming. I could see Luna fitting into a video post-production or digital asset creation pipeline for games. The combination of a visual interface and functional logic could be used to create mind-blowing custom procedural solutions! Have you given any thought as to what media libraries you might use for the final stage rendering of audio, video, bitmaps, 3d scenes, etc. Because I think it's possible it may be entirely done in HTML5 / JS...
The thing there is that is already how image processing and compositing has been done for 30 years. Check out Nuke, Digital Fusion (which is free), Shake, Flame, etc.
@CyberDildonics, I think that @indescions_2017 was referring to pipelines suitable to be run inside game engines, working at "runtime", not batch-processing data upfront. You cannot utilize any of the software you mentioned to do it. You can use Houdini engine, but it's image processing capabilities are super limited currently and even if they improve, you are limited to thinking in the context of SOPs, DOPs, CHOPs etc, without being able to extend it with custom datatypes and procedures.
TouchDesigner (https://www.derivative.ca/) or vvvv (https://vvvv.org/) are more comparable, since these systems DO work in realtime environments. But yeah, you still have to think in the context of SOPs, TOPs, CHOPs...
You cannot embed touchdesigner in a game engine (at last with ease). VVVV does not comes with abstraction over DOPs SOPs etc, but both are still very limited regarding what datatypes they can process.
Are you asking about Luna? :) Sure! Luna comes currently with its VM but we are also working on a backend allowing to compile it to machine code, so every graph you write can be also used as a library and called for example from C.
Actually Houdini's COPs are very capable, I use them all the time. Also you can define custom procedures/nodes using vex as text or as a separate node interface.
I know Houdini very well, I've been writing plugins to it for years. Vex is capable of handling complex expressions, but it is still limited to predefined 20 or 30 types and you cannot extend it (you can in a hackish way using some C++ interface, but lets assume that this is just too hackish). This also effects the UX of Houdini, you can often see nodes with 30 or 50 inputs that look strange (like the std material definition). If you are able to define custom types, you can collapse related parameters into new types.
I'm not talking COPs or Houdini is something bad. It is one of the few applications that I support with whole heart and I love it. In fact Houdini is a very rare example of really well defined visual DSL.
Luna differs in many ways, the most important are that we've got double representation and Luna is a real programming language, while Houdini provides you limited set of building, yet very powerful blocks. I would however love to see Luna used within Houdini as a plugin, I've been already speaking about it with some folks :)
Can you elaborate more on the dependent type system? Is type checking decidable? What restrictions does it have to keep automatic type checking feasible?
We were thinking how to answer this question yesterday, but it is just too broad and I've literally cannot afford explaining all the caveats now. I will be supper happy to talk about it after the release on Luna forum, so if we could just move it there and discuss it in some short time, I would be thankful :)
We were thinking how to answer this question yesterday, but it is just too broad and I've literally cannot afford explaining all the caveats now. I will be supper happy to talk about it after the release on Luna forum, so if we could just move it there and discuss it in some short time, I would be thankful :)
We are not really making a programming language. So, err.. ok, we are. But it is "just" an engine. Luna is a data processing platform. It allows you to prototype, design and deploy data processing applications much faster than it is currently possible, while working in an elegant, interactive data visualization environment. Moreover, we are supported by many cool companies that want to use Luna for their purposes, including IOT, Data Science or Bioinformatics ones. We got a really big interest in our technologies and we've collected the whole round in less than 6 weeks, choosing the investors we liked among many that wanted to contribute. I'm writing about it because I'm really very grateful for their help and super happy that the need for such development is widely recognized.
There is a big difference between what Luna is and who we target with our website. We want now to keep in touch with good developers and build community around them and make Luna a dancing and singing complete development environment with high-level libraries useful for less technical people. The libs we include are very limited currently, so Luna would not be very usable for non-technical people in its current state. Does it make sense? We will try to explain it better on our new website though! :)
Qubex, I'm sad such comment appeared. I'm sad only because it shows how rare people are honest while building companies. How can we build something that engages other people and cheat on them?
Look, we've been working on Luna for over 2 years now, full time in a team of 7 people. We were often working during weekends or hardly sleeping at nights just to create what we believe in. We were constantly using software build the same way - linux, ghc, atom, etc. Now we want to give it completely free for everyone and we want to survive not because we want to be reach or famous, only because we so deeply believe that Luna really can drastically change something important in the data processing field. We will not survive without people engaged in this project, without people that will make it shine in different domain specific fields. We don't want then to "close" it - it will always be open and free (which is somehow guaranteed by the license too). As a company we need to make money too, but how could we make money not being honest?
We want to build community around good developers only because Luna could be a big development boost for them and additionally, we can together bring it to less technical people and help them too in their daily tasks. If people like what we do, we can then charge for support and additional paid services, developed by us, but I think it is really fair deal and companies should be built this way.
Sorry for a little long answer, but I got that sentence emotional! :)
This response strikes me as either coming from a mindful person willing to show public vulnerability or someone who has studied such people & learned to mimic how they communicate. My own experiences with mindfulness suggests categorical thinking naturally goes hand-in-hand with (and may naturally emerge from) being in a mindful state, so I'm more inclined to think you're not a well-researched phony. I also prefer to give people the benefit of the doubt.
I'm feeling really inspired, hopeful, and happy when I read comments like these because I consider the lack of vulnerability in the startup world to be as sad as the lack of authenticity. Thank you! I hope you'll keep doing what you're doing.
I was prompted to write my original comment by the simple fact that (usually, in my experience) people stick to the half-truths that are easiest for them to communicate, rather than embracing the hard work of truly conveying their inner meanings (note the plural). To wit: once a website is up and a coherent (albeit incomplete) ’truth’ has been ”put out there”, rarely would I expect the author of that website to turn around and say ”that is the self-serving story we wish to convey to one subset of our potential audience, those who self-select by relying on our website for information”. It's a very intellectually honest approach to admit that the content of the website is not Truth but rather some kind of social mechanism, every. It as ’functional’ as the code itself, and serves the a ’propagandistic’ purpose.
Collectively I summarise all of this as ’candor’. ;)
Wow. That's exciting. I wouldn't think it would be possible to get a programming language funded, but you found a way. I look forward to seeing where things go. Good luck!
Thank you! I'm looking forward for your feedback and creating something powerful on top of Luna! In case of any questions (after the release), we'd love to help!
I really like this on multiple levels, because its something I've been thinking about for many years (and even took various stabs at implementing):
I love the visual/textual dual language concept - I've been trying to figure out a good solution where both work well and no information is lost from one by editing the other (eg if I create something visually, but edit it textually, does the layout get ruined?) and, at a glance, you seem to have largely solved this or at least managed to get it working well enough. Awesome.
I also like this as a tool for data processing. This kind of platform is something I've been wanting to build (and prototyped once a number of years ago even) for a long time. Couple it with a simple (and familiar) spreadsheet system and your golden (for my purposes - other people may think otherwise).
I haven't looked at Luna in any detail yet, really just glanced at the screenshots so far (I hope to read the material properly tomorrow), but one concern that jumped out at me was that the visual language semantics aren't clear to me. Of course, its probably unreasonable to expect to understand a new language without having read the documentation, so its unlikely to be an issue. I only point it out because I've seen a number of other visual languages claim to be super user friendly (even to non-programmers in many cases), when, IMHO, it really isn't unless you already deeply understand the concepts. I didn't see you making this claim though, so all good :)
Overall, I'm excited for this and wish you the best of luck. Hopefully you will choose me for alpha access so I can play with it ;-) :-P
Thank you for such an awesome comment and your attitude! :)
We've put an enormous amount of work to address the issues you've covered - including creating a system where you can edit text / graph without breaking the other one.
I'm happy that so many people were thinking to do something going this way - we hear it often. This shows us that this need is widely seen and there is nothing we want more than just collaborate with these people. We will be releasing Luna shortly as Open Source project and will be helping growing community around it. I will be supper happy helping utilizing / extending it for your needs!
As I described before, the timing for this info is not the best, because Luna is not yet available, but it will be really shortly.
Luna introduces some abstraction levels. Some of the leaves (the highest ones) could be usable by less-technical people, but of course only after they get familiar with the concept! :)
Thank you and looking forward to building something interesting together! :)
You might want to adjust the colours, and look at it on a few more screens. The medium grey on dark grey is pretty unreadable - the only reason I didn't close the page immediately is the number of upvotes it got on HN.
Would it help if we put a button "high-contrast"? On vast majority of displays the website looks well balanced and not eye-burning, but of course it does not cover older displays, displays that are dimmed or used in heavy lighting. Would such button solve your problems or do you think we should just strongly re-consider how we present everything?
I think people would miss such a button, especially since the unreadable stuff is after you scroll down.
For what it's worth, I've tried the page on 7 screens/devices here, and it was only properly readable on 3 (two of which are very similar models by the same manufacturer). On three of the screens (two really new), it was more trouble than it was worth.
We are also super curious and we hope it will shine. If you hope for it too, let's contribute! We'd love to work with you to polish it as much as possible! :)
Maybe with documentation? I could at least help with editing / proof reading and the drudge work you guys are too talented to be doing! Your time is much better spent on the core development.
There is always a way to help and we are very grateful for helping us. It means a lot to me. But please, do not treat us like "too talented to do something". I feel just wrong then :)
Drop me a line at wojciech at luna-lang.org and we could work something out :) I do not promise we will be able to collaborate before the release (we've got our hands full of work and we're hardly sleeping in nights now), but in the early days / moths after the release the help would be much needed and we would love to build community around people as passionate as you are! Thank you! :)
Sorry for putting off. I will explain that a little bit - we want to build community around people which are active, passionate and determined enough to fill such a form. I understand why it could be perceived negatively, sorry for that! :)
I don't disagree with you, though don't necessarily agree, either because I don't know that passionate people are communicative people. I know many passionate people, myself included, who've been known to be rather introverted.
After reading some of their comments & the copy on their homepage, the creators of Luna sound like they could be fairly mindful people. I'm betting they're seeking people who enshrine certain values to seed their community with & want to privately establish a relationship with them. I find this approach appealing to my introverted side, as a result.
The next mindful step would be to open things up to everyone immediately to allow the ensuing flood of extroverts & introverts alike. This approach seems like it could counter starting off with winner-take-all mechanics in the community's culture.
Then again, all I know about the product is from the first bits of text on their site & this post. I didn't know they weren't simply allowing everyone in until this thread. I could be totally off on how they're rolling. If I am, I'll have to take some time to examine my confirmation biases.
crawfordcomeaux I'm really curious about your further thoughts. Could we chat more about it? Would you be so nice and drop me a line to wojciech @ luna-lang.org ?
Wouldn't it be trouble if I tried to visit you at your office tomorrow? :) Not sure if time (and traffic) will let me, but I'm in the same city, and super interested in your project... would love to talk some... note: not an investor in any way, sorry ;) but I wanted to build something similar in some ways, and now have high hopes that maybe I won't have to, maybe I'll be just able to build on it/extend it! If you're ok, what time would be cool for you?
Sure, it's a super cool idea. Let's drop me an email to wojciech at luna-lang.org and we set all the details (time / place etc) - we've got a parking place here, but its "hidden" so if you will be driving car, you can park here without problems! :)
We are not looking for any investments now but we are looking to collaborate with everyone interested in Luna, so that sounds like a "perfect match" for us! :D
What is the largest program written in Luna? How does Luna compare with other mainstream programming languages for complex applications such as compilers, browsers and web applications?
The standard library is 3-ish kLOCs (written entirely in Luna) and growing, the biggest use cases we've created so far were around 500 LOCs. Performance-wise, we are letting the GHC compiler infrastructure do most of the heavy lifting. As for the more complex applications, it may be tricky to create a compiler or a web browser in Luna in its current state, but we are constantly working on on improving the performance, with the goal to match Haskell's. Web applications (particularly microservices) are among our main focuses now, so that's entirely within our reach.
Im just wondering what's the purpose of the language itself. Ideally you would like to use the programming language you want and still have the visualisation stuff.
Sure! Is webgl good enough for you? If so, I will prepare an example and include it in the official release. If you need more "standard" GPU power, then it will be possible, but a little bit hackish on the beginning (we don't have libraries for it yet and you will need to connect to other language to keep the performance. We will support language interoperability, but in the first reelease it will be hackish. Still if you'll need it, I'll show you how to do it) :)
So do you have first-class support for video as well as images? It seems like to have fun with video editing in Luna, you'd need to have built-in support for videos an inputs and outputs, and have a way to play the video output on the screen, and maybe scrub through it, and at a minimum be able to run shaders on the "current frame" and export the resulting video out. The next level after that would be being able to load multiple frames into memory at the same time, and being able to do a combination of "offline" and "online" processing with some CPU involvement (e.g. calculating a motion track and storing it, or applying a filter that can't be expressed as a pure shader program).
I don't know enough about Luna yet to know what code to do these things would "look" like on the visual side, or come to think of it where the computation is being performed (in the browser?). Much more to learn, but the project looks great, a sort of "holy grail" in a way.
Hi! Thank you for such great description of the process. In fact I know it well, I originate from the same domain - i was working for few years as FX TD :)
You can think of Luna just like about a general purpose programming language. You can define your own types and you can even define how to decode bits from binary files to your structures. The GUI runs in HTML, so you can utilize any html component to display output. Definitely, your use case is doeable, however the amount of libraries currently available is very, very low, so it will need some love :)
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?
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!
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.
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! :)
The power of e.g. matlab for engineering disciplines is in the profound library. The optimized performance of the core language not withstanding, optimizing the library takes many people, often enough graduates, doctorates and professors.
No gil. Draw your own neural network, pipeline or graphical model in an idiomatic way. If you can display profiling data on top of the code visualization you can go faster toward optimizing the most time consuming parts of your code. For a data scientist all this is gold.
No gil. Draw your own neural network, pipeline or graphical model in an idiomatic way. If you can display profiling data on top of the code visualization you can go faster toward optimizing the most time consuming parts of your code. For a data scientist all this is gold.
This is what we want to deliver a little bit later. So you could go to our website, click "start", make the graph and everything will be run and scaled automatically for you, delivering you the results. Are we talking about the same functionality? (I'm abstracting over particular hardware provider).
This really looks fantastic, and I'd love to give it a spin. I could see this being pretty awesome to both use myself on projects, and with people I spend time with helping them learn to develop serious applications. Looking forward to see where Luna goes. Congrats on a great-looking product!
"we are just before releasing Luna as an Open Source project!"
Is there a particular timeline on that? I'd love to see how this is implemented (and - importantly - whether or not this can easily be integrated into other software).
We are right now finishing installers on all platforms, making examples and working on new website. I don't want to set a deadline, but we work hard to make it just "around the corner" and a you can see, we're almost there :)
I'd love to see unit testing and/or contracts added too. Being able to define a graph, define a requirement for a step, and then outsource development of just that step could be awesome.
> previously running on WebGL and now we base just on HTML, so it will be possible to attach any HTML
Just in case anyone else faces this issue, another possibility is to do WebGL-above-HTML two-layer hybrids, with punchouts to see the synchronized HTML. But perhaps not worth the pain for 2D UIs.
Hmm. Last year I half-started a quick hack of atom.io with CSS3D in Vive VR. Intended for purescript et al. But the display's angular resolution was painfully low for working with text. It looks like Luna might be an interesting alternative for exploring coding in VR.
Also on my infinite todo list are exploring VR direct manipulation of a category-theoretic pushout lattice of <types,ops,laws> theories, and (separately) an interactive editor for string diagrams...
You said, other languages can't really directly be transformed to graphical luna nodes, can you say why?
Because I gave this some thought as well and don't see why not in general, but I don't know how luna works .. or if there are some restrictions I did not encounter yet ..
This is a really good question and to be well covered it needs a really deep answer. I will write a short draft here due to lack of the time, but will be happy to talk more about it after the release. Maybe a blog post would be suitable here, just an idea worth considering by our team :)
If you are thinking about visual language you have to think about many constructions that collectively give you user experience, including available basic construction blocks (how looping, branching works etc), structures, lambdas, every language construction, how you give hints to user what is possible and what is wrong and additionally how to do this real 2 way transformation of code and graph.
Luna infers types and displays colors according to them. We use algebraic data types, lazy evaluation, pattern matching and purely functional paradigm which suits graph visualization really well. We fine tune performance by allowing lazy data visualisation and many, many more things. I don't know how we can even visualize standard OO abstractions to be usable and pleasant to work in the visual form. It does NOT mean we did not think about it. We did for a long time.
Sure you can utilize Luna gui to visualize anything, including python code, but it would be insanely hard to deliver similar functionalities to what Luna offers out of the box (which is available by careful design of both representations).
I feel thin answer is very vague, but I hope I put a little light on how complex this task is. Did I answered your question (at last partially)?
I would like to try out the beta once you publish(soon?), to see more what you do and understand better (and see whether my ideas could be compatible, or not)
Another thing I've been thinking about in the past is how do you preserve formatting when translating between visual/textual. Eg, if I place a visual node and then edit the text, does it preserve my visual layout? This is important because I've used Max/MSP in the past and I would logically lay out the code by function to make it easier to comprehend. Similarly, preserving whitespace in the textual form even when editing the visual form.
I don't know if or how luna handles this, but its a concern that I've had trouble with when I was thinking about something similar in the past.
It does preserve. We keep some special markers in the text files and we track the position of the markers. The markers have associated metadata kept on the end of source file. Neither markers, nor metadata is seen during the graph editing, so it works transparently for the end user.
How do you cope with syntax errors ? e.g. saving garbage tex as source code ? And reversely, can you have visual informations that can't be pretty-printed as text easily? (e.g. nodes without names)
How do you expect the visual syntax to integrate with VCSs? Do you have an algorithm and UI to present visual conflicts? How is the layout after a Git merge?
Cześć Wojtek! Congratulations on raising funds for your very promising project. I am happy that such smart concepts are being developed in Kraków, Poland.
Two questions: How does Luna compare with flow-based programming model implementations such as Apache NiFi and its Expression Language or NoFlo? And do you find Luna appropriate for Internet of Things real-time data processing?
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.
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...), which then gets different functional-programming related optimizations and translates to LLVM IR.
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)! :)
Janus/Ianus? Two headed god of.. You know what, I'll just link the wiki page:
> In ancient Roman religion and myth, Janus (; Latin: Iānus, pronounced [ˈjaː.nus]) is the god of beginnings, gates, transitions, time, duality, doorways, passages, and endings. He is usually depicted as having two faces, since he looks to the future and to the past.
Thank you for this name! I really like the connection, it is in fact super cool. The only thing that puts me off when thinking about this name is that "Janus" is a very similar name to "Janusz", which is in polish a name used very often to describe in jokes greedy and unfair entrepreneur :D
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 :)
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!
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 :).
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.
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 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.
The irony being that this itself is a Haskell-like environment, and a complex, dependently-typed one at that, with full type inference and strange function name choices (in my opinion, of course.)
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.
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.
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.
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.
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!
330 comments
[ 4.6 ms ] story [ 300 ms ] threadVisually 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.)
You may wish to address people who consider themselves "Designers" rather than "Programmers".
Seems as if platforms for computer graphic systems production- like Unity or Unreal - would provide a receptive audience.
I wonder how they would react.
[1] https://en.wikipedia.org/wiki/Prograph
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.
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?
Regarding the questions, I've just put some small summary of updates on the top level of this thread. Regarding real world applications, Luna will be well suited (but not limiting to) to interactive data science, creating custom data visualisations, microservices management, rapid prototyping of any data processing networks (inlcuding IOT systems) and of course graphics or sound processing.
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!
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.
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.
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?
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.
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.
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?
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.
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.)
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!
LabVIEW
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 :-)
- Luna works in a purely functional environment, which allows for much more clear and easier to understand graphs. Moreover it enables us to run computations in parallel automatically (without any input from the user, however we will be supporting it very slightly during the first OS release).
- Luna allows you to convert between textual and visual representations - in both ways, always.
- Luna is a real programming language, so it is not just a pack of predefined components. Every component is created out of other components (or functions, you name it), so you can always go as deep as you want or just connect functions from other languages.
- Luna allows you to collaborate in many people on one, visual canvas.
And much more! :)
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. We'd love to collaborate with you during the upcoming release! :)
Cheers, Wojciech
Answering the question more directly, we will be providing payed support and hosted computing environment with automatic scalability in the future, however now we will be focusing on building community and helping everyone gain from what Luna has to offer, keeping Luna completely open source and free.
Did I answered your question deep enough? :)
In scientific spaces you have many data sources that all mean completely different things. They are all recorded in different coordinate spaces (mag, distances, polar, etc) and you want to plot many of these things into the same plot and have them go where they were meant to be.
If you could generate 3D plots as well just by flipping a switch that would be a huge plus. The hard part is that we have many modeling softwares that are written in strange ways and in strange formats. One example of a very popular model with a difficult interface is the IRI (http://irimodel.org/). If you could just link a node of "IRI" into "Earth Plot" then that would be awesome.
Keep up the good work!
I'm not talking COPs or Houdini is something bad. It is one of the few applications that I support with whole heart and I love it. In fact Houdini is a very rare example of really well defined visual DSL.
Luna differs in many ways, the most important are that we've got double representation and Luna is a real programming language, while Houdini provides you limited set of building, yet very powerful blocks. I would however love to see Luna used within Houdini as a plugin, I've been already speaking about it with some folks :)
(I'm totally not saying there's no need, but since it's highly technical and I probably would fail at it I'm really curious)
Well it's not really a programming language, but a data processing platform, business people love that -> VCs love that.
You might want to add what you just posted, there's nothing wrong with it, but it would make more people to get it IMHO.
Look, we've been working on Luna for over 2 years now, full time in a team of 7 people. We were often working during weekends or hardly sleeping at nights just to create what we believe in. We were constantly using software build the same way - linux, ghc, atom, etc. Now we want to give it completely free for everyone and we want to survive not because we want to be reach or famous, only because we so deeply believe that Luna really can drastically change something important in the data processing field. We will not survive without people engaged in this project, without people that will make it shine in different domain specific fields. We don't want then to "close" it - it will always be open and free (which is somehow guaranteed by the license too). As a company we need to make money too, but how could we make money not being honest?
We want to build community around good developers only because Luna could be a big development boost for them and additionally, we can together bring it to less technical people and help them too in their daily tasks. If people like what we do, we can then charge for support and additional paid services, developed by us, but I think it is really fair deal and companies should be built this way.
Sorry for a little long answer, but I got that sentence emotional! :)
I'm feeling really inspired, hopeful, and happy when I read comments like these because I consider the lack of vulnerability in the startup world to be as sad as the lack of authenticity. Thank you! I hope you'll keep doing what you're doing.
Are you, by any chance, familiar with nonviolent communication? https://en.wikipedia.org/wiki/Nonviolent_Communication
I was prompted to write my original comment by the simple fact that (usually, in my experience) people stick to the half-truths that are easiest for them to communicate, rather than embracing the hard work of truly conveying their inner meanings (note the plural). To wit: once a website is up and a coherent (albeit incomplete) ’truth’ has been ”put out there”, rarely would I expect the author of that website to turn around and say ”that is the self-serving story we wish to convey to one subset of our potential audience, those who self-select by relying on our website for information”. It's a very intellectually honest approach to admit that the content of the website is not Truth but rather some kind of social mechanism, every. It as ’functional’ as the code itself, and serves the a ’propagandistic’ purpose.
Collectively I summarise all of this as ’candor’. ;)
I love the visual/textual dual language concept - I've been trying to figure out a good solution where both work well and no information is lost from one by editing the other (eg if I create something visually, but edit it textually, does the layout get ruined?) and, at a glance, you seem to have largely solved this or at least managed to get it working well enough. Awesome.
I also like this as a tool for data processing. This kind of platform is something I've been wanting to build (and prototyped once a number of years ago even) for a long time. Couple it with a simple (and familiar) spreadsheet system and your golden (for my purposes - other people may think otherwise).
I haven't looked at Luna in any detail yet, really just glanced at the screenshots so far (I hope to read the material properly tomorrow), but one concern that jumped out at me was that the visual language semantics aren't clear to me. Of course, its probably unreasonable to expect to understand a new language without having read the documentation, so its unlikely to be an issue. I only point it out because I've seen a number of other visual languages claim to be super user friendly (even to non-programmers in many cases), when, IMHO, it really isn't unless you already deeply understand the concepts. I didn't see you making this claim though, so all good :)
Overall, I'm excited for this and wish you the best of luck. Hopefully you will choose me for alpha access so I can play with it ;-) :-P
I'm happy that so many people were thinking to do something going this way - we hear it often. This shows us that this need is widely seen and there is nothing we want more than just collaborate with these people. We will be releasing Luna shortly as Open Source project and will be helping growing community around it. I will be supper happy helping utilizing / extending it for your needs!
As I described before, the timing for this info is not the best, because Luna is not yet available, but it will be really shortly.
Luna introduces some abstraction levels. Some of the leaves (the highest ones) could be usable by less-technical people, but of course only after they get familiar with the concept! :)
Thank you and looking forward to building something interesting together! :)
https://axesslab.com/accessibility-according-to-pwd/
For what it's worth, I've tried the page on 7 screens/devices here, and it was only properly readable on 3 (two of which are very similar models by the same manufacturer). On three of the screens (two really new), it was more trouble than it was worth.
Maybe with documentation? I could at least help with editing / proof reading and the drudge work you guys are too talented to be doing! Your time is much better spent on the core development.
Drop me a line at wojciech at luna-lang.org and we could work something out :) I do not promise we will be able to collaborate before the release (we've got our hands full of work and we're hardly sleeping in nights now), but in the early days / moths after the release the help would be much needed and we would love to build community around people as passionate as you are! Thank you! :)
Let everyone check it out, the passionate ones will engage more through any channels you have (mailing lists, chat, twitter) and be easy to find, IMO.
After reading some of their comments & the copy on their homepage, the creators of Luna sound like they could be fairly mindful people. I'm betting they're seeking people who enshrine certain values to seed their community with & want to privately establish a relationship with them. I find this approach appealing to my introverted side, as a result.
The next mindful step would be to open things up to everyone immediately to allow the ensuing flood of extroverts & introverts alike. This approach seems like it could counter starting off with winner-take-all mechanics in the community's culture.
Then again, all I know about the product is from the first bits of text on their site & this post. I didn't know they weren't simply allowing everyone in until this thread. I could be totally off on how they're rolling. If I am, I'll have to take some time to examine my confirmation biases.
We are not looking for any investments now but we are looking to collaborate with everyone interested in Luna, so that sounds like a "perfect match" for us! :D
Could you (or anyone else) elaborate on MIT vs Apache V2 and patent protection?
I asked before as googling because there are often very well-informed software legal opinions on HN.
[1] https://www.quora.com/Whats-the-different-between-Apache-v2-...
So do you have first-class support for video as well as images? It seems like to have fun with video editing in Luna, you'd need to have built-in support for videos an inputs and outputs, and have a way to play the video output on the screen, and maybe scrub through it, and at a minimum be able to run shaders on the "current frame" and export the resulting video out. The next level after that would be being able to load multiple frames into memory at the same time, and being able to do a combination of "offline" and "online" processing with some CPU involvement (e.g. calculating a motion track and storing it, or applying a filter that can't be expressed as a pure shader program).
I don't know enough about Luna yet to know what code to do these things would "look" like on the visual side, or come to think of it where the computation is being performed (in the browser?). Much more to learn, but the project looks great, a sort of "holy grail" in a way.
You can think of Luna just like about a general purpose programming language. You can define your own types and you can even define how to decode bits from binary files to your structures. The GUI runs in HTML, so you can utilize any html component to display output. Definitely, your use case is doeable, however the amount of libraries currently available is very, very low, so it will need some love :)
Did I answered your questions? :)
Is there a particular timeline on that? I'd love to see how this is implemented (and - importantly - whether or not this can easily be integrated into other software).
Just in case anyone else faces this issue, another possibility is to do WebGL-above-HTML two-layer hybrids, with punchouts to see the synchronized HTML. But perhaps not worth the pain for 2D UIs.
Hmm. Last year I half-started a quick hack of atom.io with CSS3D in Vive VR. Intended for purescript et al. But the display's angular resolution was painfully low for working with text. It looks like Luna might be an interesting alternative for exploring coding in VR.
Also on my infinite todo list are exploring VR direct manipulation of a category-theoretic pushout lattice of <types,ops,laws> theories, and (separately) an interactive editor for string diagrams...
Any thoughts on using Luna as a compiler target?
Because I gave this some thought as well and don't see why not in general, but I don't know how luna works .. or if there are some restrictions I did not encounter yet ..
If you are thinking about visual language you have to think about many constructions that collectively give you user experience, including available basic construction blocks (how looping, branching works etc), structures, lambdas, every language construction, how you give hints to user what is possible and what is wrong and additionally how to do this real 2 way transformation of code and graph.
Luna infers types and displays colors according to them. We use algebraic data types, lazy evaluation, pattern matching and purely functional paradigm which suits graph visualization really well. We fine tune performance by allowing lazy data visualisation and many, many more things. I don't know how we can even visualize standard OO abstractions to be usable and pleasant to work in the visual form. It does NOT mean we did not think about it. We did for a long time.
Sure you can utilize Luna gui to visualize anything, including python code, but it would be insanely hard to deliver similar functionalities to what Luna offers out of the box (which is available by careful design of both representations).
I feel thin answer is very vague, but I hope I put a little light on how complex this task is. Did I answered your question (at last partially)?
I would like to try out the beta once you publish(soon?), to see more what you do and understand better (and see whether my ideas could be compatible, or not)
I don't know if or how luna handles this, but its a concern that I've had trouble with when I was thinking about something similar in the past.
How do you expect the visual syntax to integrate with VCSs? Do you have an algorithm and UI to present visual conflicts? How is the layout after a Git merge?
Cheers
Two questions: How does Luna compare with flow-based programming model implementations such as Apache NiFi and its Expression Language or NoFlo? And do you find Luna appropriate for Internet of Things real-time data processing?
https://www.knime.org/example-workflows
https://github.com/tj/luna
Naming is hard in the global namespace!
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)! :)
> In ancient Roman religion and myth, Janus (; Latin: Iānus, pronounced [ˈjaː.nus]) is the god of beginnings, gates, transitions, time, duality, doorways, passages, and endings. He is usually depicted as having two faces, since he looks to the future and to the past.
https://en.wikipedia.org/wiki/Janus
Here goes some suggestions: https://en.wikipedia.org/wiki/Phoebe_(mythology) https://en.wikipedia.org/wiki/Zana https://en.wikipedia.org/wiki/Notus https://en.wikipedia.org/wiki/Jaci
(That aside, very excited!)
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...).
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.
They wanted simplicity and to control the language and syntax -- not to tie themselves to some Haskell-like environment.
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
Also, "Num in IO", nice. Now we wait for someone to write a "(Num in IO) in IO" action.
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.