
Visual Programming Languages – Snapshots - seanmcdirmid
http://blog.interfacevision.com/design/design-visual-progarmming-languages-snapshots
======
troymc
If you think of a programming language as a set of tokens and production rules
(a grammar), then can't every programming language have infinitely-many visual
representations, including "pure text," "blocks/pipes" and "Jacob's
Representation"?

Does it make sense to call a programming _language_ "visual"?

What if I represent a C program by a sequence of smells... The translator
device reads the text from start to end, converts it to a token sequence, and
emits a different smell for each token. Does that mean C is a "smell-based
programming language"?

If the tokens get read by a text-to-speech program, does that make C an "audio
programming language"?

What about a different _visual_ way to represent C programs (besides the usual
text way)? Maybe we replace each token with a colored block, where each token
has its own color.

Can't we dispense with the notion of a "visual programming language"? There
are programming languages, and for each language, there are many ways to
represent its programs.

~~~
Renaud
Except that:

\- most text-based programming languages have no purely graphical counterpart.

\- Most purely graphical programming languages have no purely textual
counterpart.

\- a graphic language is generally meant to abstract at a higher level and by
doing so it has bigger trade-offs than a lower-level textual language (that's
why most graphical programming languages are specialised and those that are
too broad in their applicability domain generally fail to be useful).

Your suggestions kind of miss the point: it's not about the visual
representation of basic tokens. If that's your goal, then of course you could
represent any token and syntax with colour, sound, smells but it wouldn't
solve any problem: you would still have to use the complete original syntax,
and your colourful additions would not offer any improvements to basic textual
representations of the code.

Graphical programming attempts to solve other types of problems. Generally,
they try to hide some complexity behind a particular paradigm. Some are useful
to help in learning because the building blocks can look like a concrete
representation of something more abstract, like having a kind of C-jaw that
represents a loop.

Other systems will help alleviate complexity using domain specific visual
languages that would be difficult to represent textually: electronics for
instance, or connection between musical equipment, or animations engines, etc.

Bottom line is that yes, they are all languages but while most textual
programming languages are versatile and generally allow any level of
complexity, graphical programming languages are sometimes better fits when the
domain is much narrower.

They also generally operate at a different abstraction level.

~~~
troymc
Fine, but give me a program in any programming language, be it "text-based" or
"purely graphical" and it's probably possible to translate it into a
representation that's vice versa. (Problems arise when a representation is too
abstract: ambiguity can occur.)

Program representations are like city maps. There's only one city, but there
are many maps: the subway map, the map of post offices, the map of gas lines,
the map of Wi-Fi coverage, and so on.

I will agree that different representations have different capabilities and
use cases. However, text is also capable of great abstraction, e.g.

z2 = BesselJ(n, z1)

~~~
mbrock
You're kind of stretching the definition of "language," though. Programming
language grammars are defined textually.

Do you think, for example, that a (useful) pictorial representation of Haskell
code can be derived simply from the language grammar?

Sure, the map is not the territory, but you can also say the language is
itself the map, and the territory is something way more abstract, like
"computation."

Perhaps you can take the semantics of Haskell and invent a graphical syntax
for it, perhaps even strongly inspired by the textual syntax of Haskell. But
it wouldn't be straightforward, and any obvious, straightforward attempt would
probably be terrible.

In other words, I don't think it's obvious that there is a "deep structure" of
programming languages that can be worked on directly in a wide variety of
formats. Unless you count the AST as such a structure, in which case graphical
programming is reduced to graphical tree manipulation (which admittedly is the
path taken by many of these examples).

~~~
nitrogen
Dataflow languages (like the one I developed:
[http://www.nitrogenlogic.com/docs/palace/](http://www.nitrogenlogic.com/docs/palace/))
seem like they would have a fairly straightforward mapping to/from a purely
functional language like Lisp.

~~~
mbrock
That looks cool!

By the way, the more I think about this, the less I seem to know even what a
"language" is.

Is Lisp a language? No, it's a family of languages, but even Scheme is a
language known for its minimal grammar and its infinite extensibility. A
common critique says that one programmer can't understand another's Lisp code
because there's such a great potential for redefinitions and domain-specific
syntactic extensions. If Lisp has a slogan, it's "code is data." Is Lisp a
meta-language, or even an anti-language?

------
Permit
I think there is a balance to be struck between visualizing various aspects of
a program (control flow, data flow etc.) and retaining the control available
to developers writing their programs as text stored in files. It does seem
strange in some ways that we're still dumping text into files in 2014. A given
function might interact with classes and functions defined in 10 different
files, and we can only view two or three files at a time.

It seems like programmers compensate by creating a mental model of their
program as they try to memorize how it will execute. (The comic _This is why
you shouldn 't interrupt a programmer_ comes to mind:
[http://heeris.id.au/2013/this-is-why-you-shouldnt-
interrupt-...](http://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt-a-
programmer))

I'm actually working on a plugin for Visual Studio roughly modeled off of Code
Bubbles to see if it's practical to solve this problem.
([http://codeconnect.io](http://codeconnect.io)) I think text is the best way
to express exactly what you want out of a program, but the way we're
interacting with that text can be improved.

~~~
ibdknox
It's been done a few times before :) For example, check out the debugger
canvas:
[http://visualstudiogallery.msdn.microsoft.com/4a979842-b9aa-...](http://visualstudiogallery.msdn.microsoft.com/4a979842-b9aa-4adf-
bfef-83bd428a0acb)

The problem ends up being that you're trading one form of cognitive load for
another and it turns out that given our text-centric view of writing code,
locality ends up having a lot of importance (which is lost in the model you're
suggesting). There are lots of other issues with it at a practical level too.
I've never seen an input model that works well with lots of disconnected
little editors, for example. How do you navigate between them? How do you lay
them out? What happens when the graph is disjoint? How do I get to some point
in the flow of the program? What if I need multiple things that aren't
directly related next to each other? How do you even determine relation?

After having implemented this in various forms about 4 times now, I'm fairly
convinced this is one of those things that makes good intuitive sense, but
bleeds to death from a whole bunch of paper cuts in practice.

The one case where this _does_ seem successful though is in the step-wise
debugging case. There's a very definite flow, locality matters a lot less, and
debugging is an inherently mouse-oriented task - all the things you need for a
zoom-based infinite canvas to work out.

~~~
Permit
CodeCanvas and Debugger Canvas are two projects we've definitely consulted
while building this thing.

We've solved some of the practical problems you've described. The new C#
compiler Roslyn makes determining relation fairly trivial, something that I'm
assuming proved difficult in Clojure(script) and Javascript.

Many of the other issues are user interface/user experience problems that are
better demonstrated than explained. Unfortunately, our demo isn't quite
polished yet. We're showing it off at our school symposium in mid-March, so we
should have something to show before then.

Would it be alright if I ran the demo by you when we finished it? Much of our
inspiration for the idea came from CodeBubbles, Code Canvas and the original
Light Table demo, so it's interesting to hear that you've decided against it.

~~~
ibdknox
One of my 4 implementations was the prototype I did at MSFT that became the
debugger canvas :) Me and a few others built it after I saw the original Code
Bubbles demo.

> The new C# compiler Roslyn makes determining relation fairly trivial,
> something that I'm assuming proved difficult in Clojure(script) and
> Javascript.

I had access to the language models then too, but the thing is relation is not
always written directly into the code. This was the point I was making about
locality. In a world with mutability, you can't really know what matters. We
tend to cope with this by putting code that relates near each other (in the
same file, in the same parts of a file, etc), but that relation isn't made
specific in the call chain. It could be, and usually is, buried under several
levels of indirection. The lack of locality really frustrated people, because
the mainstream models we have for programming don't directly relate to flow
and so it ended up being a square peg in a round whole kind of thing.

> so it's interesting to hear that you've decided against it

I've decided against it for the way we program now... :) Flow as a general
concept is a very good one, and anything that can make that explicit would be
wonderful. But we can't program with rampant mutation and callbacks and expect
it to work out.

~~~
Permit
>One of my 4 implementations was the prototype I did at MSFT that became the
debugger canvas :) Me and a few others built it after I saw the original Code
Bubbles demo.

Haha yeah I've actually encountered that project. There are few things I've
wanted open sourced as badly as Codeporium. A decompiler only gets one so
far.. (You seriously come up all the place when it comes to extending the
editor: [http://social.msdn.microsoft.com/Forums/vstudio/en-
US/e536bc...](http://social.msdn.microsoft.com/Forums/vstudio/en-
US/e536bce3-30f9-4e7f-b322-b3835a487bb0/how-to-create-an-editor-with-a-
projection-buffer?forum=vsx) haha)

>I've decided against it for the way we program now... :) Flow as a general
concept is a very good one, and anything that can make that explicit would be
wonderful. But we can't program with rampant mutation and callbacks and expect
it to work out.

Fair enough.

------
valarauca1
I love how the screen shot of labview is literally the shot NI uses from an
article giving an example of what not to do [1]. Labview has its quirks but
its not as horrible as that screen makes people believe

[1]
[http://www.ni.com/newsletter/51735/en/](http://www.ni.com/newsletter/51735/en/)

~~~
joelthelion
In my experience with Labview you still spend a lot of your time arranging
cables and boxes.

I'm sure practical visual programming will be a reality some day, but for now
writing code is the best we have.

~~~
jimbokun
"In my experience with Labview you still spend a lot of your time arranging
cables and boxes."

"I'm sure practical visual programming will be a reality some day..."

I don't follow how you get from the first sentence to this conclusion. Seems
to me spending a lot of time "arranging cables and boxes" is pretty inherent
to the whole visual programming idea.

~~~
joelthelion
What I'm saying is that I hope someone will come up with a way of making
programming more visual without the tedious aspect of arranging cables and
boxes.

------
dethstar
When I see something like this, and comments debating the idea of it is a
language/programming at all I think of this presentation:
[http://worrydream.com/dbx/](http://worrydream.com/dbx/) and the author of the
link of this thread also uses one example that was used in the presentation.

We could have a bunch of different cool things to use for programming, but
with a majority screaming "no, that's not programming" we kept ourselves from
some really neat inventions.

~~~
ericHosick
> majority screaming "no, that's not programming"

I think this has something to do with one of Clarke's Three Laws
([http://en.wikipedia.org/wiki/Clarke's_three_laws](http://en.wikipedia.org/wiki/Clarke's_three_laws)).

> When a distinguished but elderly scientist states that something is
> possible, he is almost certainly right. When he states that something is
> impossible, he is very probably wrong.

I talk and think a lot about democratization of software development.

People I talk with who really want to program but couldn't get past coding
really like the idea of visual programming environments where they don't have
to deal with the compiler/interpreter.

When I talk with people who are experienced, they feel there is no advantage
to programming any other way than writing code.

From my experience, we have not gone too far in improving the development of
software for many many decades and Bret Victor does a good job of pointing
this out. I think the way we code now, and specifically how we build out
software frameworks, is flawed.

We engineer software frameworks that contain both mechanism and business
"objects" when software frameworks should only contain mechanism.

Software frameworks should be coded to be used by non-coders: not by other
coders.

Really, a domain agnostic visual language will be hard to develop when it is
representative of how we code now.

------
jcromartie
All of the "block" style visual languages are just Lisp with colored blocks
instead of parentheses.

Alice, App Inventor, Blockly, Hopscotch, Intentional Technology, Lamdu,
Minibloq, Scheme Bricks (obviously), Scratch.

I've built these sorts of things before to let users define logic through a
web interface. I think that's about the extent of their usefulness.

The dataflow languages seem much more interesting.

~~~
seanmcdirmid
They are like lisp without cons/cdr, higher order functions, or homonicity.
Oh, wait, they aren't like lisp at all.

~~~
jimbokun
I'm not familiar with those languages, but are you sure those environments
don't include the things you mention?

Even homoiconicity, I don't see why you couldn't write a program to manipulate
the blocks (or whatever) on the screen to create a new program.

I don't know if those environments support such construction, but I don't see
any reason why it would be particularly difficult to implement.

~~~
seanmcdirmid
None of those VPLs include those features; they would be too complicated for
their target audience. They only resemble LISP in that they mostly are
procedural (some of them are rule-based, but you can do rules in LISP also
given its Turing Completeness).

There is a VPL based on LISP, I forgot the name, but you could definitely say
it is LISP then.

The point was that saying these were all like LISP is like saying they are all
like machine code.

------
cswetenham
A couple I'm aware of that aren't in the list:

\- Aardappel (visual functional programming) [1] \- Widget Workshop (something
like a cross between The Incredible Machine and visual programming) [2]

[1] [http://strlen.com/aardappel-language](http://strlen.com/aardappel-
language) [2] [http://www.old-games.com/download/3399/widget-
workshop](http://www.old-games.com/download/3399/widget-workshop)

~~~
renownedmedia
Widget Workshop is what got me into computers!

------
exDM69
A few years ago there was an MIT research project about a visual programming
language where the program was represented as directed graphs. Does anyone
know of such an MIT project from the early 2000s?

There were a few things that set this programming language apart from most of
visual programming environments. First of all it was a proper programming
language and not a toy project. The graph structure visualized recursion and
re-use of variables very well. The code could be evaluated and edited at the
same time by collapsing parts of the graph. You could collapse every iteration
of recursion in the graph.

The most striking difference with normal programming languages was that all
names were purely optional documentation.

Too bad I can't remember the name of this project. I remember seeing a
presentation video of this project which got me really excited. It was a
language by computer scientists, for computer scientists and not something
done for kids or designers to get their first baby steps in programming.

Out of the ones on the list, AppInventor/Blockly/Scratch is definitely my
favorite. There are different puzzle pieces for different syntactic
structures, statements and expressions in particular. The puzzle pieces are
colored by the type of the expression they represent. This makes it easy and
obvious which piece fits where.

------
canjobear
Something I wish was here was the spread-sheet style event programming
interface in the old Clickteam programs, Multimedia Fusion/The Games Factory.
I used to make so many complex games and other programs using that in the
early 2000s; it was very powerful and I'm not sure why it never caught on in a
big way.

[http://www.digitalmediaacademy.org/wp-
content/uploads/2009/0...](http://www.digitalmediaacademy.org/wp-
content/uploads/2009/03/event-editor.jpg)

The rows are events and the columns are objects; you fill in a cell with how
the object should react to the event.

~~~
invalidOrTaken
I had a similar experience with Klik'n'Play. Before I ever wrote a line of
code, I made a bunch of (crappy, tiny) games with it.

------
morganherlocker
A couple that I did not see on the list but also come to mind:

\- Windows Workflow Foundation (used for building .Net based service flows)
[1]

\- ArcGIS Model Builder (used for geospatial processing automation) [2]

\- Sextante (open source geospatial processing that plugs into QGIS) [3]

\- GRASS GIS Modeler (open source geospatial processing that plugs into GRASS
GIS) [4]

[1] [http://msdn.microsoft.com/en-
us/vstudio/jj684582.aspx](http://msdn.microsoft.com/en-
us/vstudio/jj684582.aspx)

[2]
[http://resources.arcgis.com/en/help/main/10.1/index.html#//0...](http://resources.arcgis.com/en/help/main/10.1/index.html#//002w00000001000000)

[3] [http://sextantegis.com/](http://sextantegis.com/)

[4]
[http://grass.osgeo.org/grass64/manuals/wxGUI.Modeler.html](http://grass.osgeo.org/grass64/manuals/wxGUI.Modeler.html)

~~~
ericHosick
Added.

~~~
dkersten
There's one or two on this list of dataflow languages I compiled some time ago
that you don't have included:
[https://stackoverflow.com/questions/461796/dataflow-
programm...](https://stackoverflow.com/questions/461796/dataflow-programming-
languages/949771#949771)

Specifically: SCADE, AudioMulch, [BLOK], Shake, Max/MSP and Epecco. There are
also some programs with visual programming elements: Voreen, Blender and
ANKHOR FlowSheet.

Links/screenshots in the stackoverflow answer.

~~~
ericHosick
Thank you for the list.

------
evanspa
In Lectura 7A of SICP[1], Sussman opens the lecture by talking about how
programs can be thought of as character-stream descriptions of a wiring-
diagram for some kind of machine. And he actually goes on to talk about the
notion of visual programming languages (he didn't think they were a good
idea). It's interesting to see these screenshots of visual languages. I must
say that I agree with Sussman's reasoning for not liking them (difficult to
edit them and they take up a lot of real-estate).

[1] [http://ocw.mit.edu/courses/electrical-engineering-and-
comput...](http://ocw.mit.edu/courses/electrical-engineering-and-computer-
science/6-001-structure-and-interpretation-of-computer-programs-
spring-2005/video-lectures/7a-metacircular-evaluator-part-1/)

------
dandelany
Great list, thanks for making this!

One that's missing, though, is Max/MSP, a visual programming environment
focused around music & other media. It's used heavily by many experimental
musicians and artists.

~~~
s_kilk
As much as I like playing with Max and PureData, I think they also highlight
some of the many problems with the whole "Visual Programming" thing.

They don't play well with version control and are a nightmare to debug. The
developer will also quickly hit a point where the visual nature of the tool
becomes more of a hindrance than a help, when they're left drowning in a
tangled mass of pipes and boxes.

I would really love to see a fresh take on this idea and an attempt to address
some of the above problems.

------
hayesdaniel
Awesome to see Nuke on there. A few other 3d apps to consider:

\- Houdini (by far the most applicable)

\- Maya (2012+ offers a 'node editor' but has always operated on a DAG.)

\- Katana (not widely used, but an amazing piece of software)

\- Flame and Smoke (similar to Nuke)

~~~
dtf
Definitely. Houdini is nodes everywhere. Nodes within nodes within nodes :-)

Could maybe add Softimage ICE to that list.

Also check out Grasshopper3D for procedural modelling.

Blender has a regular flowgraph for it's compositor and shading networks (and
soon for particles, I think). Plus there's the logic bricks thing for it's
game engine.

------
russellallen
Cool!

It has Morphic with a snapshot of Squeak which is fair enough but it'd be nice
to also include Self[1] which is where Morphic came from and which has I think
a nicer implementation[2] of visual programming.

[1]: [http://selflanguage.org/](http://selflanguage.org/) [2]:
[http://www.youtube.com/watch?v=NYEKO7JcmLE](http://www.youtube.com/watch?v=NYEKO7JcmLE)

~~~
ericHosick
Added self. It was hard to find a good screenshot though.

~~~
russellallen
I'll see if I can do one and send it to you.

------
VPrime
We also developed our own visual programming system for our free iPad app
GamePress ([http://www.gamepressapp.com](http://www.gamepressapp.com)). Our
system works like a flow chart of actions and events. Designed for tablets. It
is fairly powerful as well, with lots of great additions being added.

------
zachrose
It's interesting that there appear to be two main ideas: text coding but with
less typing and more syntax highlighting (Squeak), and "draw a network"
(LabView, Pure Data).

~~~
seanmcdirmid
There are actually more than a few themes:

* Structured editing environments beginning with the Cornell Program Synthesizer [1] and including environments like Alice Pascal [2], which introduced code completion (I think). You could even include Scratch in this area, though it might be more about rules.

* Data flow languages as you mentioned

* Direct manipulation environments (e.g. Morphic)

* Spreadsheet environments (e.g. Forms/3 [3], Excel, AgentSheets [4])

* By demonstration (e.g. Chimera [5])

* Rule-based systems (e.g. KidSym [6], Kodu [7], ToonTalk [8])

* ... some of the more unique systems based on other paradigms ...

[1]
[http://pages.cs.wisc.edu/~fischer/papers/synthesizer.pdf](http://pages.cs.wisc.edu/~fischer/papers/synthesizer.pdf)

[2]
[http://www.templetons.com/brad/alice.html](http://www.templetons.com/brad/alice.html)

[3]
[http://web.engr.oregonstate.edu/~burnett/Forms3/forms3.html](http://web.engr.oregonstate.edu/~burnett/Forms3/forms3.html)

[4] [http://www.agentsheets.com/](http://www.agentsheets.com/)

[5]
[http://kurlander.net/DJ/Projects/Chimera/resources.html](http://kurlander.net/DJ/Projects/Chimera/resources.html)

[6]
[http://www.sigchi.org/chi95/proceedings/papers/ac1bdy.htm](http://www.sigchi.org/chi95/proceedings/papers/ac1bdy.htm)

[7] [http://research.microsoft.com/en-
us/projects/kodu/](http://research.microsoft.com/en-us/projects/kodu/)

[8] [http://www.toontalk.com/](http://www.toontalk.com/)

------
Zenst
Nice visual snapshot or what's out there, good selection with all you need in
simple site and wiki links as well, lovely.

~~~
ericHosick
Thank you. :-)

------
reustle
I'm most excited to see some real world usage of FlowHub [0] / NoFlo [1]

[0] [http://flowhub.io](http://flowhub.io)

[1] [http://noflojs.org](http://noflojs.org)

------
phantom_oracle
Maybe this style of programming never takes off either because of inertia or
because the programmers themselves are wired to a certain way of thinking (I
am going along the lines of programmers being more "right-brained").

If you want to see visual programming pick off, try giving it to people who
are somewhat analytical but more creative (don't let programmers make your
product successful). For example, designers or even artists.

Another good way to evaluate it is to see what a designer can do with a tool
like: www.divshot.com

I have been singing this for a long time, but I think success in visual
programming (for the web) will come when you can clearly separate the frontend
and backend and let the magic happen then (meaning, see the results
thereafter).

Writing code itself won't go away, but why write code for mundane tasks
anyway? (Why write out the entire table/list display when you can simply take
a generic one and modify it with some mod tools).

The thing we all need to do though is realize that writing a lot more code
doesn't actually make you more productive (even though you may feel that way).

Also, with such technologies available, are programmers themselves not being
luddites?

------
jbranchaud
I think Yahoo! Pipes and other data mashup tools could be included in this
list.

~~~
danielsiders
And Max
([http://cycling74.com/products/max/](http://cycling74.com/products/max/))
which was its design inspiration

------
collyw
All experiences I have had with visual programming have been counter
productive, (with the exceptions of creating GUIs). I think some things are
suited to visual environments - things which need immediate feedback, other
things are not.

Think about using Unix. For copying one or two files, or renaming the, use the
GUI. Need to do the same with 100 files? I think most competent people would
naturally go to bash, and write a for loops, or small script. For these things
it is easier. (And I am fairly sure that most desktop environments have a had
more time spent on them than most visual programming "languages"). Likewise
Visual query builder in SQL can build a basic query fairly quickly and easily,
but once you know the syntax well, it is probably a lot more efficient and
powerful to use text.

------
m_mueller
The only non-text programming model that ringed a bell for me so far is
subtext[1]. I still hope someone will extend it to a complete development
environment with all the APIs needed.

[1][http://www.subtext-lang.org/](http://www.subtext-lang.org/)

------
craigching
I don't see the visual language that comes with Lego Education's WeDo robotics
listed [1]. It's a great language for teaching kids to program robots, my
daughter (who is five) will sit for hours trying to make new things with it.
It's not always robot programming, mind you, you can have it play sounds and
present images in loops as well as make robots move and sense motion.

[1] --
[http://www.legoeducation.us/eng/characteristics/ProductLine~...](http://www.legoeducation.us/eng/characteristics/ProductLine~LEGO%20Education%20WeDo)

~~~
makeset
Lego's old "RCX Code" language also not there, where sequential instructions
hung vertically off of the event "clothesline." [http://www.joschs-
robotics.de/jochen/seminar/svkohkp4.jpeg](http://www.joschs-
robotics.de/jochen/seminar/svkohkp4.jpeg)

------
drd
I think it is better to call it model-based development rather than visual
programming. Apart from those visual tools (e.g. Alice) which can be used to
teach children the programming concepts, there are serious tools such as
Simulink and SCADE (missing from the list) which are used to develop safety-
critical applications in medical and aerospace fields. The reason to use these
tools is to allow experts in other disciplines to specify an abstraction of
their designs for computer.

------
subb
Cryengine also have VPL similar to Unreal's Kismet.
[http://media.moddb.com/images/articles/1/25/24522/FG_Tutoria...](http://media.moddb.com/images/articles/1/25/24522/FG_Tutorial_img_5.jpg)

There's also Virtools by Dassault Systèmes.
[http://images.gamedev.net/features/reviews/virtools/Image1.p...](http://images.gamedev.net/features/reviews/virtools/Image1.png)

------
dimitar
Most of those languages even look like imperative (flowcharts) or object-
oriented code (objects connected by wires).

If someone is in a such project it might be a good idea to show what are the
benefits over looking at code beside subjective aesthetics.

For example ladder logic and LabVIEW look like a wiring diagram, which is
excellent because their niches are electrical engineering. Minecraft is
excellent as a game developing platform because you see the game you are
developing right away.

------
ken_railey
Great list, thanks for putting this together!

My own project ([http://flowlab.io](http://flowlab.io)) is a visual
programming language for 2d games.

------
vinodkd
Here are some more:

1\. [http://slidetocode.com/](http://slidetocode.com/)

2\. Thyrd: Which combines spreadsheet and infinite zooms in a very interesting
way. [http://thyrd.org/thyrd/](http://thyrd.org/thyrd/). Some screenshots are
at [http://thyrd.org/thyrd/paper/](http://thyrd.org/thyrd/paper/), but the
video works better to understand it.

------
t1m
Another one that is missing is Touch by Derivative
([http://www.derivative.ca/](http://www.derivative.ca/)). This is the language
that Plastikman, NIN and Rush use to power the video projection, lights,
smoke, etc in their live shows. It is not unlike Max/MSP, but has amazing
video playback and projection, and supports lots of external devices.

------
jmyc
HyperCard could be added to the list

[http://arstechnica.com/apple/2012/05/25-years-of-
hypercard-t...](http://arstechnica.com/apple/2012/05/25-years-of-hypercard-
the-missing-link-to-the-web/)

[http://en.wikipedia.org/wiki/HyperCard](http://en.wikipedia.org/wiki/HyperCard)

~~~
evanspa
It is.

------
bokchoi
Gem Cutter for Open Quark CAL:

    
    
      http://openquark.org/
      http://en.wikipedia.org/wiki/Quark_Framework
      https://github.com/levans/Open-Quark
      http://resources.businessobjects.com/labs/cal/gemcutter-techpaper.pdf

------
haddr
Great work! +1 for including minecraft :)

------
simonster
I'm pretty sure the HyperCard screenshot is not actually a screenshot of
HyperCard, but a screenshot of an early Mac control panel. In the link it
seems like it's an example of what things looked like on the machine on which
HyperCard was originally written to run, not HyperCard itself.

~~~
ericHosick
I'm looking and it is hard to find a good example. Something like this maybe?
[http://www.mactech.com/articles/mactech/Vol.03/03.10/HyperCa...](http://www.mactech.com/articles/mactech/Vol.03/03.10/HyperCardProgramming/img003.gif)

~~~
BlackFingolfin
You can find plenty of screen shots of HyperCard applications (or rather,
"stacks", as they were called) by using Google image search.

But HyperCard wasn't really a visual programming language. Indeed, it wasn't a
language at all (the language is called "HyperTalk"). Anyway, HyperCard did
allow you to design user interfaces in a slick visual way. But the code is
purely text based. You can see example code at the HyperTalk wikipedia page

------
RamiK
Was mentioned in the article, but often overlooked. Drakon is an old school
FOSS diagrams-based visual-editor that outputs C (and Java, C#, Erlang...):

[http://drakon-editor.sourceforge.net/](http://drakon-editor.sourceforge.net/)

------
Serow225
Very nice! I see you've got Simulink, but you could consider adding the
associated state machine editor Stateflow:
[http://en.wikipedia.org/wiki/Stateflow](http://en.wikipedia.org/wiki/Stateflow)

------
swalsh
Very cool! My current project at my day job is a visual programming language
designed for automated testing using our hardware, and apps. So its great to
find some inspiration for ways to improve our product.

------
pan69
I think Macromedia Authorware was pretty big for a while:
[http://en.wikipedia.org/wiki/Macromedia_Authorware](http://en.wikipedia.org/wiki/Macromedia_Authorware)

------
bitcuration
However, now it's time seriously think about programming robots. I want tell
computer what I want to do and the computer shall figure it out by itself,
including writing code.

------
lekanwang
Max is also a popular visual music programming system
[http://cycling74.com/products/max/](http://cycling74.com/products/max/)

------
z3phyr
You should add Nengo [http://www.nengo.ca/](http://www.nengo.ca/), since it is
one of the forefronts in neuromorphic engineering

------
zacinbusiness
Would Sikuli count here? I fully expected to see it mentioned.

(www.sikuli.org)

------
MarkTee
I think Alfred's Workflows would fit in here.

[http://support.alfredapp.com/workflows/](http://support.alfredapp.com/workflows/)

------
agersant
Automgen
([http://www.irai.com/a8/a8asi_e.pdf](http://www.irai.com/a8/a8asi_e.pdf)) is
another one.

------
FollowSteph3
And this is why you don't interrupt a programmer in the zone, all that
graphical representation has to be in your head

------
meerita
This list is amazing. To experienced programers, what it's like to make a
serious project using any of these?

------
SimpleXYZ
I'm a huge fan of Sikuli (sikuli.org). It's a little clunky but the concept is
pretty powerful.

------
NAFV_P
App Inventor for Android looks a lot like the interface used in that "code for
an hour" idea.

------
narag
Thank you for putting all this together. Very interesting!

------
weixiyen
<3 Quartz Composer

------
forgottenpaswrd
Bret Victor's?

[http://vimeo.com/64895205](http://vimeo.com/64895205)

The stupid Discus thing they use does not let me comment(What a terrible UI).

------
madengr
What, no LabView?

------
jackmaney
Maybe it's just me, but I find it way, way, WAY harder to see what's going on
in those screenshots than it would be if I had actual code to look at.

~~~
dandelany
It's not just you, I've heard this before, but I personally don't agree.
Obviously it's very subjective and depends on how you learn/think - I'm a
visual person so these types of environments have always made a lot of sense
to me.

Also, don't forget that most of the complicated-looking ones are showing a
large program - the equivalent of hundreds of lines of code. Just like you to
see a portion of code on your screen at any given time, to work on these you'd
zoom in to the relevant portion.

------
greatsuccess
All I can say about this is thank you.

