It's not about technology for its own sake. It's about being able to implement your ideas.
I stopped following technical forums for three reasons: pervasive negativity, waning interest on my part, and I realized I could predict the responses to most questions. "I bet this devolves into a debate about the validity of the singleton pattern." *click* "Ha! I knew it! Wait...why am I wasting my time on this?"
"Visual programming" is one of those topics that gets predictable responses. I don't mean "visual" in the GUI-design sense of the word, like Visual C++. I mean building programs without creating text files, programming where the visual component is the program.
Not too surprisingly, this is a subject that brings on the defensiveness. It's greeted with diatribes about "real" programming and how drawing lines to connect components is too limiting and links to articles about the glory of raw text files. At one time I would have agreed, but more and more it's starting to smack of nostalgic "that's how it's always been done"-ness.
In Microsoft's old QBasic, programs were still text files, but you could choose to view them as a grid of subroutine names. Click one and view code for that function--and only that function. It was very different than moving around within a single long document. There was the illusion that each function was its own entity, that a program was a collection of smaller parts. Behind the scenes, of course, all of those functions were still part of a single text file, but no matter. That a program was presented in a clear, easily navigable way changed everything. Was this visual programming? No, but it was a step away from thinking about coding as editing text files.
Take that a bit further: what if a visual representation of a program made it easier to understand, given code you've never seen before? To get in the proper frame of mind, go into the Erlang distribution and load up one of the compiler modules, like beam_jump.erl or beam_block.erl. Even with all the comments at the top of the former, just coming to grips with the overall flow of the module takes some effort. I'm not talking about fully understanding the logic, but simply being able to get a picture of how data is moving through the functions. Wouldn't a nice graphical representation make that obvious?
Neither of these examples are visual programming. I'd call them different forms of program visualization. Regardless, I can see the benefits, and I suspect there are larger gains to be had with other non-textual ways of dealing with code. I don't want to block out those possibilities because I'm too busy wallowing in my text-file comfort zone.
permalink October 25, 2010
I'm James Hague, a recovering programmer who has been designing video games since the 1980s. Programming Without Being Obsessed With Programming and Organizational Skills Beat Algorithmic Wizardry are good starting points. For the older stuff, try the 2012 Retrospective.
Where are the comments?