3 ms·

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

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 5y ago
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 5y ago
  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 5y ago
    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 5y ago
How about writing code and then looking at it through blocks? That might be superior, if done right.
- emteycz 5y ago
  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.

nitrogen 5y ago

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 5y ago
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 5y ago
  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 5y ago

How about writing code and then looking at it through blocks? That might be superior, if done right.

emteycz 5y ago
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.