|
|
|
|
|
|
by gabigrin
840 days ago
|
|
|
This is something I ponder about a lot. For those proficient in writing textual programs, a tool such as Flyde as-is might provide value by enforcing modules to be stand-alone and well-defined; the premise of https://en.wikipedia.org/wiki/Flow-based_programming as a paradigm that promised value even without using a visual editor, and just by adhering to the concept. But for those who lack the understanding of coding syntax and grammar, a visual tool, even in a not-much-higher level of attraction, could make all the difference. I've personally mentored dozens of entry-level developers many struggled with concurrency and asynchronicity. (callbacks, promises, etc). these are concepts that become a no-brainer using a nodes-and-wires editor. Regarding prepping - fair point. I'm sure it's not what you meant, but here's a grep in a Flyde flow (the second example) - https://imgur.com/a/V9u1ETl |
|
|
Looking at flow-based programming, it looks like it could help in visualizing and understanding asynchronous systems that wouldn't be so intuitive from a code listing. In that way, I suppose it would force a functional style as well. So maybe good for gluing those parts of one's apps together.
I did look at the code examples; attributes and code wrapped in json. Obviously greppable, but then if one expected a learner to grep, version diff, author tests?, linting?, etc. they still must dip into and learn regular dev tools. I don't know if Flyde is supposed to eventually subsume that other functionality or if it is a higher scripting layer used in conjunction, and so must eventually be learned anyway.
Or is Flyde just trying to introduce an easier coding path in order to bypass the more superfluous parts of software dev such as tabs vs spaces, editor choice, oop vs functional vs procedural vs whatever.