4 ms·

This is very true. The idea of visual programming has been around forever and there is nothing wrong with it inherently. It certainly hasn't quite delivered as

This is very true. The idea of visual programming has been around forever and there is nothing wrong with it inherently. It certainly hasn't quite delivered as expected. But even established visual programming environments (e.g. LabView) are a skill itself now.

vegabook 11y ago
While I agree with you on visual programming, I think another issue raises itself: we are used to linear text editors - write one line after another - because they fit the way the computer works. Even breaking code down hierarchically as we do (functions, modules) still breaks a linear process into many linear processes. Yet increasingly as problems become more asynchronous / parallel, I sometimes wish for a more sophisticated code-creation paradigm, one where, for example, there would be some kind of two dimensional or even multidimensional visual representation of the logic of the program (even if those were each composed of linear text blocks). It's always possible to represent multiple dimensions in a lower-dimensional medium, but it becomes harder to conceptualize. So we have code folding tools, we have NERDTree etc to help us manage all the blocks, but sometimes I wonder if I could have some kind of multidimensional VIM that would allow the visual structure of my code more directly to map to the logic flow. I have taken to coding on a 4k 40 inch monitor (highly recommended - the BDM4065UC from Philips is so good I bought two) because it allows to me see so much more of my code and the way the flow will jump around, to have it all in front of my eyes kinda thing, and I wonder if it would be even better to add some visual tools in there to do conditional flow control.
- flowerpot 11y ago
  Couldn't agree more. Code is highly dimensional while our text editors are two dimensional at best. In case you don't know these talks I think you will enjoy The Future of Programming and Inventing on Principle both by Bret Victor.
- RyanZAG 11y ago
  Not sure about this. If we're writing a scientific study with nothing to do with computers, we still use the standard "write one line after another" to describe the processes and methods we use. Sequential lists and trees may be a natural property of our reality in the same way gravity is? As you say, when problems become more complex it becomes more difficult to reason about when dealing with a linear flow. But as with writing a report, the key is in the layout. The solution to a problem like that may be simply defining your abstractions better in your code so that each logical block is contained and understandable -- the same as with a section in a report. Basically it's the age-old programming logic: instead of having large chunks of code where you have to reason through complex logic, create abstractions so that the complex flow is defined in an obvious way. There will still be complex pieces, but they can be pushed to leaf nodes in other classes/files and can be backed by formal algorithms with logical proofs. So, well, standard best practices from the 1960s and still standard best practices today. Why? Because it seems to fit with the laws of reality.
  - vegabook 11y ago
    have to say - am not sure about it either! I'm simply intrigued by the question, namely, why do we still use linear tools for multidimensional problems? I think you have posited an excellent answer in that it's basically intrinsic to how we think and manage complexity, not only in CS.
Twisell 11y ago
Even in high level graphical "magical" interface like Tableau software visual BI tools, the real power come with the small scripting part you can put on some specific places. When I show my work people go crazy like "wohooo I need this magical too so I can do it too!". Then they ask to modify a pretty straigforward measurement, so I open the calculation script in front of them... they got scared as hell and suddenly think I'm some sort of wizard. Being allergic to code is a pathology for someone who work in IT, don't get it wrong kids!
lordnacho 11y ago
The closest I've come to visual programming is various UI designers and a couple of DB designers. They work OK up to a point, but as soon as you're doing something complicated you have a mass of arrows crisscrossing the surface. I think the problem is a visual designer is only a reasonable organising principle for 2D problems. You can get a nice global view. As soon as you need more dimensions, you might as well use something where the connections are only locally visible. By that I mean eg in a complex codebase, you can only see a few incoming/outgoing connections depending on where you're looking. A codebase can be arbitrarily complex, so chances are on any problem that isn't quite small, you aren't going to be able to represent it nicely in 2D.
dennisgorelik 11y ago
> nothing wrong with it inherently 1) Code diffs are pathetic with visual programming. 2) Sharing code examples is very limited with visual programming. 3) Full-text search capabilities are pathetic with visual programming.

vegabook 11y ago

While I agree with you on visual programming, I think another issue raises itself: we are used to linear text editors - write one line after another - because they fit the way the computer works. Even breaking code down hierarchically as we do (functions, modules) still breaks a linear process into many linear processes. Yet increasingly as problems become more asynchronous / parallel, I sometimes wish for a more sophisticated code-creation paradigm, one where, for example, there would be some kind of two dimensional or even multidimensional visual representation of the logic of the program (even if those were each composed of linear text blocks). It's always possible to represent multiple dimensions in a lower-dimensional medium, but it becomes harder to conceptualize. So we have code folding tools, we have NERDTree etc to help us manage all the blocks, but sometimes I wonder if I could have some kind of multidimensional VIM that would allow the visual structure of my code more directly to map to the logic flow. I have taken to coding on a 4k 40 inch monitor (highly recommended - the BDM4065UC from Philips is so good I bought two) because it allows to me see so much more of my code and the way the flow will jump around, to have it all in front of my eyes kinda thing, and I wonder if it would be even better to add some visual tools in there to do conditional flow control.

flowerpot 11y ago
Couldn't agree more. Code is highly dimensional while our text editors are two dimensional at best. In case you don't know these talks I think you will enjoy The Future of Programming and Inventing on Principle both by Bret Victor.
RyanZAG 11y ago
Not sure about this. If we're writing a scientific study with nothing to do with computers, we still use the standard "write one line after another" to describe the processes and methods we use. Sequential lists and trees may be a natural property of our reality in the same way gravity is? As you say, when problems become more complex it becomes more difficult to reason about when dealing with a linear flow. But as with writing a report, the key is in the layout. The solution to a problem like that may be simply defining your abstractions better in your code so that each logical block is contained and understandable -- the same as with a section in a report. Basically it's the age-old programming logic: instead of having large chunks of code where you have to reason through complex logic, create abstractions so that the complex flow is defined in an obvious way. There will still be complex pieces, but they can be pushed to leaf nodes in other classes/files and can be backed by formal algorithms with logical proofs. So, well, standard best practices from the 1960s and still standard best practices today. Why? Because it seems to fit with the laws of reality.
- vegabook 11y ago
  have to say - am not sure about it either! I'm simply intrigued by the question, namely, why do we still use linear tools for multidimensional problems? I think you have posited an excellent answer in that it's basically intrinsic to how we think and manage complexity, not only in CS.

Twisell 11y ago

Even in high level graphical "magical" interface like Tableau software visual BI tools, the real power come with the small scripting part you can put on some specific places. When I show my work people go crazy like "wohooo I need this magical too so I can do it too!". Then they ask to modify a pretty straigforward measurement, so I open the calculation script in front of them... they got scared as hell and suddenly think I'm some sort of wizard. Being allergic to code is a pathology for someone who work in IT, don't get it wrong kids!

lordnacho 11y ago

The closest I've come to visual programming is various UI designers and a couple of DB designers. They work OK up to a point, but as soon as you're doing something complicated you have a mass of arrows crisscrossing the surface. I think the problem is a visual designer is only a reasonable organising principle for 2D problems. You can get a nice global view. As soon as you need more dimensions, you might as well use something where the connections are only locally visible. By that I mean eg in a complex codebase, you can only see a few incoming/outgoing connections depending on where you're looking. A codebase can be arbitrarily complex, so chances are on any problem that isn't quite small, you aren't going to be able to represent it nicely in 2D.

dennisgorelik 11y ago

> nothing wrong with it inherently 1) Code diffs are pathetic with visual programming. 2) Sharing code examples is very limited with visual programming. 3) Full-text search capabilities are pathetic with visual programming.