I think the truth is somewhere in the middle. Look at complex CAD systems and editors. They focused on the visual side and still provide some kind of command line for scripting the things. Even in pure visual programming systems like PD you can type algebraic expressions in textual form. And in text-based systems you may have lots of 2d tables (Smalltalk), graphs of modules, semantic colors (colorForth) etc.
Imagine GUI editor where the user can type the code on the left side and also can move and edit widgets with cursor on the right side. And editing of both sides is working in live mode. My point is that we need to have the best of both worlds to be really productive.
Totally agree.
I think the major reason visual programming sucks is exactly because some things which are simple to do using text-based programming become way harder when all you can do is drag graphs around.
On the other hand, some things are easier and more intuitive when represented and manipulated visually using graphs or trees.
I think that a visual programming environment which would be an extension of a text-based programming environment, in that you could do everything that you can do in IDEs everybody is already used to PLUS the cool stuff you can do with visual programming, would have high chances of not sucking.
> Imagine GUI editor where the user can type the code on the left side and also can move and edit widgets with cursor on the right side. And editing of both sides is working in live mode. My point is that we need to have the best of both worlds to be really productive.
I made a hybrid visual and text programming language and prototype development environment for it as a project for my master's thesis [0].
The main idea was very similar to what you are imagining. Textual code on the left side and visual representation on the right [1]. You can edit one and have the changes reflected dynamically in the other.
Actually my idea was even more general and could be extended to parallel-editing multiple representation of the same syntax tree.
I would love have the time to explore this stuff some more.
I agree on this point, the best solution is probably a visual editor that convert code to graphs an visa versa (while really working in code internally).
Then users can switch when needed.
Also it will help explore/understand what is required to write and effective base/methods/approaches for visual programming.
If we need code (in form of text) anyway, then why even spend time on learning visual representation of the same concepts? Such learning is pricy and increases cognitive load on developer without meaningful increase in productivity.
Visual programming still may make sense in some narrow niche tasks though.
For web apps, this is possible using Chrome and the style editor. Very effective way of live editing visual styles. Functionality is a different beast though
Imagine GUI editor where the user can type the code on the left side and also can move and edit widgets with cursor on the right side. And editing of both sides is working in live mode. My point is that we need to have the best of both worlds to be really productive.