Live data from Hacker News

Luna – Visual and textual functional programming language

luna-lang.org

301–310 of 331 posts

Re: Luna – Visual and textual functional programming language

#301
post #26

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 commun…

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

Re: Luna – Visual and textual functional programming language

#302

Earlier quoted context omitted.

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, in…

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.

Re: Luna – Visual and textual functional programming language

#303

Earlier quoted context omitted.

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 edi…

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.

Re: Luna – Visual and textual functional programming language

#304

Earlier quoted context omitted.

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…

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.)

Re: Luna – Visual and textual functional programming language

#305
post #235

Earlier quoted context omitted.

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.

Re: Luna – Visual and textual functional programming language

#306
post #26

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 commun…

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?

Re: Luna – Visual and textual functional programming language

#307

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…

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

Re: Luna – Visual and textual functional programming language

#308

Earlier quoted context omitted.

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.wikip…

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 te…

This got me wondering if the designers of the circuits that run software view textual programs as an oversimplification...

Re: Luna – Visual and textual functional programming language

#309
post #265
post #222

Earlier quoted context omitted.

(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 ty…

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.

Re: Luna – Visual and textual functional programming language

#310
post #307

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…

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.

Post reply on HN