d-cook / SomethingNew

Collaboration for reinventing software in human terms
167 stars 10 forks source link

Visual Programming Languages #31

Open ivanreese opened 5 years ago

ivanreese commented 5 years ago

Hello

I was just linked to this repo. It seems to be chock full of interesting ideas. I'm looking forward to exploring this repo and the things it points to. Thanks for putting this together in an open space.

I've created a similar a resource that might have some value for you. It's a collection of links to projects, articles, talks, papers, and other works on the subject of Visual Programming Languages, both modern and historical: https://github.com/ivanreese/visual-programming-codex

I'm pretty passionate about non-textual ways of arranging computation, so if there's anything you're aware of that fits that description, I'd love to be pointed at it.

🍻

vladimir-vg commented 5 years ago

This looks really good. Thank you very much for your work putting it in one place.

d-cook commented 5 years ago

Joel wrote a great satire essay on this topic: https://programmingmadecomplicated.wordpress.com/2017/10/29/introducing-drw-a-useful-tool-to-solve-a-practical-problem/

kahunamoore commented 5 years ago

Greetings Ivan, I’m @coopsource (Twitter handle), good to see you here.

I also have a bunch of articles and sundry content I should collate into a repo like you did. Thanks for the link. I have more reading to do.

The thing I’m struggling with atm is the tension between the power of abstraction and it’s ability to transcend the ephemeral nature of any given concrete representation and the intuitive immediacy and direct manipulation of a concrete representation.

It seems that the limitations of flatland UIs (flat displays) have hampered visual programming so far and is one of the reasons I think VR/XR holds a lot of promise for exploration. As I mentioned elsewhere, I’m just stumbling through the wilderness hoping to run across something useful but maybe having a discussion with others and studying priors can help avoid a lot of dead ends.

On the other hand there is sometimes a benefit to having a bit of blind ignorance and exploring paths that were previously discounted for reasons/limitations that are no longer applicable.

I’m open to suggestions from any/all on their thoughts on good ways forward.

ivanreese commented 5 years ago

Thanks for the warm welcome, gang!

@kahunamoore — Good to see you here.

The tradeoffs between abstraction and concretion, or indirect and direct manipulation, are a big part of what I find so compelling about visual programming languages. Have you been following Sean McDirmid? He's a font of great knowledge about this stuff.

I agree VPLs have been hampered, but I don't just point the blame at 2D displays. I think the problem is simpler: a lack of exploration of the visual programming idea-space (which — to be clear — also implies that exploring 3D VPLs is something that we should be doing).

I'm quite convinced that all the popular complaints about visual languages — hard to do abstractions, hard to work with large systems, hard to use with version control, hard to use with other programming tools, etc — are simply the result of nobody prioritizing that stuff when designing a VPL.

When I look at the shortcomings I see simple and obvious, if perhaps a bit challenging, ways to overcome them. And when I look at the research / hobbyist community, I see people trying those ideas and succeeding (thus, the codex). But I don't see people spreading those ideas the same way (eg) React spread the idea of unidirectional dataflow, and Clojure spread the idea of immutable data structures.

I think the path forward is this: Don't take it as a given that any current approach to VPLs is a dead end, or that we need a total paradigm shift. Instead, just pick a direction, check for any prior art that might give you a head start in that direction, and start exploring. There's so much long grass here, it's almost unfair.

greggman commented 5 years ago

I have very little experience with visual programming languages. My experience comes mostly from games where I find that VPLs as currently implemented are really only useful for very very small snippets of code. Setting up a flowchart for "if character has red key then open door" is easy but say programming a configuration screen or an RPG character creation screen where they use can choose a ton of options is a poor fit. Whether that's because the VPLs are not good enough or because VPLs only fit certain domains I have no idea.

As for abstraction though I thought I'd point out Virtools had the ability to make "functions". To take a bunch of VPL blocks and put them inside another block and have the stuff outside that block only interact with the public interface of the containing block.

I don't remember if it actually abstracted the block or not (as in if you could instance the block) or if it was just a way of collapsing a group of blocks to avoid clutter.

My own VPL did support abstraction but it was very hands on. You'd create an "Interface Block" which represented the public inputs and outputs. You'd add inputs and outputs to that InterfaceBlock and connect all your VPL blocks to send and receive from that block. You could then save off that set of blocks and instancate a copy of it in some other program where you'd see just one block with whatever inputs and outputs the "Interface Block" exposed.