What is the state of the art in graphical (nodes and edges) programming? Anything general purpose? Or is this limited to a few domains?

I'm working on a project in this area. It's ostensibly general purpose, but it's best at a few domains (animation and music). I've also put together this collection that you may find helpful: ivanish.ca/codex

✋🏻 Working on Flowcode here. Very early stage, so there isn’t much there yet in terms of documentation, intros, blog posts, but a working prototype is available at flowcode.kwaia.com.

@Ivan Reese "_insincerely graphical"_ nice!

@tbabb is working on a general purpose node-based visual programming language: https://lynxtool.com/

Yeah, Lynx looks very interesting. Really good design thinking there.

@yaxu I take "general purpose" to mean it is used in multiple disparate domains by more than one community. No language is best for all domains. Python is general purpose without being a low-level systems language. There are many domain-specific languages that are Turing-complete, and powerful enough to be used outside their domain, but probably never will be. (Like my language Curv.) Are these languages general purpose? At best they are aspirationally general purpose.

What are the ways (if any) visual languages show recursion? Have any done recursion over time in the FRP sense (precisely defining the future of values in terms of the current value of other values)? Steve's paper is a good illustration of why that's useful: https://2018.splashcon.org/details/rebls-2018-papers/7/Explicitly-Comprehensible-Functional-Reactive-Programming

@Doug Moen A fair point but I've seen Max/MSP applied to a range of domains, e.g. analysing EEG data, audio synthesis, mapping sensors to actuators to make live interfaces.. all involving working with signals/data flows, but applied to a variety of domains. I think it's somewhere between domain-specific and general purpose.

@yaxu it's difficult to write patches about patches in Max/MSP

Reminds me of the previous discussion about "visual" vs "linguistic" thinking. Linguistic thinking emphasizes words, syntax, hierarchy, while visual thinking emphasizes images, shape/texture/colour, spacial relationships, and part/whole relationships. I've thought about how to turn my project Curv from a text based to a visual language, and that's one direction. I also thought about recasting Curv as a term-rewrite system, so that programs can be manipulated as data, so that more of the Curv system can be written in Curv. But that latter idea moves Curv even farther into the realm of linguistic representation. It's challenging to reconcile that with redesigning Curv as a visual language, where 2D layout and spacial relationships are the primary organizing principle, and rich, non-linear visual imagery replaces words as the means of signifying concepts. How does pattern matching work in a visual language?

> programs can be manipulated as data > How does pattern matching work in a visual language? In Lynx, all data, including functions, are passed through wires to the call sites that work on them. Basically, it's straight-up functional programming with a loose equivalence between "variables" and "wires". There isn't really a need for pattern matching. Basically it looks like this:

@tbabb What you show above is good for writing functions over scalar values. Pattern matching is useful for decomposing data structures. Lynx has lists. I assume there is a general N-list constructor: N wires in, 1 wire out. An N-list pattern would be the reverse: 1 wire in, N wires out.

@Doug Moen I don't (currently) opt for lisp's homoiconicity approach—

list

is its own data type distinct from expressions (though that's not necessarily set in stone). So there will be natural functions over lists (append, reverse, extract, ...), and functions over functions (map, apply, reduce, ...); and eventually introspection functions on functions, which will probably work like graph-walking ops. But a list/tree/struct/etc. can flow through those wires just as easily as a scalar. In the above diagrams, there are already wires carrying functions to their application sites.

@Doug Moen @Adriaan Leijnse There are a number of visual languages based on Haskell that represent recursive functions and pattern matching: Visual Haskell (chapter four of https://ptolemy.berkeley.edu/~johnr/papers/pdf/thesis.pdf), Viskell (https://github.com/viskell/viskell/blob/master/viskell-nlfpday.pdf), and Glance (https://github.com/rgleichman/glance). Glance can have recursive unnamed functions (lambdas), I'm not sure if that's possible in the other visual languages.

Thanks for the suggestions @Robbie Gleichman!