It depends on what kind of problems you're solving. System integrations and ETL-type stuff where it's mostly data transformation and not too much logic are great for visual dataflow programming. It's a lot easier if you can have code-within-blocks and blocks-within-code, too.
Also, I suspect there's going to be a correlation between a preference for spatial vs. lexical reasoning and a preference for visual vs. textual development.
Yeah I agree, I originally built that block-code tool for data transformations and in that domain it is used in practice and very useful. But it's just configuration/queries, no unrestricted coding (the users were shooting their feet too much).
That sounds perfect. If you have a strongly-typed language to develop new blocks in, then surely simple "configuration" for the blocks is enough for visual programming.
I'm curious what graphical Rust would look like. The type/trait system seems powerful enough to prevent weird errors at Runtime, while still enabling wide usecases for example with `AsRef<str>` where any type implementing conversion to string can be used.
Also, I suspect there's going to be a correlation between a preference for spatial vs. lexical reasoning and a preference for visual vs. textual development.