I am a programmer, and have been for about 20 years or so. My impressions here...
Diagrams and visual models of programs have typically been disappointing. Diagrams based on basic examples always look neat, tidy, intuitive and useful. When scaling up to a real example, the diagram often looks like the inside of a box of wires—lines going in all directions. Where the simple diagram showed simple lines drawing boxes together, the complex one has the same problem as the wiring box—you have 40 different ‘ends’ of the lines, and it’s a tedious job to pair them all up and figure out what goes where.
Text actually ends up winning when you scale up to real problems. I tend to find diagrams useful for describing various subsets of the problem at hand, but for describing algorithms, particularly, text wins.
The problem of programming is always that you need to model the state of the computer in your head, at various levels. You need to be able to ‘run’ parts of the program in your head to see what’s going on and correct it. This is the essential aspect of programming as it currently is, and it’s no use hoping some language will take this job away—it won’t, and can’t. The most a language can do is communicate the algorithm to you in an organised way. The job you mentioned—of modelling the flow of instructions in your head, and figuring out the interactions of distant pieces of code—that is the job of the programmer, and different presentation of the data won’t take that job away—not until the day AI takes the whole job away. Good presentation can make the job easier—but until you understand the flow of the code and the relationships between the parts, you won’t be able to solve programming problems.
On the other hand—I feel that the state of computer programming today is still almost primitivist. Almost any program today will show you several different views of the data structure you’re working on, to enable you to adjust it. The exception, by and large, is writing computer programs—particularly within a single function. There you’re stuck with the single view in which you both read and write. I’m sure there is something more that can be done in this area.
When scaling up to a real example, the diagram often looks like the inside of a box of wires—lines going in all directions.
Part of this is probably due to VPLs not exposing the right abstractions—and of course, exposing an abstraction organically in a visual representation may be unfeasible. I looked at some instances of LabView programs linked in another comment, and there seemed to be a lot of repetition which would no-doubt be abstracted away in a text-based language.
I am a programmer, and have been for about 20 years or so. My impressions here...
Diagrams and visual models of programs have typically been disappointing. Diagrams based on basic examples always look neat, tidy, intuitive and useful. When scaling up to a real example, the diagram often looks like the inside of a box of wires—lines going in all directions. Where the simple diagram showed simple lines drawing boxes together, the complex one has the same problem as the wiring box—you have 40 different ‘ends’ of the lines, and it’s a tedious job to pair them all up and figure out what goes where.
Text actually ends up winning when you scale up to real problems. I tend to find diagrams useful for describing various subsets of the problem at hand, but for describing algorithms, particularly, text wins.
The problem of programming is always that you need to model the state of the computer in your head, at various levels. You need to be able to ‘run’ parts of the program in your head to see what’s going on and correct it. This is the essential aspect of programming as it currently is, and it’s no use hoping some language will take this job away—it won’t, and can’t. The most a language can do is communicate the algorithm to you in an organised way. The job you mentioned—of modelling the flow of instructions in your head, and figuring out the interactions of distant pieces of code—that is the job of the programmer, and different presentation of the data won’t take that job away—not until the day AI takes the whole job away. Good presentation can make the job easier—but until you understand the flow of the code and the relationships between the parts, you won’t be able to solve programming problems.
On the other hand—I feel that the state of computer programming today is still almost primitivist. Almost any program today will show you several different views of the data structure you’re working on, to enable you to adjust it. The exception, by and large, is writing computer programs—particularly within a single function. There you’re stuck with the single view in which you both read and write. I’m sure there is something more that can be done in this area.
Part of this is probably due to VPLs not exposing the right abstractions—and of course, exposing an abstraction organically in a visual representation may be unfeasible. I looked at some instances of LabView programs linked in another comment, and there seemed to be a lot of repetition which would no-doubt be abstracted away in a text-based language.