I'm with you. Any attempt at visual programming I've seen has been:
1. Limited in what you can do.
2. If you need to do anything out of the norm it's either impossible or very difficult to find which menu entry you have to set in which way.
3. Doesn't have a proper diff.
4. Needs a slow compile process to actual code to work, making TDD strategies impossible.
5. Attracts the wrong kind of developers (those who don't look into the generated code and make all kinds of mistakes, those that don't understand anything about how computers work, etc.).
6. Hard to debug, because there's little to no debugging support.
7. Impossible to use with the wealth of great tools available for text manipulation.
8. Impossible to search properly, because it's not just simple text.
9. Very prone to vendor lock-in.
10. Doesn't interact well with versioning systems.
I don't remember when I saw this presentation. But it hit the nail on the head. If you go into a Korean McDonald's you have a visual menu. It enables even a foreigner who doesn't speak a bit of Korean to order a bacon cheeseburger. However if you want anything special (like no tomatoes), all of a sudden you need the language interface.
Language and text has evolved because it's necessary to describe the kind of complexity we have in the real world. That's why text is amenable as a representation of programs. They eventually represent a similar level of complexity as the real world. Of course it's easier to teach somebody to point at the McDonald's menu, but they won't get anything complex done, and they need somebody to work the abstraction for them (i.e. a real programmer).
I mean, GraphViz can have a diff. You could even go as far as taking the graph of the program, generating a GraphViz graph out of it and then taking the diff and simply colouring the nodes that made it into the diff.
That's true, but I would say GraphViz is a textual interface for programming graphs. Not a GUI for modeling graphs.
I'm very much for using something like GraphViz for visualizations (for exmaple integrated in AsciiDoc) to have a very good diffable plain text documentation that's nice to look at.
Well, my question is essentially this: what difference is there between visual programming and it's representation as a GraphViz graph?
These are two ways of representing the same concept: you could save the visual representation as a text document.
So what makes Visual Programming not have a textual representation? What makes them inherently incompatible with each other?
Because as of now, what I am seeing are the comments from people who used primarily proprietary tools, and those proprietary tools don't allow you to edit textual representations of the graphs directly because it makes the vendor lock-in so much easier.
>So what makes Visual Programming not have a textual representation? What makes them inherently incompatible with each other?
Nothing really, but you would need a Visual programming environment that maps one to one to your language. So that you could switch between coding in code and looking at or modifying the visual representation when it's helpful.
This would probably limit what you can do in the GUI, just as GraphViz limits control of the graph in favor of automatic layouting.
The vendor lock-in is one of the main issues I mentioned above.
If you have a good idea how to visually represent and modify C# or some other language I wouldn't mind that as an additional tool. I would think it's even very helpful for getting an overview. However the code should still be the master. And open-source is probably the only way to have such a tool that's actually good.
And if you can map one language to the GUI you could probably port this to many languages.
I was mostly concerned with what we have right now (LabView, Simulink and others).
1. Limited in what you can do.
2. If you need to do anything out of the norm it's either impossible or very difficult to find which menu entry you have to set in which way.
3. Doesn't have a proper diff.
4. Needs a slow compile process to actual code to work, making TDD strategies impossible.
5. Attracts the wrong kind of developers (those who don't look into the generated code and make all kinds of mistakes, those that don't understand anything about how computers work, etc.).
6. Hard to debug, because there's little to no debugging support.
7. Impossible to use with the wealth of great tools available for text manipulation.
8. Impossible to search properly, because it's not just simple text.
9. Very prone to vendor lock-in.
10. Doesn't interact well with versioning systems.
I don't remember when I saw this presentation. But it hit the nail on the head. If you go into a Korean McDonald's you have a visual menu. It enables even a foreigner who doesn't speak a bit of Korean to order a bacon cheeseburger. However if you want anything special (like no tomatoes), all of a sudden you need the language interface.
Language and text has evolved because it's necessary to describe the kind of complexity we have in the real world. That's why text is amenable as a representation of programs. They eventually represent a similar level of complexity as the real world. Of course it's easier to teach somebody to point at the McDonald's menu, but they won't get anything complex done, and they need somebody to work the abstraction for them (i.e. a real programmer).