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! :)
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 :)
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.
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!
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’. ;)
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! :)
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!
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
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.
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.
> 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...
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?
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.
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 ?
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.
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 :)
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).
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 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!
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 :)
"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 :)
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.
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! :)
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 :)
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.
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.
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.
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.
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!
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.
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 :)
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.
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.
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 :)
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! :)
May want to remove from your "About Us" bio: "hates Java Script" -- can't say I disagree, but you might alienate potential converts -- really should inject as much positivity as possible. Any negative messaging will do nothing but harm.
I prefer to alienate potential converts than convert JavaScripters! Just joking of course. It is hard to hide hate to a non-language treated as a super cool language. But you are right, I've never thought about it this way. I will change it, thank you!
in what way is javascript a non language? i write c, python and javascript- i dont see how one is any more of a language than another? you are baselessly pretentious
the_cat_kittles I did not wanted to hurt your feelings. Of course it is a language. By saying it is not I just wanted to express my strong anty-JS feelings, but they are of course very subjective :)
If I had to guess, I would point out that JavaScript was originally hacked out in 10 days, and features a number of unforgivable flaws, such as a non-transitive equality operator, weird implicit conversions, or just plain trying to make sense of quite obviously nonsensical operations.
To someone used to the mathematical rigour of typed functional languages, this is not even worth looking at. As far as I know, the success of JavaScript had nothing to do with its qualities as a language. It was timing and market forces. It was there, so people used it.
Now don't get me wrong, I don't want to disparage Brendan Eich. I couln't do a tenth of what he did in 10 days. It's just that you get what you pay for. They should have taken the time to fix JavaScript's flaws instead of marketing the hell out of it right away. (Or should have they? Maybe JavaScript would have failed if released a few months later? Damned market. Damned path dependence.)
No one is using the language Eich wrote "in 10 days" anymore, so that's a ridiculous comparison to make. You're dismissing all the effort TC39 has put into improving the language for many years.
The initial design severely limits the improvements you talk about. Sure, you can add better stuff like the === operator, but the crappy old == is still there. However stellar a work TC39 has done, they cannot fix the language without breaking everything.
I don't think anyone ever expected it to become a success, let alone a language used on everything from text editors to terminal emulators to embedded devices.
"To someone used to the mathematical rigour of typed functional languages,
this is patently false, just check out brian lonsdorf
"As far as I know, the success of JavaScript had nothing to do with its qualities as a language. It was timing and market forces. It was there, so people used it."
Man people who would bail out of the entire project just because of one of the members' likes or dislikes on his bio snippet are petty, please don't optimize for those people...
It's not some dramatic "bailing out of an entire project". A more realistic scenario would be:
> "Oh here, that link sounds interesting."
> "Hmm, another visual programing system, I wonder how it works."
> Read for a few minutes, then clicks link to the about page
> Reads part about hating javascript. "Huh.. I wonder why they hate it so much"
> Gets distracted, makes some coffee
> Comes back, and without really thinking about it, closes tab, and goes back to previous task
In this scenario, they might have possibly investigated further and checked the project out. Overall, most people probably won't care, but I would guess the statement is slightly net negative.
Taking a step back, this entire sub-thread is a fairly ridiculous bikeshedding, and I do feel a little bad about participating in it, heh.
JS devs encounter a lot of low effort BS/FUD from JS-haters who are clearly talking out of their ass or obviously haven't advanced their understanding of JS since 2005. If you're making something awesome, somebody's going to genuinely be interested if it's genuinely awesome regardless of their "fake language" background. So yeah, if I see "hates <literally any language>" in a profile, I'd probably assume the developer is pretentiously arrogant or will have the propensity to build a toxic community that focuses on bashing alternatives instead of building itself up.
This was a super-valid position until Sept. 14, 2015, when Node.js and io.js combined to establish a stable runtime. From that day forward, JS/ES have been fast to change and stable.
I don't care what they done in terms of stable runtime. I mean, I care, but not in the context of the language itself. Language is all - combined! The runtime, syntax, libs, everything. I call it "experience" or "feeling". I like the idea to treat JS as web assembler, but as a language, JS is just a garbage. It will be garbage until you will be able to write code, that seems completely valid unless you are super JS geek and know that it will break. I will not reconsider my hate until you will be able to write `['10','10','10','10','10'].map(parseInt)` and get `[10, NaN, 2, 3, 4]` as a result (just a small example of many). Sorry if that puts you off.
The `map(parseInt)` example is an obscure strawman that exists solely due to historical purposes; it's very difficult to change this sort of thing in a language because it would involve one of two things:
1. Change the API of `parseInt`, break everything
2. Change the API of `Array::map`, break everything
If you want JS devs to respect your voice you may want to attack the more fundamental problems with the language, like its lack of type-safety, rather than the remnants of its "upbringing".
it does, because you are clearly just a snob. its so obvious that people are just looking for reasons to hate javascript when they post shit like your dumb example. though i concede that is a pretty hilarious "wat". virtually all the dumb "gotchas" never show up, and the real gotchas are learned early, just like other languages. you are like a classical musician who thinks every other kind of music is not real and easy. the same damn attitude. go away
Sorry dude, I'm going to have to step in; you're being too strong in your counter attitude. I've been writing and teaching JavaScript professionally for many years, and while I don't hate the language, I don't blame those who do. After learning and using a statically typed language, it becomes absurd how much effort you have to put in to debug a JavaScript type error – a problem that is amplified by the language design.
What happens when you add 1 + undefined? Other dynamic languages make the sane choice of throwing an error immediately. JavaScript, however, silently gives you back NaN and continues chugging along. By the time a "real" error happens, you're stack traces away from the cause.
What happens when you call a function f with one argument when it expects two? Other languages would throw immediately. Instead, JavaScript silently sweeps in an undefined and continues chugging along. Combine that with the other flaw I mentioned, and your runtime error will, again, be distant from the true cause.
There's a reason TypeScript is getting insanely popular. It's the only way to code large JavaScript projects and stay sane.
The problem I have with static typing (as widely implemented) is it solves little problems at the cost of arbitrary inflexibility which ends up rippling through a code base.
And the little problems are better solved in other ways. E.g., unit tests and the like catch type errors on the way to validating that your code actually does what you think it should do.
Static typing also isn't useful when dealing with data that moves through distributed systems. You know, like pretty much all the data. The static types you had at compile time are fundamentally not related to the data you are processing at run time and static types don't equip you to deal with that very well. Systems map "wild" incoming data to the internal static types but the static type environments strongly encourage this to happen early, which is often not the right place.
> The problem I have with static typing (as widely implemented)
Mainstream type systems are best ignored. If it doesn't have sum types, it's not a good type system. If it doesn't have generics, it's not a good type system.
More flexible static type systems can help, but they don't address the fundamental problem that they are trying to make a strong statement at development time about something that isn't known until runtime.
This pushes dealing with the problem (of what if something isn't the expected type/is malformed/is missing/is incomplete) to the wrong place, causing unnecessary complexity, dependencies and bugs.
Give me an example of a correct program you actually want to write, that a decent static type system. I do have examples of correct programs that almost no static type checker will accept, but I don't want to write those programs. For instance:
if true then 1 else "one"
This is an expression of type int, that yields the value 1. But I don't want to write such crap, because of (i) dead code, and (ii) mismatched types between the the branches (one is an int, the other is a string).
I don't often feel constrained by static typing but perhaps we are just working on different kinds of problems.
As for distributed systems, it's true that static typing doesn't solve that on it's own, but combined with something like protobuf, it should right? Admittedly I've only recently learned of protobufs so feel free to correct me.
I hadn't heard of protobufs before now. But if I understand it correctly, I don't think it addresses (what I think is) the fundamental problem with static typing in a distributed system.
It's that the your static types that exist at development/compile time aren't really strongly related to the runtime data. Meaning, the strong guarantees that static types make aren't actually true.
Systems deal with this by recreating the relationship: they convert incoming data to instances of the static types. But you have to note, this code exists to satisfy the static type system. If you didn't have a static type system, you don't need that code: you don't have to write it, test it, maintain it, etc.
protobufs looks like one way to recreate the relationship between your runtime data and the static types. It looks pretty nice, but it has its own complexities -- another language to learn on top of anything else you're doing, another tool to install and learn with its own quirks (I notice the generated C++ code files have a .cc extension), a code generation step to integrate into your build, new versions of protobuf to be integrated to get new features). Stuff you don't need to deal with if you don't have a static type system.
But it's not just that its wasteful. It also encourages you to deal with changes to your data model early, in a generic way (because your inflexible static type system pervades the entire code base... you can't do anything with the data until you wrestle it into an instance of a static type). But that's often not the best place to do it because at that point, the system doesn't know what will be done with the data.
Not that static types don't have their place. They certainly have their uses, but I think it's in small, inner-boxes, not throughout a codebase. E.g., let's make it something you have to opt-in to on a case-by-case basis, not a pervasive assumed default. Sure, provide a mechanism for type hinting to drive helpful static code analysis, like auto-complete and refactoring tools.
Perhaps provide some kind of flexible dynamic-type/static-type bridge that helps you solve dynamic-type/static-type issues rather than encourage them. E.g., something that at run time keeps track of the difference between runtime data and the static type it is supposed to be according to the type hinting.
you are entitled to your opinion, and i appreciate that you offer it. and those are legitimate gripes. ive written it professionally for many years as well. there are alot of nice things about javascript as well, so in general i like the language. alot of what i read in the initial answer is a guy who wants to show he is a member of the cool kids club by hating on javascript. its so lame.
Try to be more charitable by seeing it from their point of view. Imagine being used to a language that helps you be rapidly productive and shields you from a huge catalog of mistakes. But one day you're forced to use JavaScript, and suddenly you've got nothing. It'd be like driving in a doorless jeep with no seatbelts on a high rise highway with no guard rails. Sure you can do what you want, and even in some nice, clever ways. But there are so many ways to hurt yourself, and no natural protections to prevent it.
To put it another way, it's like throwing a frontend developer into the world of C. Suddenly you have to be aware of and correctly manage your memory explicitly, whereas before you were safely protected from having to think about it.
Lastly, not everyone can voice their opinions so well. Communication is a difficult thing, and understanding what you're trying to communicate more so. If someone says they hate something, it's not always baseless. Instead of jumping to name-calling, have more patience in trying to understand why.
this is a good characterization of what causes people confusion, and i think the parallel with people going to c from js is totally right. i experienced that myself. its a great way to put it and i will probably use it, thanks!
the second point about being more understanding surely applies more to the person proudly hating a language with no constructive support about why, and little evidence of an effort to overcome the language's obstacles. sure, i dont know everything about this person, but i take the comment at face value, which seems to be the norm. maybe calling them out on it isnt helpful? i dont know, but it didn't seem that bad.
If the hate were towards a person, I would completely agree with you. But OP is only hating JavaScript-the-tool, so I have no contempt towards his opinion.
In contrast, if OP were hating on JavaScript programmers, then your indignation would be completely justified. But he's not, and I admit to holding a similar position: I hate C++ and prefer to never lay eyes on it again, but I have nothing against C++ programmers :) The difference between C++ and JS is C++ is less forced upon someone's career as the only language to work with.
thats a good distinction, and i suppose its defensible. but imagine you are a trumpet player, and a pianist walks by and says "i hate that non-instrument trumpet" unprovoked. no one is wrong to hate the trumpet. but saying it to a trumpet player, and then saying they aren't even a musician (implied by "non-language"), is going to catch heat.
and its undeniably true that javascript has got loads of warts. i mean, look no further than "javascript: the good parts" as perhaps the most recommended book. (i guess you already know this, but for the maybe 1 other person reading this...) but despite that, i enjoy the hell out of writing good js, and love that people can use what you make by going to web page. and w/r/t the warts, i feel that if they were corrected, my js life woulnd't change much at all. so when people point to the warts as evidence that its a bad language, all i can say is that while they are obviously bad, they dont end up mattering to me. thats clearly not true of everyone, but id bet its true alot. because of this, i find it pretty easy to spot people who are excited to hate js because they are pretty sure its a safe thing to hate and it will make them look in the know. i mean, i was guilty of this when i was younger with mysql and php.
and yes, people being "forced" to use js is surely contributing to the hate, probably the same way people hate having to use css. they look at them as afterthoughts, but its funny because in a lot of cases, its like the main thing that needs work. i just wonder why people cling to the idea that "real programming" has a certain look, when being good at js and css is super helpful and important to good web projects.
i suppose we are arguing for the same thing- basically open-mindedness and willingness to learn.
Two days after you two posted this thread of comments, and I must thank you for it.
The analogy of musical instruments may be appropriate here; I feel that my ability or failure to be productive with a particular set of tools to be an aspect of my identity.
Set me to debugging a C++ or Java class library and I can get to work, but these may not be the tools I would prefer to start with.
Am I a bad programmer? Hmm. Identity can be a fragile thing.
> its so obvious that people are just looking for reasons to hate javascript
Why would anyone have the motivation to do that? Either it has given them reasons to dislike it, or it hasn't. Why do you think anyone is predisposed to looking for those reasons?
Even worse though,is to have your personal identity tied up in the language you work in. If you are actually Brendan Eich, then I get you taking it personally, otherwise, who cares?
the_cat_kittles I think you don't get the point of my answer or simply my answer was confusing, sorry for that. I did not wanted to start a big discussion here and just throw a controversial, stupid example. But it very clearly shows my main point. The point is that it is easily to write a code in Javascript that looks ok, but is not. The lack of good type system, legacy of how it was implemented on the beginning and everything connected to lack of general safety leads to this conclusion.
I disliked it myself up until ES6 when it started to be "enjoyable" or..should I say less annoying. I program in 6 languages (it may not be much but enough to draw a conclusion from a sample) and I can't say I have one without it's list of wtf's.
By placing big keywords in your bio like "Serial enterpreneur, haskeller, programming languages design freak, former senior R&D technical director in the biggest film studios in Europe" + "hates java script" and keeping your flag up here makes it look very unprofessional. Of course, who are we to judge if not...your target audience for a "functional programming language", visual or not.
I remember when RoR came out and some [1] "cool dudes" decided to mock everything else on the planet. RoR vs php, RoR vs this and that. It made me feel sick even though RoR was a big step up from everything else back then. It took me 2 - 3 years to even consider it because of that.
So in the past I have used two self-proclaimed "visual programming languages", Blueprints[1] and Max[2] and in both cases I found that it is actually harder to be productive while dealing with UI elements than it is to simply write code (as long as you have at least some rudimentary form of autocomplete I guess).
However I have to say that, based on the little I've seen, Luna's UI seems to be actually developer-friendly i.e. the UI elements go hand-in-hand with code rather than getting in the way, I think it's brilliant, sort of Jupyter Notebooks on steroids.
Part of the difficulty, I think, may be the mismatch between how Luna represents a piece of code and how I visualize it in my head. Is Luna going to draw a line between some related things when I would rather see them, say, in the same color? Will it show an arrow pointing from a data source to its destination, when I would rather see the destination pointing to it's source?
My worry is that Luna's visual model of the code will not match my mental model, and the impedance will be too much to overcome.
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'd productize this more as the next level of "spreadsheet" than of "programming language". These kinds of visual programming things always seem to come out with lots of fanfare but then never get used for real work. The spreadsheet, however, is by nature reactive, relational, visual, impromptu, yada yada. But even though spreadsheet tech has added lots of functionality over the years, it's still essentially based on an old paper grid.
I could see a product like this challenging that old basis with something more modern. But it still has to do all the stuff regular spreadsheets can do too. And ensuring that it can, and in an intuitive fashion, should probably be the first priority.
Or start by doing enough of the stuff Excel can't do easily or at all and then grow into what you've described. For example:
* Plot 3d (x,y,z) and 4d (x,y,z,time) graphs
* Hook into data streams
* Multi-user editing
* JSON-like data structures beyond 2d row-column data structures
* Improved output formatting
I'd be happy enough with floating sheets. To resolve those common things where you've got two different sections, like an analysis with a summary section below it. It's annoying because e.g. changing the column width on the top part also changes the column width on the independent thing below it. A tool that lets me put multiple independent sheets on the same page would be great. If the tool can be programmed to run image processing algorithms on the same page, that's fine too.
I'd view "IO" as almost equivalent to "Macro" in that instance. Though not quite. I'd like to be able to have e.g. $A$1 be a filename and $A$2 be the image in file $A$1, and that to be understood as a "pure" transform, even though under the hood it's got to open the file. So "application-scope purity" rather than process-scope purity.
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 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.
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...)
Given the name, I would expect this to be related to or built on Lua. That doesn't appear to be the case. Is this echo accidental?
"Traditional software development is broken by design" is a pretty strong claim, but the only support is a bunch of over-broad anecdotal claims about what "always" happens. That's a bit offputting for some of us.
The phrase "Category Oriented Programming" is used like it's common vernacular, which I don't think it is. Is it related to Category Theory? The text seems to imply that the idea of mixing functional programming with message-sending objects is novel. It really isn't.
"Unmatched performance and safety". Yeah. You want to be careful about that claim. Going to need to see the independent evaluation results.
That said, for those who value diagrams highly, this looks interesting. I wonder at what level of complexity the abstractions start to leak.
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.
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.
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.
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.
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.
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 ;)
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.
One of the examples I saw you guys give on YouTube is how complex things are becoming, and you talked about the LOC of a modern car and this is a reason we need visual programming. On your website you also discuss the limitations of UML.
To design complex systems like a car, you really need to know not just the functionality and the type of information, but also the structure of the system. How do all of those systems on the car physically connect to result in the behavior.
It seems like your approach would be really powerful for data processing, since in that case I don't think the structure matters much. Have you thought about how this could be applied to a complex system where structure is extremely important?
How do you envision version control/code reviews with Luna projects? Can diffs be explored at visual level or only source code level? If one developer moves nodes around without altering any logic are such changes tracked in the code repository?
For starters we've made sure to make git diffs as readable as possible. The visual data is kept at the end of text file (hidden when using our editor), usually in a single line. So if you just move nodes around, one line gets changed and it is clear what to ignore when scanning the diff, while making sure to retain the changes in the repository.
For later stages, we envision much deeper integrated version control, including viewing git diffs in the visual editor.
This sounds bad. Any info in the text related to the visual representation will be unreadable i guess. Hiding such for diff review is helpful but not enough. Because in merge conflict resolution one may not have the luxury to neglect it.
This idea will eventually work and be huge I think (I know visual programming languages already exist but a commonly used one to emerge). As someone who believes in metaprogramming and flexibility though I'm hoping for something dynamic, not a heavy mandatory type system that compiles to Haskell.
We believe in something very similar, there are some differences though. Luna type system is not dynamic BUT it is also not mandatory. Our whole standard library does NOT mention a single type - all are inferred by type system and you can, if you want, state them explicitly. To sum this up, we want Luna to be simple to use, intuitive, but have a strongly typed backbone with power similar to Haskell or Idris IF needed. Does it makes sense to you? :)
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.
Looks like a lazy functional Python ) Very nice aesthetics of presentation.
There are a few things I am concerned, if you don't mind: I think that actually visualizing lazy computation can be quite a challenge, because of its on-demand nature. One might say that a lazily defined expression is computed (and should be visualized) where it's used, rather than where it's defined. There is a lot of substitutions going on under the hood, and computation is not as clearly localized as it would be in eager evaluation. Also, the tight binding between the code and the visualizations may limit your ability to optimize code for efficiency.
The True / False switch looks cool, but it feels like you are cheating here a little bit by using a boolean literal. Would it look equally nice if it's a function call or some complex expression that is possibly not known yet (as in a function definition)? I have a feeling that at the end of the day Luna may require a very complex visual language that is not easier than the textual alternatives.
But this is more like arbitrary concerns that will be hopefully clarified once you release the whole system. Thank you for your work.
Thumbs up for exploring these new alternative for writing code. I think, it may help us write better and safer programs in the future.
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.)
What is confusing to me is if the visualization actually running the code or is just static analysis of the code?
The reason I ask is if its running then what you have built is a language with an absolutely awesome visual REPL. If it is please say its a language with awesome visual REPL! A potential Excel for programmers killer. There are languages that tried to do this (Squeak, and Racket come to mind) but they were generally academic and more often for students/young adults (and not for businesses).
However you say whiteboard through out your marketing which makes me think brainstorming tools ala evernote, orgmode etc. I realize for VC they might prefer whiteboard.
Whiteboard to me is sharing and not really a tool. It means I have to register and create a profile when all I really want is a language with a powerful visual REPL. (again just my point of view on marketing).
Why don't we have both? And then some more.
It is an awesome REPL with a bit of Excel feel. Runs the code whenever you change it and displays the results in real-time. It is also great for interactive data sources (like web services), where you get the results as soon as they appear upstream.
The whiteboard part is super important too. Visual representation is great for design and brainstorming. Even more so, when it provides runtime feedback about your designs. And it gets even more important with collaboration. So at this point we've got a collaborative whiteboard that actually runs the computations.
There is, however, one more part to the story. Neither whiteboard, nor a REPL are well suited for implementing the final, production software. We aim to blur the lines between the design and implementation phases, allowing to deploy whatever has just been "sketched".
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!
I'm glad you like it! :)
I'm very curious about your feedback after using Luna, don't forget to keep in touch with us after the release!
We do not integrate with any language, because the visual representation is just a different syntax for Luna. In fact we keep both syntaxes - textual and visual with the same powers, so you can switch between them, but they are just syntaxes for the same language.
Integrating with Julia (or other lang) would be hard because the language has to be designed in such way that it will allow for such dual representation. We put an enormous effort to design Luna this way. However it will be possible to integrate Julia in such way, that some of the nodes would be written in Julia and then even allow to in-place expanding nodes to small text-editors to preview the code in place. It will however not be possible to translate Julias code to graph or vice versa.
Awesome, we need more visual programming languages coming out now. it's so impossible to convince a programmer who never experienced visual programming how useful/practical it can be.
I understand you are from a video processing background where visual programming is widely employed.. We are also building a visual programming platform, inspired from enterprise tools. Really interesting to see this domain evolve.
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.
data Eq : {a : Type} -> a -> a -> Type where
Refl : Eq x x
sym : {x : a} -> {y : a} -> Eq x y -> Eq y x
sym Refl = Refl
replace : {a : Type} -> {x : a} -> {y : a} -> {f : a -> Type} -> Eq x y -> f x -> f y
replace Refl p = p
Isn't it similar to what Eve tries to achieve? Well, what I like in overal, is an attitude and courage to introduce new technologies! I come from the Red language camp, which if I am not mistaken, is also being funded. So - good luck, guys :-)
Yeah, we have a lot of the same views about programming, but our focus isn't on data science. We can definitely agree that the practice of programming in the future won't look like it does today.
I think it's interesting that if you look at this and at Eve, you'll see how both are trying to improve programming and end up at quite different approaches. No size fits all.
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.)
I truly hope you will succeed in your mission. It looks like it could solve so many problems that I've come across as a result of confusion and miscommunication when people with a common understanding step away from the whiteboard and start coding. It can be so hard to align the implementation with the visual abstractions we so desperately need to communicate as humans.
I'm struck by the similarity to grasshopper. This seems to share many of the same features such as visual profiling, visual / textual representation, live previews etc... Has it inspired the design at all?
I would like to subscribe to the news, but am afraid to use news-letter services. I suspect they sell the addresses to spammers. Would you please instead set up an atom feed or a primitive blog on Blogger?
What is it compiled to? Does it target JVM, CLR, native code (if so what platforms?)
What is it compiled with? LLVM ? GCC ? Custom compiler?
What is the standard library like?
It targets few backends. Currently it runs on our VM, but we are working on targetting GHC's Haskell Core (which then compiles to LLVM IR). Luna's compiler is of course a custom compiler written in Haskell. Standard library looks cool!
What does that even mean? No offense, but like I haven't seen any demos on your website and you are describing the std lib as cool? Not exactly confidence aspiring.
It looks interesting for sure and looks really fun to mess around with (frankly has a hobbyist high school programmer who likes systems programming, I don't see a whole lot of use for me :))
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.
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 :)
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!
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 :)
im pretty you just got called out and are walking it back now. thats fine. there are lots of ways of handling typing in javascript. i could be reading more into you answers than is there, but your apparent proud ignorance is, i think, fairly deserving of a little bit of public shaming.
you deserve more public shaming than him. Sure he hates javascript and has valid reasons to do so. You, on the other hand are so insecure (probably because you've spent years using this language), that you have to make personal attacks.
well i can tell this is turning into the bad kind of internet commenting. you are calling me insecure- thats a personal attack. is it wrong to call someone a snob for being snobby?
ok i dont think snob has anything to do with upbringing, but yes- i dont really care for the tons of articles about new dumb frameworks etc, that would only be more annoying if i didnt use js. you are also allowed hate js. just kind of weird to parade around the internet proudly proclaiming it (not you, op)
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! :)
Cheers, Wojciech
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...
Keep up the good work!
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.
Can you embed this in a game engine?
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.
thats awesome !
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 :)
How did you convince VC-s, that there's need for a new programming language?
(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)
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.
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!
Thanks for the response, it makes more sense now. However your site does say it's "just" a programming language with huge font size :)
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.
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! :)
I applaud your candor.
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.
Are you, by any chance, familiar with nonviolent communication? https://en.wikipedia.org/wiki/Nonviolent_Communication
That's a heartwarming response, truly.
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 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! :)
Haha, I was thinking the same.
Well it's not really a programming language, but a data processing platform, business people love that -> VCs love that.
Lets underline one important thing. Luna really is nut just a language, it really is a data processing / visualization platform! :D
Congrats on your round. I'd love to evaluate this for several data initiatives that I'm leading. Signing up.
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!
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
Sent! Please check your spam folder ;) Also copied to the address from your website, or are both correct?
I've got it and just replied. See you tomorrow! :)
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.
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.
> 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...
Any thoughts on using Luna as a compiler target?
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?
Cheers
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.
Ah - great to hear you're open sourcing it because I was a bit put off by 'sign up to be selected' form, even though the product is fascinating.
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! :)
But without giving access, how can you expect passion? :-)
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.
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 ?
Gladly! Consider the line dropped.
To be clear, I mean opening things up to everyone would be the next step after finding the community's seeds.
I really like how the Luna site looks. As someone who knows nothing about web front-end, how was it made? Custom-built? Template?
Our programmer designed it and we've just build it using some standard bootstrap. It might seem like a joke, but it's currently not :D
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 recently viewed a very short and practical page on accessibility that you might be interested in. It had a contrast tip that matches parent's claim.
https://axesslab.com/accessibility-according-to-pwd/
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.
Any chance you could link the bootstrap?
Ahh, I actually really like it alot!
http://hyperboleandahalf.blogspot.ie/2010/04/alot-is-better-...
thanks alot! :D
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 :)
One click deployment example to AWS Lambda or Google Cloud Functions could be killer scenario!
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).
1 click deployment to something like golem.network would be even cooler
Interesting idea! Are you thinking about any specific applications you'd like to deploy there? I'd love to learn more
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 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!
Bob I'm happy you like it! We'd love to hear your feedback after your tests :)
Great news! What are the hold-ups in going open source? How soon is "just before"?
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 :)
"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 :)
How does this compare to NoFlo?
Nice work, may want to update the copyright on the website - says 2016 still
Thanks for catching it! We'l be releasing a new website shortly so it will be fixed soon! :)
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.
Very cool project! What license are you planning on using?
We are considering MIT or Apache v2, what do you recommend?
apache2 because of the patent protections.
Straight question for the uninformed (me):
Could you (or anyone else) elaborate on MIT vs Apache V2 and patent protection?
OK - found this on Quora [1] that gave me some idea.
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-...
I'm interested in seeing how an open source programming language/platform with a clean GUI will evolve. Curious to see this in a year!
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! :)
Is there a way for a beginning developer to help?
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! :)
Can I implement pixel-level video effects with Luna (e.g. warping, time map, segmentation, keying, etc.)?
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) :)
Thanks for the reply!
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 :)
Did I answered your questions? :)
Not entirely, but I think that would be hard to do in a comment box! Thank you!
It's built on top of GHC... you could try writing your filters in haskell; I imagine it would be similar.
Sounds pretty cool. Looking forward to it. Don't rewrite the graphical interface again, though ;-)
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.
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)?
Yes, thanks, I think you did, what you can ;)
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.
Awesome! That's great to hear.
What is your business model?
First of all, we originate from Open Source community and we believe in it so strong, that we set it as a backbone for our business. We also believe in Open Adoption Software model: https://www.slideshare.net/AccelPartners/the-rise-of-open-ad... .
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? :)
Thank you for the link about the Open Adoption Software model. It was a nice read!
I'm glad you like it! :)
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.
This is on our roadmap after the release, but we kindly invite you to help us design and do it the best possible way! :)
Is this intended for a general purpose programming?
Yes, it's one of our core goals! :)
inspirations please ? brett victor ? dataflow / node based modeling ? others ?
Houdini, Haskell, Python, Ruby, MaxMSP. I think these were the strongest influencers.
I can finally say Houdini is a PL influence. sidefx must be pleased :)
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!
Thanks for chiming in! Hopefully it works out for you guys! :)
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.
For completeness, the previous threads: https://hn.algolia.com/?query=Luna%20lang&sort=byPopularity&...
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 :)
Fantastic! Will do. Hopping on a plane now but will be in touch.
Have a safe and pleasant flight!
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.
LabVIEW
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.
And much more! :)
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 :)
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! :)
Thanks that sounds great! I just signed up for the mailing list, but feel free to reach out to me at any time! (my username @ gmail.com)
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! :)
May want to remove from your "About Us" bio: "hates Java Script" -- can't say I disagree, but you might alienate potential converts -- really should inject as much positivity as possible. Any negative messaging will do nothing but harm.
I prefer to alienate potential converts than convert JavaScripters! Just joking of course. It is hard to hide hate to a non-language treated as a super cool language. But you are right, I've never thought about it this way. I will change it, thank you!
in what way is javascript a non language? i write c, python and javascript- i dont see how one is any more of a language than another? you are baselessly pretentious
the_cat_kittles I did not wanted to hurt your feelings. Of course it is a language. By saying it is not I just wanted to express my strong anty-JS feelings, but they are of course very subjective :)
cool, i didnt want to hurt your feelings, just point out that you are a baseless snob
If I had to guess, I would point out that JavaScript was originally hacked out in 10 days, and features a number of unforgivable flaws, such as a non-transitive equality operator, weird implicit conversions, or just plain trying to make sense of quite obviously nonsensical operations.
To someone used to the mathematical rigour of typed functional languages, this is not even worth looking at. As far as I know, the success of JavaScript had nothing to do with its qualities as a language. It was timing and market forces. It was there, so people used it.
Now don't get me wrong, I don't want to disparage Brendan Eich. I couln't do a tenth of what he did in 10 days. It's just that you get what you pay for. They should have taken the time to fix JavaScript's flaws instead of marketing the hell out of it right away. (Or should have they? Maybe JavaScript would have failed if released a few months later? Damned market. Damned path dependence.)
No one is using the language Eich wrote "in 10 days" anymore, so that's a ridiculous comparison to make. You're dismissing all the effort TC39 has put into improving the language for many years.
The initial design severely limits the improvements you talk about. Sure, you can add better stuff like the === operator, but the crappy old == is still there. However stellar a work TC39 has done, they cannot fix the language without breaking everything.
People are, how many times does a Javascript coder type `===` in one day?
I don't think anyone ever expected it to become a success, let alone a language used on everything from text editors to terminal emulators to embedded devices.
"To someone used to the mathematical rigour of typed functional languages,
this is patently false, just check out brian lonsdorf
"As far as I know, the success of JavaScript had nothing to do with its qualities as a language. It was timing and market forces. It was there, so people used it."
i would wager this is largely true
Have you tried ECMAScript 6+? You could reconsider your hate ;)
Shhh you may fool the guy and make him look silly, that's not nice! ;)
Well, it was pretty good ad for me, so maybe reconsider.
I will reconsider hiding my real feelings. I really feel I should not hide them ;)
Man people who would bail out of the entire project just because of one of the members' likes or dislikes on his bio snippet are petty, please don't optimize for those people...
It's not some dramatic "bailing out of an entire project". A more realistic scenario would be:
> "Oh here, that link sounds interesting."
> "Hmm, another visual programing system, I wonder how it works."
> Read for a few minutes, then clicks link to the about page
> Reads part about hating javascript. "Huh.. I wonder why they hate it so much"
> Gets distracted, makes some coffee
> Comes back, and without really thinking about it, closes tab, and goes back to previous task
In this scenario, they might have possibly investigated further and checked the project out. Overall, most people probably won't care, but I would guess the statement is slightly net negative.
Taking a step back, this entire sub-thread is a fairly ridiculous bikeshedding, and I do feel a little bad about participating in it, heh.
JS devs encounter a lot of low effort BS/FUD from JS-haters who are clearly talking out of their ass or obviously haven't advanced their understanding of JS since 2005. If you're making something awesome, somebody's going to genuinely be interested if it's genuinely awesome regardless of their "fake language" background. So yeah, if I see "hates <literally any language>" in a profile, I'd probably assume the developer is pretentiously arrogant or will have the propensity to build a toxic community that focuses on bashing alternatives instead of building itself up.
Perhaps there's a way to present yourself authentically while still holding the door open for the Javascripters?
Would "Loves dogs, hates Java Script, willing to meet you in the middle if you disagree on either" be accurate?
This was a super-valid position until Sept. 14, 2015, when Node.js and io.js combined to establish a stable runtime. From that day forward, JS/ES have been fast to change and stable.
I don't care what they done in terms of stable runtime. I mean, I care, but not in the context of the language itself. Language is all - combined! The runtime, syntax, libs, everything. I call it "experience" or "feeling". I like the idea to treat JS as web assembler, but as a language, JS is just a garbage. It will be garbage until you will be able to write code, that seems completely valid unless you are super JS geek and know that it will break. I will not reconsider my hate until you will be able to write `['10','10','10','10','10'].map(parseInt)` and get `[10, NaN, 2, 3, 4]` as a result (just a small example of many). Sorry if that puts you off.
Pet-peeve from a Javascript Apologist:
The `map(parseInt)` example is an obscure strawman that exists solely due to historical purposes; it's very difficult to change this sort of thing in a language because it would involve one of two things:
1. Change the API of `parseInt`, break everything
2. Change the API of `Array::map`, break everything
If you want JS devs to respect your voice you may want to attack the more fundamental problems with the language, like its lack of type-safety, rather than the remnants of its "upbringing".
> @horse_js: JavaScript. It isn’t meant to be hand-written;
https://twitter.com/horse_js/status/872243719889616897
:p
it does, because you are clearly just a snob. its so obvious that people are just looking for reasons to hate javascript when they post shit like your dumb example. though i concede that is a pretty hilarious "wat". virtually all the dumb "gotchas" never show up, and the real gotchas are learned early, just like other languages. you are like a classical musician who thinks every other kind of music is not real and easy. the same damn attitude. go away
No matter what you're replying to, uncivil, name-calling dismissals and personal attacks are not OK on Hacker News. Please stop.
https://news.ycombinator.com/newsguidelines.html
Sorry dude, I'm going to have to step in; you're being too strong in your counter attitude. I've been writing and teaching JavaScript professionally for many years, and while I don't hate the language, I don't blame those who do. After learning and using a statically typed language, it becomes absurd how much effort you have to put in to debug a JavaScript type error – a problem that is amplified by the language design.
What happens when you add 1 + undefined? Other dynamic languages make the sane choice of throwing an error immediately. JavaScript, however, silently gives you back NaN and continues chugging along. By the time a "real" error happens, you're stack traces away from the cause.
What happens when you call a function f with one argument when it expects two? Other languages would throw immediately. Instead, JavaScript silently sweeps in an undefined and continues chugging along. Combine that with the other flaw I mentioned, and your runtime error will, again, be distant from the true cause.
There's a reason TypeScript is getting insanely popular. It's the only way to code large JavaScript projects and stay sane.
(just going' down this rabbit hole with you all)
The problem I have with static typing (as widely implemented) is it solves little problems at the cost of arbitrary inflexibility which ends up rippling through a code base.
And the little problems are better solved in other ways. E.g., unit tests and the like catch type errors on the way to validating that your code actually does what you think it should do.
Static typing also isn't useful when dealing with data that moves through distributed systems. You know, like pretty much all the data. The static types you had at compile time are fundamentally not related to the data you are processing at run time and static types don't equip you to deal with that very well. Systems map "wild" incoming data to the internal static types but the static type environments strongly encourage this to happen early, which is often not the right place.
> The problem I have with static typing (as widely implemented)
Mainstream type systems are best ignored. If it doesn't have sum types, it's not a good type system. If it doesn't have generics, it's not a good type system.
More flexible static type systems can help, but they don't address the fundamental problem that they are trying to make a strong statement at development time about something that isn't known until runtime.
This pushes dealing with the problem (of what if something isn't the expected type/is malformed/is missing/is incomplete) to the wrong place, causing unnecessary complexity, dependencies and bugs.
Give me an example of a correct program you actually want to write, that a decent static type system. I do have examples of correct programs that almost no static type checker will accept, but I don't want to write those programs. For instance:
This is an expression of type int, that yields the value 1. But I don't want to write such crap, because of (i) dead code, and (ii) mismatched types between the the branches (one is an int, the other is a string).I don't often feel constrained by static typing but perhaps we are just working on different kinds of problems.
As for distributed systems, it's true that static typing doesn't solve that on it's own, but combined with something like protobuf, it should right? Admittedly I've only recently learned of protobufs so feel free to correct me.
I hadn't heard of protobufs before now. But if I understand it correctly, I don't think it addresses (what I think is) the fundamental problem with static typing in a distributed system.
It's that the your static types that exist at development/compile time aren't really strongly related to the runtime data. Meaning, the strong guarantees that static types make aren't actually true.
Systems deal with this by recreating the relationship: they convert incoming data to instances of the static types. But you have to note, this code exists to satisfy the static type system. If you didn't have a static type system, you don't need that code: you don't have to write it, test it, maintain it, etc.
protobufs looks like one way to recreate the relationship between your runtime data and the static types. It looks pretty nice, but it has its own complexities -- another language to learn on top of anything else you're doing, another tool to install and learn with its own quirks (I notice the generated C++ code files have a .cc extension), a code generation step to integrate into your build, new versions of protobuf to be integrated to get new features). Stuff you don't need to deal with if you don't have a static type system.
But it's not just that its wasteful. It also encourages you to deal with changes to your data model early, in a generic way (because your inflexible static type system pervades the entire code base... you can't do anything with the data until you wrestle it into an instance of a static type). But that's often not the best place to do it because at that point, the system doesn't know what will be done with the data.
Not that static types don't have their place. They certainly have their uses, but I think it's in small, inner-boxes, not throughout a codebase. E.g., let's make it something you have to opt-in to on a case-by-case basis, not a pervasive assumed default. Sure, provide a mechanism for type hinting to drive helpful static code analysis, like auto-complete and refactoring tools.
Perhaps provide some kind of flexible dynamic-type/static-type bridge that helps you solve dynamic-type/static-type issues rather than encourage them. E.g., something that at run time keeps track of the difference between runtime data and the static type it is supposed to be according to the type hinting.
you are entitled to your opinion, and i appreciate that you offer it. and those are legitimate gripes. ive written it professionally for many years as well. there are alot of nice things about javascript as well, so in general i like the language. alot of what i read in the initial answer is a guy who wants to show he is a member of the cool kids club by hating on javascript. its so lame.
Try to be more charitable by seeing it from their point of view. Imagine being used to a language that helps you be rapidly productive and shields you from a huge catalog of mistakes. But one day you're forced to use JavaScript, and suddenly you've got nothing. It'd be like driving in a doorless jeep with no seatbelts on a high rise highway with no guard rails. Sure you can do what you want, and even in some nice, clever ways. But there are so many ways to hurt yourself, and no natural protections to prevent it.
To put it another way, it's like throwing a frontend developer into the world of C. Suddenly you have to be aware of and correctly manage your memory explicitly, whereas before you were safely protected from having to think about it.
Lastly, not everyone can voice their opinions so well. Communication is a difficult thing, and understanding what you're trying to communicate more so. If someone says they hate something, it's not always baseless. Instead of jumping to name-calling, have more patience in trying to understand why.
this is a good characterization of what causes people confusion, and i think the parallel with people going to c from js is totally right. i experienced that myself. its a great way to put it and i will probably use it, thanks!
the second point about being more understanding surely applies more to the person proudly hating a language with no constructive support about why, and little evidence of an effort to overcome the language's obstacles. sure, i dont know everything about this person, but i take the comment at face value, which seems to be the norm. maybe calling them out on it isnt helpful? i dont know, but it didn't seem that bad.
If the hate were towards a person, I would completely agree with you. But OP is only hating JavaScript-the-tool, so I have no contempt towards his opinion.
In contrast, if OP were hating on JavaScript programmers, then your indignation would be completely justified. But he's not, and I admit to holding a similar position: I hate C++ and prefer to never lay eyes on it again, but I have nothing against C++ programmers :) The difference between C++ and JS is C++ is less forced upon someone's career as the only language to work with.
thats a good distinction, and i suppose its defensible. but imagine you are a trumpet player, and a pianist walks by and says "i hate that non-instrument trumpet" unprovoked. no one is wrong to hate the trumpet. but saying it to a trumpet player, and then saying they aren't even a musician (implied by "non-language"), is going to catch heat.
and its undeniably true that javascript has got loads of warts. i mean, look no further than "javascript: the good parts" as perhaps the most recommended book. (i guess you already know this, but for the maybe 1 other person reading this...) but despite that, i enjoy the hell out of writing good js, and love that people can use what you make by going to web page. and w/r/t the warts, i feel that if they were corrected, my js life woulnd't change much at all. so when people point to the warts as evidence that its a bad language, all i can say is that while they are obviously bad, they dont end up mattering to me. thats clearly not true of everyone, but id bet its true alot. because of this, i find it pretty easy to spot people who are excited to hate js because they are pretty sure its a safe thing to hate and it will make them look in the know. i mean, i was guilty of this when i was younger with mysql and php.
and yes, people being "forced" to use js is surely contributing to the hate, probably the same way people hate having to use css. they look at them as afterthoughts, but its funny because in a lot of cases, its like the main thing that needs work. i just wonder why people cling to the idea that "real programming" has a certain look, when being good at js and css is super helpful and important to good web projects.
i suppose we are arguing for the same thing- basically open-mindedness and willingness to learn.
Two days after you two posted this thread of comments, and I must thank you for it.
The analogy of musical instruments may be appropriate here; I feel that my ability or failure to be productive with a particular set of tools to be an aspect of my identity.
Set me to debugging a C++ or Java class library and I can get to work, but these may not be the tools I would prefer to start with.
Am I a bad programmer? Hmm. Identity can be a fragile thing.
> its so obvious that people are just looking for reasons to hate javascript
Why would anyone have the motivation to do that? Either it has given them reasons to dislike it, or it hasn't. Why do you think anyone is predisposed to looking for those reasons?
its just a kind of hipster thing to do, to hate things. i did it with mysql and php. its like a way to show that you are cool.
Even worse though,is to have your personal identity tied up in the language you work in. If you are actually Brendan Eich, then I get you taking it personally, otherwise, who cares?
yea, i guess i shouldnt care as much.
the_cat_kittles I think you don't get the point of my answer or simply my answer was confusing, sorry for that. I did not wanted to start a big discussion here and just throw a controversial, stupid example. But it very clearly shows my main point. The point is that it is easily to write a code in Javascript that looks ok, but is not. The lack of good type system, legacy of how it was implemented on the beginning and everything connected to lack of general safety leads to this conclusion.
I disliked it myself up until ES6 when it started to be "enjoyable" or..should I say less annoying. I program in 6 languages (it may not be much but enough to draw a conclusion from a sample) and I can't say I have one without it's list of wtf's.
By placing big keywords in your bio like "Serial enterpreneur, haskeller, programming languages design freak, former senior R&D technical director in the biggest film studios in Europe" + "hates java script" and keeping your flag up here makes it look very unprofessional. Of course, who are we to judge if not...your target audience for a "functional programming language", visual or not.
I remember when RoR came out and some [1] "cool dudes" decided to mock everything else on the planet. RoR vs php, RoR vs this and that. It made me feel sick even though RoR was a big step up from everything else back then. It took me 2 - 3 years to even consider it because of that.
[1] https://www.youtube.com/watch?v=EnnpbVW7Yb8
So in the past I have used two self-proclaimed "visual programming languages", Blueprints[1] and Max[2] and in both cases I found that it is actually harder to be productive while dealing with UI elements than it is to simply write code (as long as you have at least some rudimentary form of autocomplete I guess).
However I have to say that, based on the little I've seen, Luna's UI seems to be actually developer-friendly i.e. the UI elements go hand-in-hand with code rather than getting in the way, I think it's brilliant, sort of Jupyter Notebooks on steroids.
[1] https://docs.unrealengine.com/latest/INT/Engine/Blueprints/
[2] https://cycling74.com/products/max
What is interesting here is that you can switch between code and visual representation. All luna code can be looked at in either mode.
Max does allow you to use JavaScript or Java and they are doing a lot right now with JavaScript interop/export.
Thanks for pointing me in that direction, I should have looked at the JS interop capabilities in Max.
Part of the difficulty, I think, may be the mismatch between how Luna represents a piece of code and how I visualize it in my head. Is Luna going to draw a line between some related things when I would rather see them, say, in the same color? Will it show an arrow pointing from a data source to its destination, when I would rather see the destination pointing to it's source?
My worry is that Luna's visual model of the code will not match my mental model, and the impedance will be too much to overcome.
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 :)
Exactly! And Quartz Composer leads to OpenGL shader trees.
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.
I'd productize this more as the next level of "spreadsheet" than of "programming language". These kinds of visual programming things always seem to come out with lots of fanfare but then never get used for real work. The spreadsheet, however, is by nature reactive, relational, visual, impromptu, yada yada. But even though spreadsheet tech has added lots of functionality over the years, it's still essentially based on an old paper grid.
I could see a product like this challenging that old basis with something more modern. But it still has to do all the stuff regular spreadsheets can do too. And ensuring that it can, and in an intuitive fashion, should probably be the first priority.
Or start by doing enough of the stuff Excel can't do easily or at all and then grow into what you've described. For example: * Plot 3d (x,y,z) and 4d (x,y,z,time) graphs * Hook into data streams * Multi-user editing * JSON-like data structures beyond 2d row-column data structures * Improved output formatting
I'd be happy enough with floating sheets. To resolve those common things where you've got two different sections, like an analysis with a summary section below it. It's annoying because e.g. changing the column width on the top part also changes the column width on the independent thing below it. A tool that lets me put multiple independent sheets on the same page would be great. If the tool can be programmed to run image processing algorithms on the same page, that's fine too.
I'd view "IO" as almost equivalent to "Macro" in that instance. Though not quite. I'd like to be able to have e.g. $A$1 be a filename and $A$2 be the image in file $A$1, and that to be understood as a "pure" transform, even though under the hood it's got to open the file. So "application-scope purity" rather than process-scope purity.
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 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.
This is one of those things that always seems like it ought to be the future but for various reasons it doesn't take off. My high school computer class used a programming language called ProGraph[1] that looked a lot like this, but without the text representation, and it was neat but honestly it was more tedious to both read and write anything of even moderate complexity than a pure textual form.
[1] https://en.wikipedia.org/wiki/Prograph
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.
This got me wondering if the designers of the circuits that run software view textual programs as an oversimplification...
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...)
Given the name, I would expect this to be related to or built on Lua. That doesn't appear to be the case. Is this echo accidental?
"Traditional software development is broken by design" is a pretty strong claim, but the only support is a bunch of over-broad anecdotal claims about what "always" happens. That's a bit offputting for some of us.
The phrase "Category Oriented Programming" is used like it's common vernacular, which I don't think it is. Is it related to Category Theory? The text seems to imply that the idea of mixing functional programming with message-sending objects is novel. It really isn't.
"Unmatched performance and safety". Yeah. You want to be careful about that claim. Going to need to see the independent evaluation results.
That said, for those who value diagrams highly, this looks interesting. I wonder at what level of complexity the abstractions start to leak.
This is similar to Knime [0], which lets you build "workflows" visually, and allow you to write custom blocks with Python or Java. The main difference seems that you can represent the whole workflow in a human-readable (and writable) format.
https://www.knime.org/example-workflows
I find thinking visually to be quite limiting.
Although having a mixed textual representation is interesting. I sort of get this with the Moose platform in Pharo which I use for analysis based work. The most painful part of that though is interfacing with foreign systems. And maybe Smalltalk... not a bad language but I've been bitten by the Haskell/Lean/Idris bug. A seamless FFI experience as promised with this language coupled with a toolbox rivalling Moose would be interesting!
What is text itself but a visual representation of something complex? I repeat, text is intrinsically visual and just a restrictive form of the alternative which is diagramming. Is it a pure coincidence that the english alphabet happens to be the best primitive for representing programming concepts?
I believe that there is no coincidence. English is horrible at representing programming concepts. A limited set of characters, restricted left to right reading and line based structures... is this really the best way to program? Intuitively, things like recursion, data structures, processes, modularity and objects etc, etc, are better represented with diagrams... Wouldn't Circles and lines that can move diagonally across the 2D plane be better candidates as programming primitives?
It's hard to say really. Functional programming is in itself a restrictive form of imperative programming that gains power through restriction. It may very well be that English as a programming primitive gains the same type of power through restriction as well. Our brains have dedicated modules for processing language as well as dedicated modules for processing geometry, shapes and diagrams. Which module is better for programming?
Let's face it though, English as a programming primitive only became prevalent for historical reasons similar to how javascript (a shitty, shitty language) became prevalent. We like it partly because we're used to it.
There has got to be a better way.
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.
Math.
When learning graph theory it can be quite useful at first. But once you start using set theory the graphical representation actually hides more information than it gives and intuition starts to get in the way of us discovering useful properties.
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.
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.
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 ;)
Actually diagram might be better suited, for example to display the difference between sequential in parallel tasks.
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.
One of the examples I saw you guys give on YouTube is how complex things are becoming, and you talked about the LOC of a modern car and this is a reason we need visual programming. On your website you also discuss the limitations of UML.
To design complex systems like a car, you really need to know not just the functionality and the type of information, but also the structure of the system. How do all of those systems on the car physically connect to result in the behavior.
It seems like your approach would be really powerful for data processing, since in that case I don't think the structure matters much. Have you thought about how this could be applied to a complex system where structure is extremely important?
How do you envision version control/code reviews with Luna projects? Can diffs be explored at visual level or only source code level? If one developer moves nodes around without altering any logic are such changes tracked in the code repository?
For starters we've made sure to make git diffs as readable as possible. The visual data is kept at the end of text file (hidden when using our editor), usually in a single line. So if you just move nodes around, one line gets changed and it is clear what to ignore when scanning the diff, while making sure to retain the changes in the repository. For later stages, we envision much deeper integrated version control, including viewing git diffs in the visual editor.
This sounds bad. Any info in the text related to the visual representation will be unreadable i guess. Hiding such for diff review is helpful but not enough. Because in merge conflict resolution one may not have the luxury to neglect it.
> Traditional software development is broken by design
Which is why Luna is entirely hosted within itself and needs a Luna implementation to bootstrap.
We wouldn't want to ask investors to believe in any traditional development after telling them it's broken.
This idea will eventually work and be huge I think (I know visual programming languages already exist but a commonly used one to emerge). As someone who believes in metaprogramming and flexibility though I'm hoping for something dynamic, not a heavy mandatory type system that compiles to Haskell.
We believe in something very similar, there are some differences though. Luna type system is not dynamic BUT it is also not mandatory. Our whole standard library does NOT mention a single type - all are inferred by type system and you can, if you want, state them explicitly. To sum this up, we want Luna to be simple to use, intuitive, but have a strongly typed backbone with power similar to Haskell or Idris IF needed. Does it makes sense to you? :)
Thanks for your response and that does seem like a nice compromise, but it's still not perfect to me.
If the choice is <untyped>|<haskell>, it's better than just <haskell> but I'd love some <gradually typed, allows side effects>
Good luck with your project, looks pretty cool
I like the idea of category-oriented programming. Would be interested to see a white paper on what that means.
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 bogus, they just wanted to use the word "category" to try and lure in FP enthusiasts.
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.
That's just plain-old dependent typing, isn't it? What's in this and not in, say, Idris, such that you can say that it's a whole new paradigm?
1 also belongs to 'all integers from 1 through 10'. Is this also a category? (I assume yes). How is this category expressed in Luna?
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 :).
And you know that because?
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.
This sounds a bit like Idris with its dependent types.
Is this related to the luna programming language experiment by TJ Holowaychuk?
https://github.com/tj/luna
There is also a framework by this name that is (was?) being developed by Asana.
Naming is hard in the global namespace!
Yeah it was - https://news.ycombinator.com/item?id=2191800
It's not. That is just a name clash, but in our early days TJ was so kind as to pass the ownership of luna organization on GitHub to us :).
Looks like a lazy functional Python ) Very nice aesthetics of presentation.
There are a few things I am concerned, if you don't mind: I think that actually visualizing lazy computation can be quite a challenge, because of its on-demand nature. One might say that a lazily defined expression is computed (and should be visualized) where it's used, rather than where it's defined. There is a lot of substitutions going on under the hood, and computation is not as clearly localized as it would be in eager evaluation. Also, the tight binding between the code and the visualizations may limit your ability to optimize code for efficiency.
The True / False switch looks cool, but it feels like you are cheating here a little bit by using a boolean literal. Would it look equally nice if it's a function call or some complex expression that is possibly not known yet (as in a function definition)? I have a feeling that at the end of the day Luna may require a very complex visual language that is not easier than the textual alternatives.
But this is more like arbitrary concerns that will be hopefully clarified once you release the whole system. Thank you for your work.
Thumbs up for exploring these new alternative for writing code. I think, it may help us write better and safer programs in the future.
Why implement a new language rather than a GUI on top of Idris, PureScript or similar?
(That aside, very excited!)
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'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.
Because few care for Idris and PureScript.
They wanted simplicity and to control the language and syntax -- not to tie themselves to some Haskell-like environment.
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.)
Just some minor critiques.
What is confusing to me is if the visualization actually running the code or is just static analysis of the code?
The reason I ask is if its running then what you have built is a language with an absolutely awesome visual REPL. If it is please say its a language with awesome visual REPL! A potential Excel for programmers killer. There are languages that tried to do this (Squeak, and Racket come to mind) but they were generally academic and more often for students/young adults (and not for businesses).
However you say whiteboard through out your marketing which makes me think brainstorming tools ala evernote, orgmode etc. I realize for VC they might prefer whiteboard.
Whiteboard to me is sharing and not really a tool. It means I have to register and create a profile when all I really want is a language with a powerful visual REPL. (again just my point of view on marketing).
Why don't we have both? And then some more. It is an awesome REPL with a bit of Excel feel. Runs the code whenever you change it and displays the results in real-time. It is also great for interactive data sources (like web services), where you get the results as soon as they appear upstream. The whiteboard part is super important too. Visual representation is great for design and brainstorming. Even more so, when it provides runtime feedback about your designs. And it gets even more important with collaboration. So at this point we've got a collaborative whiteboard that actually runs the computations. There is, however, one more part to the story. Neither whiteboard, nor a REPL are well suited for implementing the final, production software. We aim to blur the lines between the design and implementation phases, allowing to deploy whatever has just been "sketched".
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!
This. Looks. Awesome!
I literally cannot wait to try this out on some data processing/number crunching stuff!
The integrations with the likes of Python are super exciting as well - any plans (even remote ones) to do the same with Julia?
I'm glad you like it! :) I'm very curious about your feedback after using Luna, don't forget to keep in touch with us after the release!
We do not integrate with any language, because the visual representation is just a different syntax for Luna. In fact we keep both syntaxes - textual and visual with the same powers, so you can switch between them, but they are just syntaxes for the same language.
Integrating with Julia (or other lang) would be hard because the language has to be designed in such way that it will allow for such dual representation. We put an enormous effort to design Luna this way. However it will be possible to integrate Julia in such way, that some of the nodes would be written in Julia and then even allow to in-place expanding nodes to small text-editors to preview the code in place. It will however not be possible to translate Julias code to graph or vice versa.
Awesome, we need more visual programming languages coming out now. it's so impossible to convince a programmer who never experienced visual programming how useful/practical it can be.
I understand you are from a video processing background where visual programming is widely employed.. We are also building a visual programming platform, inspired from enterprise tools. Really interesting to see this domain evolve.
This looks really beautiful: what's it written in?
Also, "Num in IO", nice. Now we wait for someone to write a "(Num in IO) in IO" action.
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 haven't tested it yet but i mind if this is possible to make microservice with this ?
Like defining an port (like 80) an input (a json like {"example":0} make an operation an return a value by the same port and json.
It could be an nice way to include micro service into a larger eco system or make people collaborate using luna in larger project.
For python you may use hug or flask
That s an interesting idea btw
good job and good luck
You say you have dependent types
OK, could you define this?
Examples on the home page have broken indentation, or just a multi-level indentation that is confusing?
(Why is `origin =` indented at all?)To line up the equal signs, so all assigned values are aligned as well.
You are right, all the last 3 lines should be aligned max to the left. We'll fix that soon on new website!
Another thing, this example wouldn't type check unless it is verifiably a list of non blank strings:
The section about dependent typing says `lst.head` would be a compile time error in some cases.Isn't it similar to what Eve tries to achieve? Well, what I like in overal, is an attitude and courage to introduce new technologies! I come from the Red language camp, which if I am not mistaken, is also being funded. So - good luck, guys :-)
Yeah, we have a lot of the same views about programming, but our focus isn't on data science. We can definitely agree that the practice of programming in the future won't look like it does today.
I think it's interesting that if you look at this and at Eve, you'll see how both are trying to improve programming and end up at quite different approaches. No size fits all.
Wojciech, this is incredible! The combination of expressiveness, type safety, visual programming and API focus are pretty unique right now.
By the way, "Aggresive compile-time optimization" should be "Aggressive compile-time optimization".
Where are the node positions stored?
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.
Nice.
A few more questions:
Is does z-ordering just follow the painter's model?
As a user am I allowed to place two nodes at the same x/y coordinate?
As a user am I allowed to position nodes in a way that creates a visual ambiguity in the diagram (e.g., two or more perfectly overlapping edges among nodes)?
Edit: As a user am I allowed to place a node at an x/y that lies within the bbox of another node?
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.)
Why do you store the visual node positions? For me it is hard to imagine anyone want to edit those. Why not just automatic layout?
This way we are also compatible with git etc! :)
How about conflict resolving? Is it some base64-like snippet or human readable representation?
I truly hope you will succeed in your mission. It looks like it could solve so many problems that I've come across as a result of confusion and miscommunication when people with a common understanding step away from the whiteboard and start coding. It can be so hard to align the implementation with the visual abstractions we so desperately need to communicate as humans.
Cool concept - is there an open source repo of some kind which shows how a complex application (kitchen sink kind of app) is made?
Thank you! We will be releasing demos soon!
Are you guys going to release something describing your concept of "category oriented programming" any time soon?
We will try to cover it alongside the upcoming release! :)
If Luna is dependently typed, can it be used to do theorem proving, eg like Idris?
I'm struck by the similarity to grasshopper. This seems to share many of the same features such as visual profiling, visual / textual representation, live previews etc... Has it inspired the design at all?
Grasshopper did not, but Houdini / Touch designer actually did.
I would like to subscribe to the news, but am afraid to use news-letter services. I suspect they sell the addresses to spammers. Would you please instead set up an atom feed or a primitive blog on Blogger?
What is it compiled to? Does it target JVM, CLR, native code (if so what platforms?) What is it compiled with? LLVM ? GCC ? Custom compiler? What is the standard library like?
It targets few backends. Currently it runs on our VM, but we are working on targetting GHC's Haskell Core (which then compiles to LLVM IR). Luna's compiler is of course a custom compiler written in Haskell. Standard library looks cool!
Did I answered your questions? :)
>standard library looks cool
What does that even mean? No offense, but like I haven't seen any demos on your website and you are describing the std lib as cool? Not exactly confidence aspiring.
It looks interesting for sure and looks really fun to mess around with (frankly has a hobbyist high school programmer who likes systems programming, I don't see a whole lot of use for me :))
Good luck.
It targets GHC
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.
Im happy to hear that. We do our best to realease it soon and I'd love to collaborate further with you then!
Any relationship to TJ H's repo, http://github.com/tj/luna ?
Other than name – none at all :)
Isn't it similar to what Eve is trying to achieve?
What beautiful black magic programming even despite the fact that I hate flow chart programming like unreal and other game engines do.
I'd like to see how the visual representation of larger non toy examples look. Looks like a very cool project !
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 :)
so when's the ICO?
Looks cool! Is the editing environment extensible enough to support an embedded neovim instance?
It sounds like it wont compile to C or use LLVM, you have some kind of custom VM?
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.
anyone try bubble.is? Love to get a comparison on how this is better / different.
Pretty bad name, I thought it was a typo for Lua.
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.
https://en.wikipedia.org/wiki/Janus
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
There are more ways to spell the name, maybe one of them doesn't trigger that association?
I mean, I don't care if you keep it as Luna. Just saying you're gonna have problems if you keep that name
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!
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
I agree. Lua is moon in Portuguese; Luna is moon in Spanish and Italian.
Luna is moon in Russian as well (stress is on the second syllable though)
Ding Dang Lyrics – Munna Michael (2017) | Tiger Shroff http://www.desilyrics.in/2017/06/ding-dang-lyrics-munna-mich...
Radha Lyrics – Jab Harry Met Sejal | Sunidhi Chauhan http://www.desilyrics.in/2017/06/main-bani-teri-radha-lyrics...
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 :)
How do you do basic branching and loops?
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 :)
im pretty you just got called out and are walking it back now. thats fine. there are lots of ways of handling typing in javascript. i could be reading more into you answers than is there, but your apparent proud ignorance is, i think, fairly deserving of a little bit of public shaming.
We detached this subthread from https://news.ycombinator.com/item?id=14615377 and marked it off-topic.
> there are lots of ways of handling typing in javascript
No, there are not.
you deserve more public shaming than him. Sure he hates javascript and has valid reasons to do so. You, on the other hand are so insecure (probably because you've spent years using this language), that you have to make personal attacks.
well i can tell this is turning into the bad kind of internet commenting. you are calling me insecure- thats a personal attack. is it wrong to call someone a snob for being snobby?
is it wrong to call someone a snob for being snobby?
I'm not a snob. I grew up on a small farm. I can milk the cows and have moved a few tons of grass by hand because the barn was to small for machinery.
I still strongly dislike javascript.
Maybe you could respect our right to hate or at least strongly dislike a language that
1. Is being forced upon us as the coolest thing since I don't know what
2. has quite complicated and IMO dumb ideas about equality like
2.1. http://dorey.github.io/JavaScript-Equality-Table/
2.2. https://stackoverflow.com/a/359509
3. Feels like it changes major parts of one of the build systems every second week
?
ok i dont think snob has anything to do with upbringing, but yes- i dont really care for the tons of articles about new dumb frameworks etc, that would only be more annoying if i didnt use js. you are also allowed hate js. just kind of weird to parade around the internet proudly proclaiming it (not you, op)
The difference is the others are hating on a technology, not a person. You are insulting a person.
He didn't insult javascript developers or people who like it he simply said he doesn't like it, which for some reason got you personally insulted.
Hate is a word used in the modern world pejoratively to mean strongly dislike especially I've noticed those with English as a second language.