Hacker News Reader

Comment by zadwang | Hacker News Reader

This actually should be the way codes are written. This is how we reason about codes in our minds.

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.

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.

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

That might be superior, if done right.

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.

Reply on news.ycombinator.com