This Isn’t Another Quick Dismissal of Visual Programming

Programming in the 21st Century - James Hague - October 25, 2010

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 I am 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.



Categories: Blogs  Programming in the 21st Century  

Comments

anonymous avatar

You got a very good point there, but there’s a problem. You’re talking about code visualization and that’s quite different from code production,  editing, refactoring, manipulation, and all those parts of the programming process, and a lot of the are just not very well suited to a visual style( as in graphics). Visual production is quite hard, I mean it’s not only perceived by it’s formal meaning but then you have aestethic right in the middle, and then agree in the form that should be used.

If you want to tell us that text feels old, there’s nothing farther from truth: programming languages and styles are always improving and now more than ever we’re seeing lots and lots of new languages experimenting with new ways for programming. I mean, I’m reading this on erlang planet, and erlang itself it’s quite new for the masses. And then take a look to efene.

Thank you for the post

Posted by Carlos Perilla on 26 Oct 2010 at 04:01



 
anonymous avatar

Hello

There are General Purpose Visual Programming Language (Free-Open Source)

You can try it
http://doublesvsoop.sourceforge.net

Using this visual language.. you can develop any kind of software ... no limits at all ... you can see/edit the code (Optional) ... you will work faster than coding (Be Sure).... you can create Complex/Large applications .... No Syntax Errors .... Max Readability ... Max Writablity ... You can Customize the visual interface (create/edit components) ... very easy to learn .... very easy to use… productive ...And more

Have fun

Posted by msfclipper on 06 Jan 2011 at 12:09



 


Add comment

Name:

Email:

URL:

Smileys

Remember my personal information

Notify me of follow-up comments?