One big thing about plain text (and so conventional programming languages) is speed: for a proficient and practiced user, the keyboard is a really efficient method of entering data into a computer, and even more so when using an editor like Emacs or vim or a fully-featured IDE. As soon as you start using the mouse you slow down dramatically.
Another thing about normal text is the tooling has built up around it. Version control is the largest one: being able to narrow down to exactly when bug Y was introduced (“git bisect” is pretty cool) and see exactly what changed is really useful. Currently I don’t think there is anything like this for visual programming languages, and this is a requirement.
I don’t think these points are necessarily impossible to address: a visual programming language could still use the keyboard for manipulation and the structure of the code is build into the storage format so it would be feasible for version control to be more intelligent and useful than current ones.
Also, using visual connection can separate things too much, so the meaning isn’t obvious at a glance, e.g. in this picture one has to follow the lines back to work out what’s being used where, but in a textual language the variable names should tell you what’s what. This places an additional burden on the programmer, having to remember too much about what connects where: the language isn’t “local” enough so the programmer can’t easily model the program in their head.
That said, I’m sure a good language that uses a visual representation of control flow can introduce non-programmers to some of the ideas and allow them to automate some tasks, which is always a good thing. But, I don’t think they will be a success amongst “real” programmers (at least until brain-computer interfaces work fluently).
Case study: Some of the first programming I ever did was on the LEGO Mindstorms RCX, and normal method was via a version of LabVIEW, the programs look a little like this. It was really cool! It got me introduced to some of the ideas of programming, and for simple things it’s easy to understand the program.
But it was so slow. So intensely slow. Clicking around to find the right block to place, dragging it to the appropriate spot, connecting up the wires, place any auxiliary inputs for that block and connect them up, move all blocks around a bit so wires don’t cross and blocks don’t overlap, repeat. Takes 10 or 20 seconds at best to do the equivalent of “MotorA.run(5)”, and much more to do something like “if TouchSensor.is_pressed()”.
Furthermore, moderately complicated programs ended up as a mess of wires and blocks: it is very difficult to make modifications to a block of code (inserting stuff means either leaving it hanging off to the side, or manually rearranging the whole thing) and expressing some concepts/structures is pretty awkward. As an example: this piece of code.
A few years later, I started learning proper languages, and found out that I could actually run real code on the RCX, which allowed me to do vastly more complicated tasks, because, for instance, I could have variables without having to have wires running across the whole page, and it was easy to encapsulate repeated bits of code into separate functions (and they could take input parameters!).
(Obviously, that’s just one example of one visual programming language, but it illustrates a few of my points.)
One big thing about plain text (and so conventional programming languages) is speed: for a proficient and practiced user, the keyboard is a really efficient method of entering data into a computer, and even more so when using an editor like Emacs or vim or a fully-featured IDE. As soon as you start using the mouse you slow down dramatically.
Another thing about normal text is the tooling has built up around it. Version control is the largest one: being able to narrow down to exactly when bug Y was introduced (“git bisect” is pretty cool) and see exactly what changed is really useful. Currently I don’t think there is anything like this for visual programming languages, and this is a requirement.
I don’t think these points are necessarily impossible to address: a visual programming language could still use the keyboard for manipulation and the structure of the code is build into the storage format so it would be feasible for version control to be more intelligent and useful than current ones.
Also, using visual connection can separate things too much, so the meaning isn’t obvious at a glance, e.g. in this picture one has to follow the lines back to work out what’s being used where, but in a textual language the variable names should tell you what’s what. This places an additional burden on the programmer, having to remember too much about what connects where: the language isn’t “local” enough so the programmer can’t easily model the program in their head.
That said, I’m sure a good language that uses a visual representation of control flow can introduce non-programmers to some of the ideas and allow them to automate some tasks, which is always a good thing. But, I don’t think they will be a success amongst “real” programmers (at least until brain-computer interfaces work fluently).
Case study: Some of the first programming I ever did was on the LEGO Mindstorms RCX, and normal method was via a version of LabVIEW, the programs look a little like this. It was really cool! It got me introduced to some of the ideas of programming, and for simple things it’s easy to understand the program.
But it was so slow. So intensely slow. Clicking around to find the right block to place, dragging it to the appropriate spot, connecting up the wires, place any auxiliary inputs for that block and connect them up, move all blocks around a bit so wires don’t cross and blocks don’t overlap, repeat. Takes 10 or 20 seconds at best to do the equivalent of “MotorA.run(5)”, and much more to do something like “if TouchSensor.is_pressed()”.
Furthermore, moderately complicated programs ended up as a mess of wires and blocks: it is very difficult to make modifications to a block of code (inserting stuff means either leaving it hanging off to the side, or manually rearranging the whole thing) and expressing some concepts/structures is pretty awkward. As an example: this piece of code.
A few years later, I started learning proper languages, and found out that I could actually run real code on the RCX, which allowed me to do vastly more complicated tasks, because, for instance, I could have variables without having to have wires running across the whole page, and it was easy to encapsulate repeated bits of code into separate functions (and they could take input parameters!).
(Obviously, that’s just one example of one visual programming language, but it illustrates a few of my points.)