Beyond that, my best advice would be to just hang out on this Slack for a while. A lot of the big, useful ideas come up again and again as we explore them in different ways and with different perspectives (and as new people come in and ask about "the same old things" in slightly different ways, sparking a new round of debate).

The hard thing about doing a high-level summary (on, say, some web page) is that for most of the promising directions, the devil is in the details. What I've found is that knowing the current thinking around a certain topic isn't helpful (though it is interesting) unless I also know what foundational ideas those current thoughts are resting upon. You need to know the giant to stand on its shoulders.

This github collection by @Daniel Garcia might be helpful: https://github.com/pel-daniel/mind-bicycles

If there's a specific topic or idea or broad category you're interested in, I'd recommend making a new post on #C5T9GPWFL saying "People interested in ______, please tell me what current ideas you find exciting"

Examples to fill in that blank: projectional editing / structural editing, node-and-wire visual programming languages, visual programming languages (that aren't node-and-wire), spreadsheet-inspired UIs, literate editors, program visualization, direct manipulation abstractions, text / code editors, Smalltalk-inspired languages, VR programming environments (etc)

This episode is also pretty relevant: http://twitter.com/spiralganglion/status/1035001118936330240

To flip it around: what about the UI side of programming do you find interesting?

i’m trying to work out (very slowly) a way of structuring/designing a kind of federated social wiki for this topic as i feel like its a major blocker for people entering the community

Ivan, thanks for visual-programming-codex. This is a great resource.

@Ivan Reese Is there a reason there’s no entry for HyperCard?

I don't really have a sharp line on that stuff, so if you feel IB really fits in with this collection, I'll gladly take your word on it. (I haven't used IB so I'm only categorizing it based on what I've seen of it)

Yeah, I think this question of classification actually gets to the heart of the problem with VP

What is programming? What does it mean for it to be visual? Certainly, IB is replacing the typical fragile and ugly boilerplate UI code with something that is simple and visual.

But it wasn’t really a live environment. It didn’t remove the edit/compile/run cycle, but I’d guess many of these examples also aren’t live.

I throw "bespoke" in there because I'm looking for things that could have some generality to them. Again, trying to avoid including things like 3d modelling, and VST synthesizers with patcher interfaces.

(They're worth studying, don't get me wrong. But they generally aren't created by someone with the goal of being a general purpose programming tool.)

Tools like Apparatus aren't general purpose, either, and I'll probably eventually pull them out into a separate category — tools created to explore interface ideas that could be made into a general purpose programming interface, but haven't been yet.

So that might be a better definition — visual programming tools are tools for which the author specifically claimed that they were making a programming tool (rather than just a music tool or just an art tool, even though music tools and art tools are absolutely programming tools, too)

So the NeXT Interface Builder is interesting not because it’s visual per se, but because of how much more productive it is. It happens to make the UI building part more productive through directness - visually manipulating the visual UI. But there are other things where doing something “visually” would be less direct and less productive than a text (structured or otherwise) interface.

DM is part of it, but I think chasing DM itself is actually a distraction. DM will emerge naturally as the result of satisfying other goals.

Text is more optimal for a wide range of things, absolutely. I see a lot of value, though, in defining "visual programming" as oppositional to text, since it pushes you further away from well-explored territory. Yeah, it does mean you miss out on a lot of interesting hybrids, or environments where you have visual extensions to traditional text code (eg: notebook interfaces with inline graphs and widgets). But after exploring a lot of that stuff, I've found it doesn't change how it feels to write code. You're still working in an environment where the mechanical thing you do with your body is type characters into a document, and the thing you do with your mind is imagine what that text does as it executes, and there's no knob that you can turn to control the passage of time (other than undo/redo, but that doesn't touch the execution model in most environments).

A great visual programming tool will have lots of text in it, of course, because text is a great medium. But (I believe) that text will sit inside an environment and execution model that were designed to afford things that simply make no sense if text is the primary medium, or if text is the outer bound / conceptual foundation.

My experience on that is: I used to play with Max/MSP some time ago. If I recall correctly, on of my project was for some kind of midi/OSC conversion or processing. The box and arrow visual programming was very practical for some points (say for the events routing part) but I felt frustrated when I wanted to do some basic data manipulation where box and arrow would lead to awfull spaghetti code and I felt that I can be very more productive with a text language. Fortunately, Max/MSP has a way to use JavaScript! And I coded some stuff with it. The bad part is that I had to open a code external code editor to modify the code...

So, from the productivity point of view, both visual and text programming were usefull in that case. And the limitation of the visually metaphor of the visual language at hand (Max/MSP) can be bypassed with the help of a text language that is more expressive.

So, I think that until some very mature visual representations can be found (and maybe after that too), it is a good point to have a mix of visual and text programming in a same environnement.

And several years ago I have done some small experiments on this visual/text combination with the PureData/MaxMSP kind of visual metaphor.

Here are some examples:

The point was really to experiment on how to mix both visual and text. I didn't focus to much on the visual metaphor (wich is directly inspired by PureDat/MaxMSP).