3 ms·

It might not suck, but the cost benefit analysis ends up washing out any value it might have. Text is glorious and portable. I can run emacs in a terminal. I n

It might not suck, but the cost benefit analysis ends up washing out any value it might have. Text is glorious and portable. I can run emacs in a terminal. I need a software stack just to look at my code like I need a hole in my head. The thing I really hate about visual programming is that programs are fundamentally tree structured and 2d space introduces extra degrees of freedom which, for me, impose additional cognitive load.

ModernMech 8y ago
> the cost benefit analysis ends up washing out any value it might have. For you, apparently yea, but for others maybe not. We don't all value the same things. Visual languages are especially friendly toward new and young learners of programming. > programs are fundamentally tree structured and 2d space introduces extra degrees of freedom which, for me, impose additional cognitive load. Interesting, you say this, because I draw most trees in 2d, whereas text is a 1d list of statements. To me, a 2d space better maps to the programs I tend to build.
mbrock 8y ago
Christopher Alexander (the architect) wrote a paper called A City Is Not A Tree. I don't know of any paper called A Program Is Not A Tree, but one could be written. Programs are fundamentally messy tangles of references, as far as I can tell! Compile-time structures are utterly different from run-time structures. Some languages have both dynamic and lexical scoping. Etc.
- beaconstudios 8y ago
  you can reduce an individual function to a a directed graph (not a tree). But once you have more than one function? That's graphs referencing graphs. That definitely doesn't reduce to a tree. The only parts of a program that reduce to a tree are incidental to their functionality - the nesting-block structure of procedural, C-derived languages, and the tree structure of a filesystem.
steego 8y ago
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.

ModernMech 8y ago

> the cost benefit analysis ends up washing out any value it might have. For you, apparently yea, but for others maybe not. We don't all value the same things. Visual languages are especially friendly toward new and young learners of programming. > programs are fundamentally tree structured and 2d space introduces extra degrees of freedom which, for me, impose additional cognitive load. Interesting, you say this, because I draw most trees in 2d, whereas text is a 1d list of statements. To me, a 2d space better maps to the programs I tend to build.

mbrock 8y ago

Christopher Alexander (the architect) wrote a paper called A City Is Not A Tree. I don't know of any paper called A Program Is Not A Tree, but one could be written. Programs are fundamentally messy tangles of references, as far as I can tell! Compile-time structures are utterly different from run-time structures. Some languages have both dynamic and lexical scoping. Etc.

beaconstudios 8y ago
you can reduce an individual function to a a directed graph (not a tree). But once you have more than one function? That's graphs referencing graphs. That definitely doesn't reduce to a tree. The only parts of a program that reduce to a tree are incidental to their functionality - the nesting-block structure of procedural, C-derived languages, and the tree structure of a filesystem.

steego 8y ago

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.