PCPro.co.uk has an article on graphical programming
Programming is a fairly specialist activity, requiring a different manner of thinking to operate in. Some programming languages try to be friendly in terms of words, symbols and grammar used to write the code (syntax) – but it still tends to be an initial hurdle to get past.
An asker on Slashdot had the following question today:
“…why are we still writing text based code? Shouldn’t there be a simpler, more robust way to translate an algorithm into something a computer can understand? One that’s language agnostic and without all the cryptic jargon? It seems we’re still only one layer of abstraction from assembly code. Why have graphical code generators that could seemingly open coding to the masses gone nowhere?”
The /. editor added:
Of interest on this topic, a thoughtful look at some of the ways that visual programming is often talked about.
Here are my thoughts:
For the TL/DR: graphical programming is inefficient, and error prone; better methods of viewing source code during read-back is more interesting.
Apple has the Automator, which takes actions and chains them together. You can define variables, and operate on them.
I used to work with an enterprise software called Adobe LiveCycle ES2 until 2012, which does business process automation — the approach was that rather than defining the business workflows in a chart diagram, and handing it over to a programmer to implement, the diagram itself WAS the program – business workflow designers (often managers and business consultants who were not technical) could build the workflow as individual steps, and more tech savvy people would add the variables and stuff to make it work.
A quick search on Google images turns up a lot of interesting stuff, including this graphical programming tool. [pcpro.co.uk] The techniques have been in the making for a while.
Needless to say, even with these visual aids, to get something worthwhile done, you need to have actual programming knowledge – the Automator is good for home use but cute at best in production environments due to lack of finer configurability, and the business process workflow programming I mentioned still required in-depth computer knowledge: the workflow creators’ work was often computationally inefficient, and often had to be refactored to take into account finer points of logic flow from both efficiency and data management points of view.
On top of that, it’s easier to search on the Internet and on forums for code snippets, and discuss these when they’re already in text form – no programmer actually works in isolation, communication is essential. Some advantages in reading back code might be had in graphical representation, and certainly creating a “visualization tool” for reading back code or designing high-level ideas might be helpful – but making it the implementation language is probably a bad idea.
On that matter, I recently came across the LightTable IDE [vimeo.com] which facilitates programming by doing live demonstrations of what happens to variables directly in the code flow. This also catches syntax issues early, bad type casting, and other relevant issues. Much better than a graphical abstraction I think, but that may just be preference.
The linked article indicates that visual programming has had success with casual creators in very specific scenarios (education of young kids, and use in LittleBigPlanet) – not in the general purpose programming arena for business critical solutions, high throughput systems, etc. Also, it says nothing concrete apart from “it’s a matter of opinion” – nothing about the advantages or disadvantages of either.
Ultimately, it’s like asking why bread shops don’t use bread making machines. Tools for the job, tools for the desired outcome. If the simpler method works at home, that’s great – but if you want to work professionally, the more sophisticated method yields better control over the final product.