Luna is very much a general-purpose programming language! We’re working on developing both the language and the libraries ecosystem until you can use it for whatever you’d like.
While data-analysis is our focus at the moment, that isn’t due to any current limitation on Luna the language. We still have more we want to do to the language, but there is nothing stopping you from writing whatever you want in it now!
Looks cool - Considering your data-analysis focus, will you be adding: SQL language interop, Postgres data source component/nodes for functions(critical for me)/ views /tables? Would then become much more interesting.
Can you expand more on what you mean here? We currently have a work-in-progress library for binding to Postgres, but I have the feeling that isn’t quite what you’re getting at.
There are some other lessons too, especially regarding Haskell. Basically the sad truth is that if you do not benchmark literally every single line, you can suddenly get MUCH worse performance than expected. Sometimes GHC's strictness analysis does not discover that it can unbox some things and you land in a boxing-unboxing loop or you hit some of optimization bugs (during the work on performance we've reported over 10 GHC bugs and even implemented our custom graph memory manager). So one of the biggest problems that we encountered earlier was that actually the GHC performance is MUCH harder to predict than you think and you have to take extra care of it while building your software. Of course using Haskell pays off in other areas, but performance is tricky.
Thanks for the details. I would love to read still more about it to learn from the experience. E.g., What would be examples of the boxing-unboxing loop. All you have described seems worthy of a more detailed blog article in its own right. :-) Thanks.
To be blunt, performance is much more important than you think, even when building a proof of concept. We used the PoC code for much longer than was initially intended, and had we thought about performance from the start we might’ve saved quite a bit of work!
The only news I can give you at the moment is that it’s still definitely planned! We’re hoping to work on it once we finish our performance improvement and new GUI work.
Really what usually does it for me is just screenshots or links to videos that I can immedietly click on, at the minimum. You guys have some amazing stuff in your homepage already, maybe something in that spirit that wont take away too much from the technical side you're trying to portray.
Thanks for working on something so awesome, makes me feel like I feel when I watch Cowboy Bebop and watch Ed travel through cyberspace when I see your samples of how the visual aspect of Luna is.
I have been waiting YEARS for someone to bring the idea of 'zoom' into visual programming. I expect it should be a simple solution to the problem many visual programming systems face where any substantial complexity results in an incomprehensible web of components and connections from different conceptual layers of abstraction all presented at once. This is the first I've heard of Luna, but I'm looking forward to experimenting with it when I get home!
Thank you! It is so heartwarming to read such comments as yours. We are doing everything we can to bring this idea to reality. Please check out some of our Luna live session coding screen casts here (enable 1080p mode): https://www.youtube.com/watch?v=8_pi7LYpDYw&feature=youtu.be
Metaprogramming is definitely on our radar, and we have had some internal discussions regarding it, but it’s not one of the top-priority items right now.
We should be getting both our Mac and Windows developer certificates this week. I’m really sorry for the inconvenience - it should be fixed by the time of the next release.
It'd be nice not have the installer be an Electron app which then downloads something I can't cache/save, but just have the actual app be the download from the main page!
Unfortunately not! The graph in Luna isn’t an external visualisation of parts of the data flow, but an explicit alternate syntax for the Luna AST. It’s isomorphic to the textual syntax.
It would be possible, perhaps, to use some of the machinery for display to draw other pipelines, but I work on the compiler rather than Luna Studio, so perhaps I’m not the best person to say!
I understand well that this is a graphical representation of the code (and I find it really appealing to have this dual representation, rather than post-host visualization).
Though, as I imagine, such vis is at some point JavaScript code. (And one could potentially re-use this visualization (not - abstraction) tool for showin arbitrary diagrams with data lookups, in this lovely style.)
Oh, I understand what you mean now. My mistake! It is all displayed on Canvas at this point, which does go through JavaScript. We’re actually moving to our own WebGL-based canvas (BaseGL) for performance.
I should add that something like FStar [0] combines the capabilities of automated theorem proving and a more manual-proof-based dependent type system like that in Idris.
It doesn’t have some of the power of Idris’ elaborator reflection, for example, but it can eliminate many long-winded manual proofs via the SMT solver.
It made me smile to see your wedding venue. It’s a lovely place.