Luna – Visual and textual functional programming language
luna-lang.org
luna-lang.org
1. We've raised a seed round of $1M, so we can safely focus on product development and shortly on community building! 2. We've improved our core technologies to be much more robust, open and extensible, including:
- We've re-written our graphical interface to be much more open and extensible (it was previously running on WebGL and now we base just on HTML, so it will be possible to attach any HTML-compatible controls / visualisations directly to nodes) - We've implemented new, better type inferencer and updated Luna compiler in many ways. - And much much more, but I don't want to uncover everything before the release, especially when it's around the corner :)
I would love to answer your questions, so If you've got any, just post it here and I'll do my best to cover it. Don't forget to singup for the list at http://luna-lang.org. We'd love to collaborate with you during the upcoming release! :)
Cheers, Wojciech
Answering the question more directly, we will be providing payed support and hosted computing environment with automatic scalability in the future, however now we will be focusing on building community and helping everyone gain from what Luna has to offer, keeping Luna completely open source and free.
Did I answered your question deep enough? :)
In scientific spaces you have many data sources that all mean completely different things. They are all recorded in different coordinate spaces (mag, distances, polar, etc) and you want to plot many of these things into the same plot and have them go where they were meant to be.
If you could generate 3D plots as well just by flipping a switch that would be a huge plus. The hard part is that we have many modeling softwares that are written in strange ways and in strange formats. One example of a very popular model with a difficult interface is the IRI (http://irimodel.org/). If you could just link a node of "IRI" into "Earth Plot" then that would be awesome.
Keep up the good work!
I'm not talking COPs or Houdini is something bad. It is one of the few applications that I support with whole heart and I love it. In fact Houdini is a very rare example of really well defined visual DSL.
Luna differs in many ways, the most important are that we've got double representation and Luna is a real programming language, while Houdini provides you limited set of building, yet very powerful blocks. I would however love to see Luna used within Houdini as a plugin, I've been already speaking about it with some folks :)
(I'm totally not saying there's no need, but since it's highly technical and I probably would fail at it I'm really curious)
Well it's not really a programming language, but a data processing platform, business people love that -> VCs love that.
You might want to add what you just posted, there's nothing wrong with it, but it would make more people to get it IMHO.
Look, we've been working on Luna for over 2 years now, full time in a team of 7 people. We were often working during weekends or hardly sleeping at nights just to create what we believe in. We were constantly using software build the same way - linux, ghc, atom, etc. Now we want to give it completely free for everyone and we want to survive not because we want to be reach or famous, only because we so deeply believe that Luna really can drastically change something important in the data processing field. We will not survive without people engaged in this project, without people that will make it shine in different domain specific fields. We don't want then to "close" it - it will always be open and free (which is somehow guaranteed by the license too). As a company we need to make money too, but how could we make money not being honest?
We want to build community around good developers only because Luna could be a big development boost for them and additionally, we can together bring it to less technical people and help them too in their daily tasks. If people like what we do, we can then charge for support and additional paid services, developed by us, but I think it is really fair deal and companies should be built this way.
Sorry for a little long answer, but I got that sentence emotional! :)
I'm feeling really inspired, hopeful, and happy when I read comments like these because I consider the lack of vulnerability in the startup world to be as sad as the lack of authenticity. Thank you! I hope you'll keep doing what you're doing.
Are you, by any chance, familiar with nonviolent communication? https://en.wikipedia.org/wiki/Nonviolent_Communication
I was prompted to write my original comment by the simple fact that (usually, in my experience) people stick to the half-truths that are easiest for them to communicate, rather than embracing the hard work of truly conveying their inner meanings (note the plural). To wit: once a website is up and a coherent (albeit incomplete) ’truth’ has been ”put out there”, rarely would I expect the author of that website to turn around and say ”that is the self-serving story we wish to convey to one subset of our potential audience, those who self-select by relying on our website for information”. It's a very intellectually honest approach to admit that the content of the website is not Truth but rather some kind of social mechanism, every. It as ’functional’ as the code itself, and serves the a ’propagandistic’ purpose.
Collectively I summarise all of this as ’candor’. ;)
I love the visual/textual dual language concept - I've been trying to figure out a good solution where both work well and no information is lost from one by editing the other (eg if I create something visually, but edit it textually, does the layout get ruined?) and, at a glance, you seem to have largely solved this or at least managed to get it working well enough. Awesome.
I also like this as a tool for data processing. This kind of platform is something I've been wanting to build (and prototyped once a number of years ago even) for a long time. Couple it with a simple (and familiar) spreadsheet system and your golden (for my purposes - other people may think otherwise).
I haven't looked at Luna in any detail yet, really just glanced at the screenshots so far (I hope to read the material properly tomorrow), but one concern that jumped out at me was that the visual language semantics aren't clear to me. Of course, its probably unreasonable to expect to understand a new language without having read the documentation, so its unlikely to be an issue. I only point it out because I've seen a number of other visual languages claim to be super user friendly (even to non-programmers in many cases), when, IMHO, it really isn't unless you already deeply understand the concepts. I didn't see you making this claim though, so all good :)
Overall, I'm excited for this and wish you the best of luck. Hopefully you will choose me for alpha access so I can play with it ;-) :-P
I'm happy that so many people were thinking to do something going this way - we hear it often. This shows us that this need is widely seen and there is nothing we want more than just collaborate with these people. We will be releasing Luna shortly as Open Source project and will be helping growing community around it. I will be supper happy helping utilizing / extending it for your needs!
As I described before, the timing for this info is not the best, because Luna is not yet available, but it will be really shortly.
Luna introduces some abstraction levels. Some of the leaves (the highest ones) could be usable by less-technical people, but of course only after they get familiar with the concept! :)
Thank you and looking forward to building something interesting together! :)
For what it's worth, I've tried the page on 7 screens/devices here, and it was only properly readable on 3 (two of which are very similar models by the same manufacturer). On three of the screens (two really new), it was more trouble than it was worth.
Maybe with documentation? I could at least help with editing / proof reading and the drudge work you guys are too talented to be doing! Your time is much better spent on the core development.
Drop me a line at wojciech at luna-lang.org and we could work something out :) I do not promise we will be able to collaborate before the release (we've got our hands full of work and we're hardly sleeping in nights now), but in the early days / moths after the release the help would be much needed and we would love to build community around people as passionate as you are! Thank you! :)
Let everyone check it out, the passionate ones will engage more through any channels you have (mailing lists, chat, twitter) and be easy to find, IMO.
After reading some of their comments & the copy on their homepage, the creators of Luna sound like they could be fairly mindful people. I'm betting they're seeking people who enshrine certain values to seed their community with & want to privately establish a relationship with them. I find this approach appealing to my introverted side, as a result.
The next mindful step would be to open things up to everyone immediately to allow the ensuing flood of extroverts & introverts alike. This approach seems like it could counter starting off with winner-take-all mechanics in the community's culture.
Then again, all I know about the product is from the first bits of text on their site & this post. I didn't know they weren't simply allowing everyone in until this thread. I could be totally off on how they're rolling. If I am, I'll have to take some time to examine my confirmation biases.
We are not looking for any investments now but we are looking to collaborate with everyone interested in Luna, so that sounds like a "perfect match" for us! :D
Could you (or anyone else) elaborate on MIT vs Apache V2 and patent protection?
I asked before as googling because there are often very well-informed software legal opinions on HN.
[1] https://www.quora.com/Whats-the-different-between-Apache-v2-...
So do you have first-class support for video as well as images? It seems like to have fun with video editing in Luna, you'd need to have built-in support for videos an inputs and outputs, and have a way to play the video output on the screen, and maybe scrub through it, and at a minimum be able to run shaders on the "current frame" and export the resulting video out. The next level after that would be being able to load multiple frames into memory at the same time, and being able to do a combination of "offline" and "online" processing with some CPU involvement (e.g. calculating a motion track and storing it, or applying a filter that can't be expressed as a pure shader program).
I don't know enough about Luna yet to know what code to do these things would "look" like on the visual side, or come to think of it where the computation is being performed (in the browser?). Much more to learn, but the project looks great, a sort of "holy grail" in a way.
You can think of Luna just like about a general purpose programming language. You can define your own types and you can even define how to decode bits from binary files to your structures. The GUI runs in HTML, so you can utilize any html component to display output. Definitely, your use case is doeable, however the amount of libraries currently available is very, very low, so it will need some love :)
Did I answered your questions? :)
Is there a particular timeline on that? I'd love to see how this is implemented (and - importantly - whether or not this can easily be integrated into other software).
Just in case anyone else faces this issue, another possibility is to do WebGL-above-HTML two-layer hybrids, with punchouts to see the synchronized HTML. But perhaps not worth the pain for 2D UIs.
Hmm. Last year I half-started a quick hack of atom.io with CSS3D in Vive VR. Intended for purescript et al. But the display's angular resolution was painfully low for working with text. It looks like Luna might be an interesting alternative for exploring coding in VR.
Also on my infinite todo list are exploring VR direct manipulation of a category-theoretic pushout lattice of <types,ops,laws> theories, and (separately) an interactive editor for string diagrams...
Any thoughts on using Luna as a compiler target?
Because I gave this some thought as well and don't see why not in general, but I don't know how luna works .. or if there are some restrictions I did not encounter yet ..
If you are thinking about visual language you have to think about many constructions that collectively give you user experience, including available basic construction blocks (how looping, branching works etc), structures, lambdas, every language construction, how you give hints to user what is possible and what is wrong and additionally how to do this real 2 way transformation of code and graph.
Luna infers types and displays colors according to them. We use algebraic data types, lazy evaluation, pattern matching and purely functional paradigm which suits graph visualization really well. We fine tune performance by allowing lazy data visualisation and many, many more things. I don't know how we can even visualize standard OO abstractions to be usable and pleasant to work in the visual form. It does NOT mean we did not think about it. We did for a long time.
Sure you can utilize Luna gui to visualize anything, including python code, but it would be insanely hard to deliver similar functionalities to what Luna offers out of the box (which is available by careful design of both representations).
I feel thin answer is very vague, but I hope I put a little light on how complex this task is. Did I answered your question (at last partially)?
I would like to try out the beta once you publish(soon?), to see more what you do and understand better (and see whether my ideas could be compatible, or not)
I don't know if or how luna handles this, but its a concern that I've had trouble with when I was thinking about something similar in the past.
How do you expect the visual syntax to integrate with VCSs? Do you have an algorithm and UI to present visual conflicts? How is the layout after a Git merge?
Cheers
Two questions: How does Luna compare with flow-based programming model implementations such as Apache NiFi and its Expression Language or NoFlo? And do you find Luna appropriate for Internet of Things real-time data processing?
My question: what has changed? Has anyone addressed any of the fundamental questions that were posed last time this was submitted? Are there any concrete examples of how you might use this for general purpose programming?
Regarding the questions, I've just put some small summary of updates on the top level of this thread. Regarding real world applications, Luna will be well suited (but not limiting to) to interactive data science, creating custom data visualisations, microservices management, rapid prototyping of any data processing networks (inlcuding IOT systems) and of course graphics or sound processing.
A lot of work in robotics involves software that maps to this style well (functional-ish, where data is being pushed through computational pipelines / graphs), and I think this could be a killer development environment for things like control systems, sensor fusion software, image processing / computer vision, etc.
The fact that it is going to be open source, and already seems to have some nice support for things foreign libraries, profiling support, and well as visualizing of your data visually (that image processing graph example!) makes me think you are going to get a good response to this. I also think there are a lot of hobbyist type projects (RasPi level 'smart home' stuff, algorithmic art / music, SDR, anything you see on Make / Hack-A-Day) who would love a tool like this!
I'm very interested in checking this out, and in contributing packages / libraries if that will be supported. Hoping to get access to the alpha!
LabVIEW
Why I'm excited about this is: 1) It's open source, so we can extend it and hack on it as needed. Thos is probably the biggest reason. 2) The dual textual / graphical representation is really useful in cases where you might want to switch between the two, or one makes more sense than the other. You can do some with text in some the other tools, but the last time I tried, it felt like an after thought more than something expressly designed into the language. 3) It looks to be designed as a general programming language, focussing on having a good compiler, good tooling and a nice foreign function interface. My hope is that this means we can incorporate it into our existing code bases easier than labview, where it kind of wants to stand alone. As an example, perhaps I have a large existing codebase for my robot written in C++ with ROS. Perhaps I could use this to create a new ROS node that does my vision pipeline, by taking advantage of the fact it compiles down to native code, and has a foreign function interface designed in from the start. (Or maybe I'm dreaming, but my hope is it would be easier and more performant than doing the same in Labview!) 4) Did I mention open source :-)
- Luna works in a purely functional environment, which allows for much more clear and easier to understand graphs. Moreover it enables us to run computations in parallel automatically (without any input from the user, however we will be supporting it very slightly during the first OS release).
- Luna allows you to convert between textual and visual representations - in both ways, always.
- Luna is a real programming language, so it is not just a pack of predefined components. Every component is created out of other components (or functions, you name it), so you can always go as deep as you want or just connect functions from other languages.
- Luna allows you to collaborate in many people on one, visual canvas.
And much more! :)
> "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.
Would "Loves dogs, hates Java Script, willing to meet you in the middle if you disagree on either" be accurate?
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".
https://twitter.com/horse_js/status/872243719889616897
:p
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/
Max does allow you to use JavaScript or Java and they are doing a lot right now with JavaScript interop/export.
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.
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.)
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 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.
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.
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.
"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.
Although having a mixed textual representation is interesting. I sort of get this with the Moose platform in Pharo which I use for analysis based work. The most painful part of that though is interfacing with foreign systems. And maybe Smalltalk... not a bad language but I've been bitten by the Haskell/Lean/Idris bug. A seamless FFI experience as promised with this language coupled with a toolbox rivalling Moose would be interesting!
I believe that there is no coincidence. English is horrible at representing programming concepts. A limited set of characters, restricted left to right reading and line based structures... is this really the best way to program? Intuitively, things like recursion, data structures, processes, modularity and objects etc, etc, are better represented with diagrams... Wouldn't Circles and lines that can move diagonally across the 2D plane be better candidates as programming primitives?
It's hard to say really. Functional programming is in itself a restrictive form of imperative programming that gains power through restriction. It may very well be that English as a programming primitive gains the same type of power through restriction as well. Our brains have dedicated modules for processing language as well as dedicated modules for processing geometry, shapes and diagrams. Which module is better for programming?
Let's face it though, English as a programming primitive only became prevalent for historical reasons similar to how javascript (a shitty, shitty language) became prevalent. We like it partly because we're used to it.
There has got to be a better way.
When learning graph theory it can be quite useful at first. But once you start using set theory the graphical representation actually hides more information than it gives and intuition starts to get in the way of us discovering useful properties.
I find language to be better suited for imperative procedures. Think about it, I have a list of tasks, do I write that list in ordered English bullet points or do I draw a diagram?
Programming languages tend to be a little less expressive and elegant. They're more complicated too. For reasons of course... but I don't think I'm going to be writing algorithms and data-structures in such a tedious notation as a diagram.
Graphics are good for some things but programming I don't think is one of them.
This is pretty much why we've gone with interchangeable representations instead of going "visual only". The choice of the proper tools / representations highly depends on the context, and we want to leave that for the programmer's decision.
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?
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.
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
Naming is hard in the global namespace!
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.
(That aside, very excited!)
I imagine in a visual environment, being able to make useful suggestions on potential ways to use/combine different nodes/types would help as well as an auto-complete for the user's intent.
I'm actually also a bit reminded here of MS Excel Power Query, which also offered a GUI for data transformation, see e.g. [this pic](https://blogs.office.com/wp-content/uploads/2015/07/6-update...).
I bring this up because I see you covered visualizing the steps, while they focused on showing the data (though after finishing a transformation the script could be generalized into a reusable function). I wonder if adding a dimension like that could be helpful for Luna as well.
If you target non-programmers, showing things as concrete as possible (e.g. their data transformed by whatever function they just pulled together) sounds like it might help make things even more accessible.
They wanted simplicity and to control the language and syntax -- not to tie themselves to some Haskell-like environment.
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).
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?
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.
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.
Also, "Num in IO", nice. Now we wait for someone to write a "(Num in IO) in IO" action.
I would recommend that you focus on good error messages that explain monad-related errors in "user land" and not force them to either guess about what's wrong or suddenly learn all the stuff under the hood. It's a terrible experience and you see it in C++ with incomprehensible template errors or any kind of transpiled language like ClojureScript that gives you errors from the underlying implementation.
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
OK, could you define this?
data Eq : {a : Type} -> a -> a -> Type where
Refl : Eq x x
sym : {x : a} -> {y : a} -> Eq x y -> Eq y x
sym Refl = Refl
replace : {a : Type} -> {x : a} -> {y : a} -> {f : a -> Type} -> Eq x y -> f x -> f y
replace Refl p = p class Point:
x y z :: Int
origin = Point 0 0 0
Point x y _ = origin
print 'Origin XY coords are ($x,$y)'
print [s for s in lst if s.head != '_']
By the way, "Aggresive compile-time optimization" should be "Aggressive compile-time optimization".
A few more questions:
Is does z-ordering just follow the painter's model?
As a user am I allowed to place two nodes at the same x/y coordinate?
As a user am I allowed to position nodes in a way that creates a visual ambiguity in the diagram (e.g., two or more perfectly overlapping edges among nodes)?
Edit: As a user am I allowed to place a node at an x/y that lies within the bbox of another node?
Keep in mind, that point 2 and 3 does not happen during your workflow normally, so these are very rare situations. We want to support them just from the "purity" perspective, but they are very low on our priority list currently.
That means that Luna requires some kind of visual diffing step to reach parity with the development flow of text-based languages. Otherwise developers will get comfortable interpreting metadata changes as noise. In specialized languages like Max/MSP that leads to spaghetti programs. In more general visual languages it could probably even lead to security issues if an overlap suggest a different visual data flow than the source code. (And judging by Pharmaceutical TV commercials, people blithely favor the visual over the written when there's a discrepancy.)
Did I answered your questions? :)
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.
I've got a crazy idea here! I know that HN has some magical powers, so if you have any idea of a better name for a dual-representation, functional, visual language, we'd be more than happy to talk about it and change it before the release (after the release it would be too late)! :)
> In ancient Roman religion and myth, Janus (; Latin: Iānus, pronounced [ˈjaː.nus]) is the god of beginnings, gates, transitions, time, duality, doorways, passages, and endings. He is usually depicted as having two faces, since he looks to the future and to the past.
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