4 ms·

I think that's more of an indictment on the specific environment/software you used than visual programming in general. One could argue thinking in terms of clas

I think that's more of an indictment on the specific environment/software you used than visual programming in general. One could argue thinking in terms of classes is invalid. Visual programming has value at a higher level of abstraction e.g. workflow management/stitching of components.

wvenable 8y ago
I used class as an example but the product was for workflow management and stitching of components and it was, frankly, ridiculous. Nothing was wrong with the product itself, it was sound. But the entire concept of representing working software visually that is unmanageable. Honestly people can read and process text much easier then they can follow active visual nodes and lines. And I'm not talking about an abstract diagram; we are talking about visually designing something detailed enough to be executable. I think most people imagine visual programming based on pretty high-level abstractions but that's not the reality of programming. Anything even moderately complex is too big to see all at once but could easily fit on a few screens of text. Making changes is even worse. I can easily move to the top of this paragraph and add another paragraph (which I just did). Have you ever tried moving around 20 visual nodes? Almost impossible to do easily. I just re-wrote a few sentences; easily 6 clicks and typing in a visual environment.
- wires 8y ago
  You are talking about deficits in the tools to work with graphical representations and lack of language support to contain behaviour to a single box (like a decent type system and separation of effects from pure computation) I am the first person to admit that visual programming goes wrong about 95% of the time, but it doesn't have to... also nobody is expecting everyone to swap out their tools for statebox haha

4 ms·

I think that's more of an indictment on the specific environment/software you used than visual programming in general. One could argue thinking in terms of clas

by kodablah 8y ago

wvenable 8y ago
I used class as an example but the product was for workflow management and stitching of components and it was, frankly, ridiculous. Nothing was wrong with the product itself, it was sound. But the entire concept of representing working software visually that is unmanageable. Honestly people can read and process text much easier then they can follow active visual nodes and lines. And I'm not talking about an abstract diagram; we are talking about visually designing something detailed enough to be executable. I think most people imagine visual programming based on pretty high-level abstractions but that's not the reality of programming. Anything even moderately complex is too big to see all at once but could easily fit on a few screens of text. Making changes is even worse. I can easily move to the top of this paragraph and add another paragraph (which I just did). Have you ever tried moving around 20 visual nodes? Almost impossible to do easily. I just re-wrote a few sentences; easily 6 clicks and typing in a visual environment.
- wires 8y ago
  You are talking about deficits in the tools to work with graphical representations and lack of language support to contain behaviour to a single box (like a decent type system and separation of effects from pure computation) I am the first person to admit that visual programming goes wrong about 95% of the time, but it doesn't have to... also nobody is expecting everyone to swap out their tools for statebox haha