[emteycz]

Not really... I built a block-based IDE like that which compiled to TypeScript/React (you could switch to writing code and back to blocks at any time)... And I just never used it, writing code was much faster, even though it supported custom "macro" blocks and other new ways of making programs.

[nitrogen]

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.

[emteycz]

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).

[southerntofu]

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.

[hutzlibu]

How about writing code and then looking at it through blocks?

That might be superior, if done right.

[emteycz]

In my case, it took much longer to convert the program from what I am seeing into a in-head representation. Perhaps I am just too used to textual code, but I really tried to do it another way... Or perhaps it's simply not for me, but others might be happy.