I've been kicking around the idea of building a visual programming language for about a week, so this article is well timed for me. Let me throw out a counter

I've been kicking around the idea of building a visual programming language for about a week, so this article is well timed for me. Let me throw out a counter hypothesis, please feel free to tell me where I'm wrong. I can imagine that, when you have to build a complex program out of a bunch of boxes, and it gets to the point where a simple for-loop requires a bunch of boxes, that the whole program would be way, way too complicated. This is the same problem if you wrote a java app, only it all fit in a single file, and every class of the java frameworks were also defined in that file-- it would be a massive file and damn hard to understand. So, I think the same solution should work for a visual programming language: Modules (as they're called in erlang) or Classes (in Java etc.) So, at the highest level, your program would be a small collection of boxes with lines between them. Maybe these are the major features of your app. If you clicked on a box, you'd be drilling down into that level and you'd see how that feature was built. And it would be composed of a series of boxes- each of which was probably akin to a module or a class. And if you clicked on one of those boxes, you'd be down into that module or class, and it is also composed of modules or classes. You could drill down this way, until you ultimately got to the lowest level boxes which are akin to lines of code or components of a line of code in a text based language. I think that would be visually easy to manage-- you'd only be dealing with a relatively small number of boxes and pipes at a time, and conceptually drilling down and pulling back is someting that I think non-programmers would be able to understand. (Plus drilling all the way down would be something that programmers want to do, but non-programmers (the presumed target of a visual programming language) might not care about.) Second hypothesis: If it makes no sense to drill all the way down, then at some point, when you drill down you're dropped into text based code. Thus the higher levels of abstraction could be done visually, but the components themselves could be done with text-- sort of a hybrid approach that might give the best of both worlds. Thoughts? (and I'd love pointers if anyone knows of a system like this that is open source.) Also, If I did try to build this thing, it would be my first ever language. I'd love to have a checklist of the basic components of a computer language that I could work form... otherwise I'm afraid I'll implement what I need and probably miss something, or do it wrong. But havent' found any good guides so far.