Live data from Hacker News

Unit is a general purpose visual programming system

unit.software

71–80 of 84 posts

Re: Unit is a general purpose visual programming system

#71
Hi,

I've probably mentioned this a few times on here, but Prograph was a GREAT example of a visual language, that solved a LOT of issues (spaghetti code) etc. It's worth a look if you're interested in visual programming

* object oriented * scrunching of code - tha could be turned into functions (local-to-opers) * you could edit code and values whilst it was running * FAST!

Here's an ole video of some server software I made, that at the end shows me rustily doing some Prographing.

https://youtu.be/MtECJw59elc?si=svRbd5_IA4cAFhVa&t=1429

p.s A free version of Prograph (Marten) used to exist, but when the genius creator died, the project, sort of lost its way too.

Re: Unit is a general purpose visual programming system

#72
post #68

Earlier quoted context omitted.

Are you saying visual programming languages can only work if they can be explained with text?

Sibling is right that video was the problem for me with that specific bit, but also: Text isn't necessarily a hard requirement, but the alternative is harder, in that then you need a tool chain that covers everything we do with code. That includes putting it in blog posts, emails, Slack in ways that are searchable, and can be decomposed into smaller bits, so images are insufficient. It's possible for a visual program…

I agree with most of your points up to this:

>likely to forever condemning it to a niche.

The context within which we build visual programming languages needs to change in order for it to stop being a niche. As you point out, the alternative is [much] harder [today]. But I think that VR, as an example, will be forced to solve a lot of difficult UX problems if VR is to progress beyond a niche. And once those problems have found satisfying solutions the context for building nice visual programming languages will likely also have improved significantly.

Re: Unit is a general purpose visual programming system

#73
post #69

Earlier quoted context omitted.

The trick is that you don't round trip. You choose one immutable data structure that captures both the textual source of the program and the semantic information captured by the parser at the same time.

That doesn't solve anything. The problem isn't how to represent the AST, but defining both a visual and textual version that can unambiguously represent the same thing without either or both representational becoming unusable.

Right. I think it's already a solved problem though. HTML and the HTML DOM are a living solution to that exact problem. All that we have to do is take the patterns used to power general UI and develop a DOM for code.

Re: Unit is a general purpose visual programming system

#74
post #67

Earlier quoted context omitted.

I'm pretty sure I have a general solution to that problem. The key is that hierarchies can be embedded in text, as HTML and XML do. Check out https://github.com/bablr-lang/

I'm not sure how that is solving it? It needs to be compact, and readable.

I personally think CSTML is both compact and readable, though I understand why it would look the opposite the very first time you see it (and without any syntax highlighting at that).

Open up the source code for this web page: is it compact and readable? The answer seems to be that HTML is "good enough" in that regard, and I suspect CSTML will be the same especially as more developer tooling for it becomes available.

Re: Unit is a general purpose visual programming system

#75
post #68

Earlier quoted context omitted.

Sibling is right that video was the problem for me with that specific bit, but also: Text isn't necessarily a hard requirement, but the alternative is harder, in that then you need a tool chain that covers everything we do with code. That includes putting it in blog posts, emails, Slack in ways that are searchable, and can be decomposed into smaller bits, so images are insufficient. It's possible for a visual program…

I agree with most of your points up to this: >likely to forever condemning it to a niche. The context within which we build visual programming languages needs to change in order for it to stop being a niche. As you point out, the alternative is [much] harder [today]. But I think that VR, as an example, will be forced to solve a lot of difficult UX problems if VR is to progress beyond a niche. And once those problems…

very well said

Re: Unit is a general purpose visual programming system

#76
post #69

Earlier quoted context omitted.

That doesn't solve anything. The problem isn't how to represent the AST, but defining both a visual and textual version that can unambiguously represent the same thing without either or both representational becoming unusable.

Right. I think it's already a solved problem though. HTML and the HTML DOM are a living solution to that exact problem. All that we have to do is take the patterns used to power general UI and develop a DOM for code.

The internal representation isn't the problem, or even a problem. It's not even beginning to address what I described.

E.g this is a real line of code:

    link = wf["links"].find{ _1["rel"] == "self" && _1["type"] == "application/activity+json" }
Now consider I have a visual programming version representing that expression, and I want to ask someones opinion about it on Slack. Unless your visual programming environment has a solution for how I can post that to Slack, and have others respond with tweaked versions, it's a non-starter.

Once you've solved Slack - maybe with a plugin -, you need to solve all our e-mail clients, and you need to solve Google Docs and Word for when we write documentation, and a multitude of other tools.

You might be able to get part of the way there with a browser plugin, but you'll still have a wide variety of other tools and platforms to cover.

Re: Unit is a general purpose visual programming system

#77
post #68

Earlier quoted context omitted.

Sibling is right that video was the problem for me with that specific bit, but also: Text isn't necessarily a hard requirement, but the alternative is harder, in that then you need a tool chain that covers everything we do with code. That includes putting it in blog posts, emails, Slack in ways that are searchable, and can be decomposed into smaller bits, so images are insufficient. It's possible for a visual program…

I agree with most of your points up to this: >likely to forever condemning it to a niche. The context within which we build visual programming languages needs to change in order for it to stop being a niche. As you point out, the alternative is [much] harder [today]. But I think that VR, as an example, will be forced to solve a lot of difficult UX problems if VR is to progress beyond a niche. And once those problems…

I don't see what VR has to do with this. You'd still need all the software you transfer this information via to support more complex data, and you'd still need a vocabulary to communicate about it. And if you have that, it doesn't need to be VR.

(EDIT: And specifically to the sentence you cut that out from: For it to appear in search results, and so be discoverable* it still needs to be in a form that search engines know how to index)

There's nothing technically preventing us from having all our software allowing the embedding of visual code elements that can be manipulated via components - the technology to do that is decades old.

The problem is a combination of social, inertia, and the chicken and egg problem of there not being any sufficiently compelling visual programming system creating a significant reason to push for this.

I don't want to discourage people from trying. By all means, try - I'd love to be proven wrong, and I think you might very well discover something useful or learn worthwhile lessons from trying to push the limits of this. There are just lots of pitfalls to address.

Re: Unit is a general purpose visual programming system

#78
post #67

Earlier quoted context omitted.

I'm not sure how that is solving it? It needs to be compact, and readable.

I personally think CSTML is both compact and readable, though I understand why it would look the opposite the very first time you see it (and without any syntax highlighting at that). Open up the source code for this web page: is it compact and readable? The answer seems to be that HTML is "good enough" in that regard, and I suspect CSTML will be the same especially as more developer tooling for it becomes available.

The problem is that I'm not talking about markup. Markup - unless it's so lightweight as to be near unnoticeable is not a solution. Unless every application you're transferring it via supports CSTML, the representation needs to be as compact and readable as a regular programming language.

To take your example, pretty much anything longer than [1, true, "3"] is a non-starter if someone is pasting it into Slack, or sending an e-mail. The CSTML representation isn't readable to them, and would take additional steps on both sides vs. just writing the source representation. I'm not going to tell people how to do something by writing it into some other tool and pasting some large blob into Slack or my e-mail client and expect the recipient to reverse the process.

That is the problem space. How you represent that as an AST isn't the problem - that's easy. How you represent it in a way that everyone can read and write and that "passes seamlessly" via existing tools is the problem.

(I must also admit that I think the choice of serialization format for CSTML is utterly baffling and feels like it adds a lot of NIH)

Re: Unit is a general purpose visual programming system

#79
post #76

Earlier quoted context omitted.

Right. I think it's already a solved problem though. HTML and the HTML DOM are a living solution to that exact problem. All that we have to do is take the patterns used to power general UI and develop a DOM for code.

The internal representation isn't the problem, or even a problem. It's not even beginning to address what I described. E.g this is a real line of code: link = wf["links"].find{ _1["rel"] == "self" && _1["type"] == "application/activity+json" } Now consider I have a visual programming version representing that expression, and I want to ask someones opinion about it on Slack. Unless your visual programming environment…

Your assumption is that visual programming and textual programming are disjoint, but I have not observed this to be true (necessarily). Being able to edit a program in a semantic fashion does not preclude its having syntax. I don't see syntax as a boondoggle to be eliminated, but rather the highest-bandwidth way we know how to convey information!

I think you're right that the end game of any successful attempt at standardization is integration with all those tools like Outlook, Slack, Discord, Signal, Word, Docs, Notion... The list goes on and on. It's strange how the presence or absence of political momentum behind a standard could change that from being "basically impossible" to "basically inevitable"

Re: Unit is a general purpose visual programming system

#80
post #78

Earlier quoted context omitted.

I personally think CSTML is both compact and readable, though I understand why it would look the opposite the very first time you see it (and without any syntax highlighting at that). Open up the source code for this web page: is it compact and readable? The answer seems to be that HTML is "good enough" in that regard, and I suspect CSTML will be the same especially as more developer tooling for it becomes available.

The problem is that I'm not talking about markup. Markup - unless it's so lightweight as to be near unnoticeable is not a solution. Unless every application you're transferring it via supports CSTML, the representation needs to be as compact and readable as a regular programming language . To take your example, pretty much anything longer than [1, true, "3"] is a non-starter if someone is pasting it into Slack, or se…

We're using markup to communicate right now and it's the overhead is small enough to be unnoticeable.

Try copy and pasting some HTML-formatted text from this page into your paste buffer.

I assure you that what goes into the buffer is HTML. You can verify this because if you paste the text into an HTML-embedding WYSIWYG editor (such as an HTML email composer) the formatting will be preserved. But if you paste the content of the same HTML buffer into VSCode, notice that you don't get the raw HTML but rather the textual content that was embedded in that HTML.

Post reply on HN