Visual Basic is one of those tools that looks very different when it's mostly in the past than it did when it was mostly in the future. For its time, VB was a huge, amazing, incredible simplification of what had formerly been about that much of a pain. This is part of why it tends to be reviled today, but it opened up the door for a large number of people to address a large number of problems that were heretofore mostly unreachable for them.
That type of tool... the tool that lowers the barrier to entry and makes more problems addressable by more people... that's a good thing.
(But, FWIW, VB is not really a visual programming language... more of a visual development environment built around an almost completely textual language.)
I think that was the point of the original article. That we can use more visual told to augment code, rather than trying to reinvent programming from scratch.
Have you played with Racket at all? There is another concept from the DrRacket tool that I really enjoy. Images have their own print mode, i.e. getting displayed in the REPL just by referencing them. Similarly, Matlab and Octave make printing matrices and graphs just a natural part of the experience.
There are probably a lot of good reasons for storing code as text, not the least of which are diffing as well as transmitting to/from other authors with their own toolsets. Merge visualization is a type of visual task related to programming.
Unix and its shell concept were supposed to, kinda, be this. But I think it got lost in the need to build production server environments. Who is the modern Symbolics with their LISP machines?
> Have you played with Racket at all? There is another concept from the DrRacket tool that I really enjoy. Images have their own print mode, i.e. getting displayed in the REPL just by referencing them.
I haven't played much with Racket, but I have worked with other systems that do this. (I've also developed a feature like this feature myself, many years ago, in a system I was building as a small-scale data analysis tool.) And yes, I agree that the combination of a REPL that both uses the full capabilities of the output device and renders objects that 'know what they are' is transformative. It makes entirely different classes of work that much more interactive.
In addition to the graphics, it still seems like a miss that I can't type 'ls' or 'find' at a terminal prompt and drag a filename from the list into a finder window to move or copy the file. (But getting to that point is work on several different levels... ls would need to produce output that somehow annotates each output filename with the fact that it's a file with a specific full path. Then the terminal would need to be able to intelligently work with those sorts of annotations.)
> There are probably a lot of good reasons for storing code as text, not the least of which are diffing as well as transmitting to/from other authors with their own toolsets.
I think part of it is history... both inside and outside the field of computing. It was technical limitations at the beginning of the field that made text more or less the only choice for early programming systems. (Unless you count the even earlier plugboard machines.)
Outside the field, images alone don't tend to be used to represent the sequences of events that are so common in programming. There's always a convention for imposing a sequence layered atop the visuals. This text, by convention, reads left to right. Pictographic languages have an ordering by convention. Comic books have both a convention to the ordering of frames and (mostly) the text within the frames. I mentioned LabView elsewhere in this thread... it's a visual programming language, but it has an explicit sequence construct (that models a sequence visually as frames of film that can be paged through).
I guess my point is that textual representations have a lot going for them out of the box... including an historically natural modeling of the notion of sequence and a huge volume of tooling and process optimized for the purpose of manipulating text. For a visual language to succeed, it has to offer compelling enough advantages to outweigh the cost of walking away from those things.
That type of tool... the tool that lowers the barrier to entry and makes more problems addressable by more people... that's a good thing.
(But, FWIW, VB is not really a visual programming language... more of a visual development environment built around an almost completely textual language.)