3 ms·

I wonder if part of the problem with visual programming isn't I/O? Coding uses the keyboard. Once you get good at using it a keyboard is a much faster input de

by api 8y ago

I wonder if part of the problem with visual programming isn't I/O? Coding uses the keyboard. Once you get good at using it a keyboard is a much faster input device than a mouse or a touch screen, especially for complex highly structured input like text or code. Visual programming relies on the mouse or the touch screen so you spend an inordinate amount of time clicking, tapping, dragging, positioning, etc., all of which is irrelevant to what you're trying to achieve. Maybe a visual programming system that used readily learnable keyboard input or even some novel form of touch panel or mouse input that eliminates the need to futz around with dragging and dropping and positioning would be the way to go? Or... https://neuralink.com https://neuralink.com ??

cdtwoaway 8y ago
If you are a very experienced programmer, you program LabVIEW (one of the major visual languages) almost exclusively with the keyboard (QuickDrop). Let me show you an example (gif) I press "Ctrl + space" to open QuickDrop, type "irf" (a short cut I defined myself) and Enter, and this automatically drops a code snippet that creates a data structure for an image, and reads an image file. https://github.com/b-ploetzeneder/MachineVisionCodeSnippets/blob/master/docs/assets/images/quickdrop/3.gif https://github.com/b-ploetzeneder/MachineVisionCodeSnippets/... If you are efficient at this type of input, the "dragging/dropping/rearranging" is similar to refactoring that you would do in an IDE. The only difference is that there is something called secondary notation in many visual languages (people are not aware of that, I'm only familiar with it because I've done research on the topic - it is how the code is visually arranged). How code is arranged is kind of a quality parameter for visual code (google examples for "spagetti code"). There are typical patterns that are instantly recognizable to an experienced user, ways of using distance and direction to group connected parts.. I actually played with alternative forms of input for LabVIEW, mainly gesture control and "drawing" on tablets. It sounds like a fantastic idea, but only for 5 mintues. After that, your hands start to hurt. The reality is that keyboard and mouse are heavily optimized tools for input (minimal movement of fingers, and we have lots of muscle memory), and don't restrict you. It's like saying "I can type xxx word per minutes" and thinking that typing faster would help you code faster..
- wires 8y ago
  I totally agree with you & thanks for that nice GIF! I used LabVIEW a lot and always enjoyed it... so anyway we have keyboard input for the diagrams / blocks, its very important. also a minimum of wires, they are annoying to draw
mathgenius 8y ago
Totally agree. For me any such system would have to come with vim bindings. This pretty much rules out "wires". All wires would need to come from some kind of geometric locality. For example, I have often dreamed of a programming language that uses horizontal and vertical compositions of tiles. It would be easy enough to layer this on top of a language like python, assigning semantics to the horizontal and vertical directions. But it would probably be a bit arbitrary.
- wires 8y ago
  ohey. you came to the right place :-) no wires, composition of boxes, no vi bindings yet, but def. something wanted and what we are going for I want vi/emacs/spacemacs for diagrams
wires 8y ago
yo totally agree, keyboard input to build the diagrams is mandatory. we are going much more for a text editor feel than some VR-style swipe-a-wire but once that's working, I'm all for neuralink + VR for "diagram dreaming"

by api 8y ago

cdtwoaway 8y ago

If you are a very experienced programmer, you program LabVIEW (one of the major visual languages) almost exclusively with the keyboard (QuickDrop). Let me show you an example (gif) I press "Ctrl + space" to open QuickDrop, type "irf" (a short cut I defined myself) and Enter, and this automatically drops a code snippet that creates a data structure for an image, and reads an image file. https://github.com/b-ploetzeneder/MachineVisionCodeSnippets/blob/master/docs/assets/images/quickdrop/3.gif https://github.com/b-ploetzeneder/MachineVisionCodeSnippets/... If you are efficient at this type of input, the "dragging/dropping/rearranging" is similar to refactoring that you would do in an IDE. The only difference is that there is something called secondary notation in many visual languages (people are not aware of that, I'm only familiar with it because I've done research on the topic - it is how the code is visually arranged). How code is arranged is kind of a quality parameter for visual code (google examples for "spagetti code"). There are typical patterns that are instantly recognizable to an experienced user, ways of using distance and direction to group connected parts.. I actually played with alternative forms of input for LabVIEW, mainly gesture control and "drawing" on tablets. It sounds like a fantastic idea, but only for 5 mintues. After that, your hands start to hurt. The reality is that keyboard and mouse are heavily optimized tools for input (minimal movement of fingers, and we have lots of muscle memory), and don't restrict you. It's like saying "I can type xxx word per minutes" and thinking that typing faster would help you code faster..

wires 8y ago
I totally agree with you & thanks for that nice GIF! I used LabVIEW a lot and always enjoyed it... so anyway we have keyboard input for the diagrams / blocks, its very important. also a minimum of wires, they are annoying to draw

mathgenius 8y ago

Totally agree. For me any such system would have to come with vim bindings. This pretty much rules out "wires". All wires would need to come from some kind of geometric locality. For example, I have often dreamed of a programming language that uses horizontal and vertical compositions of tiles. It would be easy enough to layer this on top of a language like python, assigning semantics to the horizontal and vertical directions. But it would probably be a bit arbitrary.

wires 8y ago
ohey. you came to the right place :-) no wires, composition of boxes, no vi bindings yet, but def. something wanted and what we are going for I want vi/emacs/spacemacs for diagrams

wires 8y ago

yo totally agree, keyboard input to build the diagrams is mandatory. we are going much more for a text editor feel than some VR-style swipe-a-wire but once that's working, I'm all for neuralink + VR for "diagram dreaming"