I've had to use a number of visual programming tools and I never truly appreciated this argument until I had to deal with all of the trade-offs.
Most visual tools handle version control poorly. Refactoring and reuse is a joke. They often require a lot more work to do simple things that can otherwise be expressed with a simple expression.
What I do like about this article is how the author shows many different projections of code and I think that's really the key. I personally think before we try to tackle the difficult problem of building a visual editor, a better problem to solve would be projecting code that's written in a simple text editor into different graphical formats.
There are a few challenges with that because turning existing languages into visual representations is a challenge itself. One can imagine the challenges of projecting a function in your code base into a graphical representation.
Let's say you wanted to project a class's method to a sequence diagram. In order to keep your diagram clean, you'll want to display and emphasize method calls to external services and elide local method calls, which aren't so relevant in your diagram. How do you solve that? Do you require the programmer to annotate the various aspects of their code? Do you assume some sort of convention? That might work with green field projects, what about existing code that already violates conventions? What if you want to have different projections of the same code? Do you litter your code with annotations?
The key point is different diagrams communicate and emphasize some things often at the expense of other things, and automatically figuring out what needs to be communicated is hard for humans, let alone tools.
Personally, I'd be interested in a set of DSLs that would not only project the different aspects of your program, but would work together to verify the correctness of your program. You might have a simple predicate DSL you'd use to describe what invariant conditions must always hold. Maybe you'd have a DSLs to describe how services communicate with each other.
I would really like to see people who are researching visual programming to take these issues seriously and not discount the value of text. There's not one reason why text prevails, there are many reasons. If that's not convincing, consider The Lindy Effect which suggests that the future life-expectancy of a technology tends to be proportional to it's current age. In other words, if something has dominated for 50 years, knowing nothing else, it's likely to continue to dominate. Forks, chopsticks and wheels are elegant solutions that have been around for thousands of years. I'm not saying text is the same, but I feel like a lot of people (not all) working the on visual programming tend to underestimate text.
Most visual tools handle version control poorly. Refactoring and reuse is a joke. They often require a lot more work to do simple things that can otherwise be expressed with a simple expression.
What I do like about this article is how the author shows many different projections of code and I think that's really the key. I personally think before we try to tackle the difficult problem of building a visual editor, a better problem to solve would be projecting code that's written in a simple text editor into different graphical formats.
There are a few challenges with that because turning existing languages into visual representations is a challenge itself. One can imagine the challenges of projecting a function in your code base into a graphical representation.
Let's say you wanted to project a class's method to a sequence diagram. In order to keep your diagram clean, you'll want to display and emphasize method calls to external services and elide local method calls, which aren't so relevant in your diagram. How do you solve that? Do you require the programmer to annotate the various aspects of their code? Do you assume some sort of convention? That might work with green field projects, what about existing code that already violates conventions? What if you want to have different projections of the same code? Do you litter your code with annotations?
The key point is different diagrams communicate and emphasize some things often at the expense of other things, and automatically figuring out what needs to be communicated is hard for humans, let alone tools.
Personally, I'd be interested in a set of DSLs that would not only project the different aspects of your program, but would work together to verify the correctness of your program. You might have a simple predicate DSL you'd use to describe what invariant conditions must always hold. Maybe you'd have a DSLs to describe how services communicate with each other.
I would really like to see people who are researching visual programming to take these issues seriously and not discount the value of text. There's not one reason why text prevails, there are many reasons. If that's not convincing, consider The Lindy Effect which suggests that the future life-expectancy of a technology tends to be proportional to it's current age. In other words, if something has dominated for 50 years, knowing nothing else, it's likely to continue to dominate. Forks, chopsticks and wheels are elegant solutions that have been around for thousands of years. I'm not saying text is the same, but I feel like a lot of people (not all) working the on visual programming tend to underestimate text.