Visual Programming Languages – Snapshots(blog.interfacevision.com)
blog.interfacevision.com
Visual Programming Languages – Snapshots
http://blog.interfacevision.com/design/design-visual-progarmming-languages-snapshots/
18 comments
Visual versus Text are just means to an end. What matters is how you apply the given form within a method or process.
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.
http://www.mathworks.com/videos/bell-helicopter-ensures-a-fl...
There are other notable examples of Model Based Design being more appropriate for large complex, mission critical, systems; Toyota's Prius, Curiosity, Dreamliner, etc.
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.
http://www.mathworks.com/videos/bell-helicopter-ensures-a-fl...
There are other notable examples of Model Based Design being more appropriate for large complex, mission critical, systems; Toyota's Prius, Curiosity, Dreamliner, etc.
> I'm glad this is still being updated.
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.
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.
If you want to create a nice general-purpose VPL, go nuts. I won't be offended. I'm skeptical, but open to being proved wrong.
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...)
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...)
Looking at all these visual programming languages, I'm struck at how complex many of them are.
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?
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?
Because generally you'll want to deal with a bit higher-level structures using the visual paradigm. So, a Fibonacci generator should be just a box, not a whole graph.
Visual programming can help keeping track of data flows within complex and/or parallel programs.
Visual programming can help keeping track of data flows within complex and/or parallel programs.
I rather like Martin Fowler's view of diagrams being sketches used to communicate rather than blueprints from which to build stuff:
"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.
http://martinfowler.com/bliki/UmlAsSketch.html
"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.
http://martinfowler.com/bliki/UmlAsSketch.html
Yeah, except that in our system the graphs are still executable: http://noflojs.org/
So are your components written directly in a "lower level" language (JavaScript etc.) and then the high level structure relating those components defined in the diagrams?
Yep, in NoFlo you write components in JavaScript, though you can also use other diagrams as "subgraph" components.
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++.
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++.
Thanks - that makes sense. I just get a bit nervous with the idea that it makes sense to use a diagram-based representation all the way down the stack.
Here is one example of a project where we used FBP on Node.js, browser, and microcontrollers. The components in the graph you can see there are quite high-level:
http://bergie.iki.fi/blog/ingress-table/
http://bergie.iki.fi/blog/ingress-table/
At what point does a visual program become low level enough to not just be a architectural whiteboard session?
More suggestions:
* 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
* 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
Two more:
* 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
* 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
Many ideas from Bret Victor also seem relevant, such as his recent talk on drawing dynamic visualizations:
http://worrydream.com/#!/DrawingDynamicVisualizationsTalk
http://worrydream.com/#!/DrawingDynamicVisualizationsTalk
From Microsoft, wouldn't BizTalk qualify?
That's an amazingly comprehensive list. Would be great if there was a summary table, or some kind of more organized shorter form view.
I'd never heard of Google Web Designer. Looks useful, going to try it out.
I'd never heard of Google Web Designer. Looks useful, going to try it out.
> That's an amazingly comprehensive list.
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.
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.
More discussions from the last time this was posted: https://news.ycombinator.com/item?id=7274674
Last time this came up (https://news.ycombinator.com/item?id=7274674) I had been working on a sort of hybrid between visual programming languages and the traditional "text in files" approach most people have been using for the past few decades. I still think that text seems to be the best way to express exactly what we want out of our programs, but I'm not convinced "text in files" is the right way to go about programming, at least not for all cases.
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.
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.
This is a dupe of https://news.ycombinator.com/item?id=7274674.
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.
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.
Just a suggestion -- have the submission routine search for prior appearances of the offering, especially effective when the URLs are identical. Then diplomatically suggest that the submission might make the submitter look like a craven copycat. :)
HN's dupe detection has always been an honor system. We leave it so porous because we want to give the best stories multiple cracks at the bat. Otherwise randomness and churn, especially during peak hours, would bury far too many. Of course, this also makes the dupe detector easy to game, so we ask people not to game it. A small number of reposts is ok.
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 curiosity, which cares about quality over quantity, so losing any of the best stories is a big (bad) deal.
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 curiosity, which cares about quality over quantity, so losing any of the best stories is a big (bad) deal.
Nice reply, thank you. Well put.
I wrote the blog post but this one and the one you linked to weren't submitted by me nor do I know who they are. I only found out via an analytics spike and asking someone who emailed me some VPL additions that it was submitted again.
Sorry it was added twice.
Sorry it was added twice.
Not at all; it wasn't your fault. We're just hoping to train the system via feedback.
Shameless plug: Filter Forge, http://www.filterforge.com
We even added (limited) loops and recursion in v4.0: http://www.filterforge.com/features/version4/loops-and-recur...
We even added (limited) loops and recursion in v4.0: http://www.filterforge.com/features/version4/loops-and-recur...
This is a pretty insane example of using Pure Data (http://puredata.info/) to make procedurally generated music for a game: https://www.youtube.com/watch?v=0xr4aL1C24E
It's close to the end of the list, but it's worth hearing more about Scheme Bricks and the music people do with it.
http://www.pawfal.org/dave/blog/2013/05/algorave-practice/
http://www.pawfal.org/dave/blog/2013/05/algorave-practice/
I'm excited to see Sikuli on the list this time around (it wasn't there last time). I use Sikuli quite often, and it's basically just Python but with pictures thrown in, so it's really easy to use.
Also very interesting: http://www.subtext-lang.org/
Schematic tables in particular are a novel interface that is really interesting.
Everything from Automagic (Android automation package) to Alan Kay demo (from late 60s it seems) to LabVIEW to Alice, Squeak, Automator and a lot I haven't even heard of before.
Whatever happened to IRIS Explorer by NAG, is it still available?
Wow, I had no idea how many of these exist(ed). Also, thanking my lucky star that I don't have to use any of them. Bad memories of LabView and HP Vee.
Very neat. I found a bug.
What is listed as "Foundry Modo" is actually a different product called Katana by The Foundry.
What is listed as "Foundry Modo" is actually a different product called Katana by The Foundry.
Why is the Hypercard one a picture of MacOS 6's Control Panel?
No one has figured it out...yet..
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...)