Software applications are one of those things that are easy to draw, but impossible to describe without years of practice in arcane specialized languages.
I agree. They are easy to draw. They are easy to draw because in doing so you eliminate real world situations and just draw some boxes that elide all the real detail of programming. And in doing so you barely express what will be needed to make the program actually work.
Visual programming has been attempted over and over again. It's the future and I suspect it always will be.
Most people seem to focus on the visual programming model which is just one aspect of NoFlo. I think its real power comes from the Flow Based Programming model. Functional programming is the trendy solution to the problem of concurrency these days. But I think FBP could offer some solutions in this domain too.
In my experience with LabVIEW, I found that the FBP paradigm greatly simplified process of writing highly parallel code. Whether you use the text or visual UI, I’m excited that NoFlo will bring this concept to JS development.
And yet diagramming remains a useful communication technique. Why? Because diagraming recapitulates one of the most fundamental of programming activities: describing the addressability of data. When you draw a box, you are saying "This is worth addressing, this is how big it is and I'll even try to impart it's qualities with shape, color, and a label." The stage is set, and now you can describe how the actors interact with each other. And that's useful.
It's interesting, though, that diagrams seem to only really be useful for humans. Maybe that's another form of Turing test: hand a program a high-level diagram and see if the computer can write a program that behaves as the diagram describes. Perhaps this would even be an iterative process, with the computer doing what it's sure about, e.g. defining a type, and then prompting for more input (possibly in the form of a diagram!) when it's unclear. I suppose a way to approach this would first have a known-good solution, like Word-Press, do the diagrams for it, then feed the diagrams into this hypothetical software-writing program and see how much help it needs to recover something like the original WordPress.
There's even another interesting question, which is what impact the programming paradigm has on diagram descriptions of software. You would see differences at both the framework and the language level: a SpringMVC diagram is different than Play, which is different than Rails, which is very different from Noir. And Clojure programs would, generally, tend to be diagrammed very differently from Java or Groovy programs.
I agree. They are easy to draw. They are easy to draw because in doing so you eliminate real world situations and just draw some boxes that elide all the real detail of programming. And in doing so you barely express what will be needed to make the program actually work.
Visual programming has been attempted over and over again. It's the future and I suspect it always will be.