When people announce loudly that visual programming is the future, I'm often one being skeptical, and one of the points I try to make is that it's not a new idea. Not only has it been tried, it's been comprehensively tried, in multitudes of domains and variations. If you think this is the solution, you really ought to spend time studying what has already been tried.
This make that point a lot easier, and makes it a lot easier to find the things to study.
If nothing else, this screenshot display ought to put to rest the idea that visual programming makes programming "intuitive" or "easy to understand".... most of these screenshots are just as opaque at first glance as any block of code is. (And if their secrets are revealed once you learn the language and understand what is being said... well, that's true of code, too, you know...)
A nice example of where hand code struggled and a visual language within the constructs of a formal method succeeded is the V22 Osprey compared to the BA609 Tiltrotor.
The Navy struggles to maintain the V22 and the vehicle has a total of around 40 deaths attributed to it. While the BA609 has far fewer operational hours, it also is more rigorously tested.
There are other notable examples of Model Based Design being more appropriate for large complex, mission critical, systems; Toyota's Prius, Curiosity, Dreamliner, etc.
We are too. There are a lot of languages out there and as we find them we add them (we have someone who is searching and adding them).
> If nothing else, this screenshot display ought to put to rest the idea that visual programming makes programming "intuitive" or "easy to understand".... most of these screenshots are just as opaque at first glance as any block of code is.
I'm not sure if I totally agree with your conclusion of what the VPL - Snapshot page is bringing to the table. I think this page shows that there are many different ways people form mental models. Not only in the domain of textual languages but even within the domain of Visual languages.
The intuitive or easy part comes from people being able to program a computer using the mental models they are most comfortable with.
As for VPLs being tried comprehensively, I think this is true in the case of domain specific VPLs and I think they are becoming more and more main stream. For general purpose, domain agnostic VPLs, I don't think we've even touched the surface.
However, I'm really tired of the "Hey, guys! We can just fix programming by MAKING IT VISUAL! How come nobody ever thought of this before? Everybody else must be stupid! I'm going to go work on this for three to six months and revolutionize programming as we know it! Be right back!"
And no, I don't think I'm particularly exaggerating that, up to and including the "everybody else must be stupid!" bit. The periodic conversations on HN every time this comes up definitely have that in them, with a selection of people slapping their metaphorical forehead and going "Yes, that's so true!". VPLs may work, and may be good in certain domains, but they aren't the Holy Grail. If they were, we'd already know, because in fact it's been tried tons of times.
Yes, I know that's not what you intended, but it's part of what's there. It's not a new idea, it's not something that magically makes all complexity go away, it's actually a well-explored field. If you want to contribute to it, I suggest learning about what's actually been explored, and then trying to figure out why your contribution won't have the same failures as the previous attempts at general-purpose VPLs. Maybe you have an answer to that question, in which, like I said, go nuts. But don't waste tons of time replicating the obvious answers, again, all the while thinking Revolution is just around the corner.
Visual programming isn't the only place where this comes up. Another one is "Hey guys, what programming really needs is a PERSISTENT ENVIRONMENT! How come nobody ever thought of this before? Everybody else must be stupid!" followed by a description of, basically, Smalltalk. I've actually clocked some time in persistent environments... there are reasons why it's less desirable than you think. If you can't fix them, or even see them, it's unlikely you're going to revolutionize the world. (It would be interesting to see a pure-functional take on that idea, though, while I'm musing.... a pure functional optional-and reactive environment would actually address a lot of the problems you can get there...)
For example, I can almost always understand a recursive Fibonacci generator written in a new procedural or functional language that I've never seen before, yet I struggled to figure out what was happening as some of these visual languages generated the same Fibonacci sequence.
Why create that kind of complexity in an effort to avoid text?
Visual programming can help keeping track of data flows within complex and/or parallel programs.
"comprehensiveness is the enemy of comprehensibility"
I like nice simple diagrams (I joke to colleagues about having a limited budget for boxes and arrows or drawing things in crayon) - having these kinds of things where you try and include everything in your diagram seems to miss the point to me.
In other environments compatible with the FBP protocol (http://noflojs.org/documentation/protocol/) the components may be written in other languages. For example, MicroFlo components for microcontrollers are C++.
* Microsoft InfoPath - form designer, visual "rules" language, http://en.wikipedia.org/wiki/Microsoft_InfoPath , pic: https://cdn.lynda.com/video/130286-219-635215935570714090_54...
* Microsoft SharePoint Designer - visual workflow language, http://en.wikipedia.org/wiki/Microsoft_SharePoint_Designer , pic: http://i.msdn.microsoft.com/dynimg/IC620514.png
* Microsoft Powerpoint - visual tweens, timeline, navigation buttons and advanced animation, http://en.wikipedia.org/wiki/Microsoft_PowerPoint , pic: http://www.brainshark.com/~/media/2012%20Ideas%20Blog%20Imag...
* Macromedia/Adobe Flash IDE - visual tweens, timeline and interactive buttons, http://en.wikipedia.org/wiki/Adobe_Flash , pic: http://pad2.whstatic.com/images/thumb/1/17/Make-a-Simple-Ani...
* Arena - simulation program - http://www.arenasimulation.com , pic: http://i1.ytimg.com/vi/W_9_bTn2LZE/hqdefault.jpg
* FME - a lovely GIS data proccessing language - http://www.safe.com
* IEC_61131-3 - the main way of programming industrial controller devices - http://en.wikipedia.org/wiki/IEC_61131-3
I'd never heard of Google Web Designer. Looks useful, going to try it out.
Thank you. There is so much we could do with this list and would like to add more meta-data. We have someone who spends part of their time finding VPLs and adding them. When we run out of VPLs we can find (and there seem to be so many), we'll try to organize them a little better than alphabetical.
I'm working on Code Connect (http://codeconnect.io) with a friend and we're trying out some of the ideas first demonstrated in Code Bubbles. Instead of working with files, one works with individual functions. You can see a demo here if you're interested: https://www.youtube.com/watch?v=CuQ8NJOypqs
We're currently building it for Visual Studio, but we should be branching out into other languages and IDEs shortly after we release.
Submitters: please check whether an article has been posted before. In this case, running the title through HN Search returns the above immediately.
Once a story has had significant attention on HN, we generally don't allow reposts for about a year.
Several users have complained that randomness and churn are still causing many good stories to disappear without a trace. After looking at the data, we agree, and we're working on some experimental solutions for it.
If there's one driving idea behind HN, it's optimizing for quality rather than quantity, so losing any of the best stories is a big (bad) deal.
Sorry it was added twice.
We even added (limited) loops and recursion in v4.0:
What is listed as "Foundry Modo" is actually a different product called Katana by The Foundry.