The tone of the article sounds preemptively dismissive of the visual programming paradigm itself using deficiencies of its implementations. This is like saying OOP is deficient because a language implements it in a bad way. As with text-based programming, visual tooling varies in quality.
Several existing visual tools address the issues the author raises (diff support, searching, modularity etc.). Further, saying that visual tools are not Googleable or have enough following on StackOverflow is a Catch-22 situation. It won't improve until people start using and improving the tooling.
The same applies for other points the author makes. For example, I would argue the lack of open-source visual programming tools is more due to the lack of adoption stemming from FUD than it is from lack of interest in the paradigm itself.
Generalizing what is essentially the state of infrastructure to an entire paradigm (visual logic authoring) doesn't convey the full picture.
can you provide some links for visual diffing tools? 90% of the programs I write are PLC programs in the IEC 61131 function block language. I would love to be able to diff and merge.
PLC processors have come down so much in cost we have gone to a modular architecture where we have multiple CPUs in a plant each running an independent machine or part of the plant process partly so that one programmer can work on the program for 1 CPU without having to merge another programmer's changes.
I thought I might be able to get this open source PLC programming software which includes a function block renderer to read the unity XML program exports and then I could render the function block sections myself and diff them: http://www.beremiz.org/doc
Here is the only real product I've ever seen which has a module for matlab simulink diffing: https://www.diffplug.com/
Schneider does have the UnityDiff tool which has come a long way in the last couple years and it does pretty decent diffs but there is no way to generate them automatically that I know of. I have to open both versions of the program I want to diff and then run the diffing tool. Then the visual diff output can't be exported out of the unitydiff program. printing doesn't work. I should make some feature requests.
I think this really is the core insight behind visual tooling. I'm currently working on Coati, a source explorer for C/C++, which does exactly that. By building a visual representation on top of a textual syntax, you can leverage the advantages of both.
In actuality, text is a visual representation. Code is text, what he means is the abstract.
Text mandates a layout that most have at least some experience, but because it's sequential it doesn't map as well to problems in more yet few dimensions. Good graphical layout in contrast is almost a niche skill, just like project layout, architecture (3D) or and software architecture and engineering in more than three dimensions.
My problem with such tools as that it always looks nice on toy examples but when faced with some real-life complexity the source seems always way more clear and faster to navigate.
Naturally, you can't get rid of reading source code, that's where all the information is. But the visual representation can speed up navigation and understanding a lot. Having worked with the visual navigation of Coati for while now, I can tell you that it changed the way I develop software. Seeing at a glance which classes derive from an interface or where and how often a function is called gives you a whole new perspective on your codebase.
> At some point in their careers, almost every data scientist has written code to perform a series of steps, and thought, “It would be great if I could build these transformations visually rather than by writing code.”
I have been in a data science career for nearly six years, now, and I have never thought this. Not once. Further, I don't know of a single colleague or associate who has thought such a thing.
I've been in one for just slightly longer, and I absolutely adore visual tools (SSIS). My coworker despises them. We are similarly experienced and similarly productive.
After some discussion, the difference seems to stem from our own mental design patterns. When I design and visualise a data process, I literally draw and diagram on paper in the same way that a visual tool represents it. His own prototyping is notes in the form of pseudocode.
Don't underestimate the human equation at work here. This debate might not ever be 'solved'.
This may be controversial, but I completely agree. Let's say 7 - 10 years experience here myself.
You know who has said that? Management and marketers and it's driving me batty. A paradigm is being pushed on us, and I'm sorry, but the most productive members have always been coders and the best solutions/implementations in my experience have always been coders.
Now what I have got a lot of experience in its going in and fixing/refactoring solutions written in point and click out derived from copy/pasting templates.
I'm not saying no visualisation or visual coding, our that maybe there isn't a field or context where it works or could be better. I'm open to new experiences and techniques.
But my experience so far is otherwise in this case. And I know this goes against the executive and startup propaganda, since every man and his dog is trying to sell yet another point-click drag-drop visual analytics solution, and every executive seems to want the "do analytics without having to have skilled labor or actual knowledge of analytics", but let's just say I'll risk it to make the comment...
I have worked most of the time in traditional (text based) languages, but I have also a non-trivial experience with a tool which is mostly visual (Software AG webMethods - here is an example of how it "looks": https://webmethodsexpert.files.wordpress.com/2015/07/try-fin...).
I suspect that unless you had most of your experience in a visual environment, you will never be able to work at the same level of efficiency that you have after a much shorter exposure to a text-based code.
This is also due, again in my own opinion, to the fact that while code has been text-based for 60+ years now, and millions of people have worked with that (and reinvested into the paradigm, and came up with new and better, clearer, more concise ways to do things IN TEXT) every attempt to work with a visual language never made much inroad outside of academia and/or games.
I have good memories from an UML design tool that generated Java stub code and kept in sync with code changes.
3D CAD is really great and works well.
WYSIWYG editors often work for 95% of the use cases.
For several domain specific niches there are already visual designing tools that work great. Having a text representation in the background is often a plus, so that some edge cases can be solved.
Several existing visual tools address the issues the author raises (diff support, searching, modularity etc.). Further, saying that visual tools are not Googleable or have enough following on StackOverflow is a Catch-22 situation. It won't improve until people start using and improving the tooling.
The same applies for other points the author makes. For example, I would argue the lack of open-source visual programming tools is more due to the lack of adoption stemming from FUD than it is from lack of interest in the paradigm itself.
Generalizing what is essentially the state of infrastructure to an entire paradigm (visual logic authoring) doesn't convey the full picture.