I'm thinking about ways to represent/interact with a (computational) graph. I could come up with three different interfaces off the top of my head: 1) names/identifiers and application, 2) combinators/stack operations, and 3) boxes and wires. I'm curious to know if y'all can think of any other?

i'm heavily invested (both in effort and ideologically) in boxes and wires so I'll take door 3, but it must be live/reactive/flow node & wire with embedded output previews one issue is that the expressive power of the visual programming is only as good as your primitives -- so one of the boxes should be a "get outta jail free" box that embeds other more expressive albeit more arcane paradigms (code, structured editors, etc.) and as long as the blocks are purely functional, in/out, maintain and display state, it's the computational tool-for-thought of choice for me

Interesting. I have a sort of long-standing feud with boxes and wires, so I'm actually quite curious to know more about your investment in that paradigm. What have you used it for, why do you like it? One of my biggest beef with those systems is that I find them often quite cumbersome to write and edit in, compared to the speed I can have by typing code. I also find them often low in information density, and complex code can get very difficult to understand. I'm very curious to hear your thoughts on that, if you'd be inclined to share them.

@Xavier Lambein I am not sure I understand exactly what you mean by "interactin with a computational graph", but I wonder how (term | graph) rewriting fits into your scheme. What you interact with is a set or list of rules and an algebra of terms or graphs. @Arvind Thyagarajan That's my pet peeve with box-and-wire approaches. They don't scale to complex graph, so you need to be able to zoom in and out, which is something I haven't seen yet in real implementations.

Essentially what I mean is "read/write programs", I guess, but I was trying to avoid this specific framing because I find it potentially restrictive.

Agreed, @Xavier Lambein @Konrad Hinsen I share a lot of the feuds with the nodegraph way, but I'd like to sort them out. I've now used boxes-n-wires for everything from building... igh... "apps" for business (simple rich form submissions to connecting diverse legacy system into a simple mobile get-things-done tool) and personal use (habit tracker, medication tracker, travel tracker... small software), to getting at least into day 10 of Advent of Code (i.e. use it as a computationally powerful thinking surface) I do not come to the table with the deep experiences & assumptions of a textual programmer -- those who code textually are definitely faster, but code has just 1.5 dimensions (linear lines of code + structural hinting) and I don't find that as ready-to-hand as I'd like at all. However programmers today would find a new nodegraph based visual coding surface quite present-at-hand I'd imagine. To address the complexity peeve (you now have a wonderful 2.X dimensions of information) my answer has been two-fold: "components" & "live previews"; • "components" -- you can collapse a sub-graph into a pure function (re-usable) component that has its own in/out interface -- once you're done thinking through a functional portion of the graph, you can group/collapse it, give it an interface, annotate it for understanding, and you've greatly simplified your graph. So for now "zooming in" is actually "drilling in." • "live preview" -- your box is not just a box, it's a small live/reaactive preview of what it does, either showing the state of computation or the final computed output; your wire is not just a wire, it highlights to show flow, lighting up the next box as downstream state updates propagate through It's quite beautiful in practice :-) nb: all that being said, the most complex graphs do become hairnets, spaghetti, and detritus -- but so can text, and one answer is good mise-en-place

@Xavier Lambein Yes, rewriting is the execution phase. The equivalent of a program is a set of rules which has in general no structure at all. A graph with no edges. Some rewriting technique add a partial order to the set, but that is just for convenience.

> components Sounds a bit like the "good practices" around coding in a pure functional language, where it's frowned upon to write very long functions because they're way less readable. This means a good boxes-n-wires programming environment should make it seamless to abstract things into components and inline them back 🤔 > live preview Definitely a big selling point of such systems, I do love that about them!

What do you use in your current day job @Xavier Lambein?

Data scientists & previous devs built a massive model in KNIME, which is an absolute pain to use and maintain

@Xavier Lambein Rules are selected by pattern matching. The rewriting engine provides an outer loop executing a giant switch/case/... statement. It stops when no rules are applicable, i.e. no pattern matches the current term/graph.

Ahh right, I see! Thank you that made it clear for me 🙂

@Xavier Lambein though I have to admit I've never tried it myself for the data science domain, check out this demo and walkthrough of enso, a visual prog lang for data transformation and visualisation: (once in the weeds, I don't know if they've addressed any of the peeves we've discussed above, it doesn't seem like they have the notion of collapsing into components for example...)

Thanks! I'm not really looking for a data science solution though, I'm asking about this for a side-project, nothing to do with my work. I'm working on a programming environment and I'm trying to explore the design space a little 🙂 So I'm interested in your recommendations for boxes-n-wires systems that you've used, regardless of the domain of application. That being said Enso looks really cool 🤔