3 ms·
I've thought about this, and I think I have a general sense as to why. First, let's look at the size of the keyboard in relation to the screen: it's huge. In m
by aylmao 6y ago
I've thought about this, and I think I have a general sense as to why.
First, let's look at the size of the keyboard in relation to the screen: it's huge. In most laptops, it is about half the size of the screen. Keys easy to use— they all work the same way, and we all grow up knowing how to use letters. You can press several at once, press them in quick succession, plus they are huge and haptic. You don't have to be precise with how you press one, and you feel it when it presses: your eyes, fingers and ears are all telling you that the information you're transmitting is making it to the screen.
You effectively have a very big, very good, dedicated toolbar and the rest of your screen is either your canvas (the text area) or can be used for other tools to augment your programming.
With visual programming languages, you have to reserve part of this screen real estate, for the input. It's like having to put your keyboard on screen: leaves you less space for the canvas or additional tools. Moreover, these UI elements are often smaller than the keys in a keyboard, and hovering/clicking something with a mouse doesn't provide haptic feedback. All this means a little more mental effort when composing with the mouse, and doing all the aiming, clicking, dragging and dropping. It's more "precise" and "delicate" movements that require more "attention", if you will.
On top of that consider that there is no visual programming environment is ever "fully" visual— there's always typing involved at some point or another. You have to enter a number, a string, the name of a variable, etc. All this switching between the keyboard and the mouse is even more movement, more attention, more cognitive load to the layout of ideas. There is a reason all these modern IDEs have a "VIM mode"— you'd think our new tools would replace an older, more complicated way of doing things, but VIM has managed to survive in the hearts of experienced programmers because it allows them to type without reaching to the mouse.
Let's delve into this. For an unexperienced programmer, "wording" the idea (remembering the syntax, etc) probably takes enough time that laying it out is not the bottleneck. For an experienced programmer, finding the idea is the bottleneck, but once found, wording it is quick, and so laying it down becomes the bottleneck. Being able to express things quickly becomes important.
Moreover, revisiting this "finding the idea" and "wording the idea"— because wording the idea is fast, an experienced programmer might write while it's still looking for the right idea, as a way of "thinking out loud". They will type something, delete it, type something else, backspace repeatedly, etc. Seeing it in front of them helps the idea materialize, kind of how a musician might play notes as it's thinking of a melody, or digital tools allows artists to paint strokes and undo as they draw [1: notice in this link how a digital artist works. They're constantly drawing and erasing. It's the first video I found when searching "painting digital"].
This is harder and slower to do with current visual tools.
[1]: https://youtu.be/1lemi11CgLs?t=1200 https://youtu.be/1lemi11CgLs?t=1200
- aylmao 6y agoTo follow up on my last two paragraphs, I think this is why visual programming has proven successful in some fields. In computer graphics, a collection of nodes with visual controls is perhaps a faster way to "think out loud" then jumping across different lines in a file to change number values or colors. In audio, and interface mimicking a rack [1] where you can again, turn knobs or connect different signals visually is faster to "think out loud" in than typing it out. Overall, it comes to enabling the creative process in the most frictionless way, wether or not is the most initially approachable way. [1]: https://youtu.be/tMh3ZEFyEmo?t=50 https://youtu.be/tMh3ZEFyEmo?t=50
- Firadeoclus 6y agoVisual tools often involve direct manipulation via pointing and dragging. This doesn't have to be the only mode of interaction. It is entirely possible, probably highly desirable, to have visual tools which can be 100% keyboard driven. Many programmers explore ideas with pen and paper, beyond the restrictions that code as a sequence of characters would have. There are definitely benefits to be had in those areas.