Visual Programming Languages – Snapshots

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...

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.

NKCSS• 12 years ago

I was going through the list, expecting WWF, only to find that it's the last one there :)

haddr• 12 years ago

Great work! +1 for including minecraft :)

zachrose• 12 years ago

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).

seanmcdirmid4• 12 years ago

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

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

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

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

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

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

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

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

marcosdumay• 12 years ago

There are a few that use graphs and time lines to actually apply visual elements to programming. Those may be good for something.

For the ones that simply replace text with flow, and aren't aimed at small children, I only have pity.

zacinbusiness• 12 years ago

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

(www.sikuli.org)

canjobear• 12 years ago

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...

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

invalidOrTaken• 12 years ago

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.

Permit3• 12 years ago

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-...)

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) 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.

ericHosick11• 12 years ago

I would really like to chat with you about code connect and get your thoughts. My email address is in the post.

ibdknox2• 12 years ago

It's been done a few times before :) For example, check out the debugger canvas: http://visualstudiogallery.msdn.microsoft.com/4a979842-b9aa-...

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.

Permit3• 12 years ago

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.

seanmcdirmid4• 12 years ago

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,

I think this has more to do with our conventional debugger interface being so horrible, that anything is an improvement. When debugging, I want my code ordered temporally in terms of how it is executing. Code bubbles give us that, but a 1D editor solution might still work better if the code can be dynamically reorganized.

and debugging is an inherently mouse-oriented task - all the things you need for a zoom-based infinite canvas to work out.

It doesn't have to be, that's just what we have to work with at this point.

russellallen2• 12 years ago

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/ [2]: http://www.youtube.com/watch?v=NYEKO7JcmLE

ericHosick11• 12 years ago

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

russellallen2• 12 years ago

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

muyuu• 12 years ago

It's historically important but frankly I believe Self is a very flawed language in several respects for anything other than prototyping.

Smalltalk has aged much better IMO regardless of it's relative market irrelevance.

BlackFingolfin2• 12 years ago

I don't understand why Squeak or Self (with or without Morphic) would be considered visual programming languages. Don't get me wrong, I think Morphic is a pretty slick system, but still... Perhaps because it was not made quite clear what is considered to be a "visual programming language".

Based on what is in this list, though, it would seem to me that e.g. the combination of "Objective-C and InterfaceBuilder" could also be added to the list, which feels silly.

valarauca13• 12 years ago

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/

ericHosick11• 12 years ago

Ya. My Bad. I've added a better screen shot.

valarauca13• 12 years ago

Your better screen is the second image in the article I linked.

joelthelion2• 12 years ago

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.

jimbokun4• 12 years ago

"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.

jackmaney• 12 years ago

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.

dandelany2• 12 years ago

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.

ericHosick11• 12 years ago

I think very domain specific visual programming environments work well: music, 3d modeling, etc.

However, for the ones that try to be domain agnostic, they don't seem to work so well.

dandelany2• 12 years ago

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.

benbeltran• 12 years ago

Yes! The guy that made Max eventually made PureData (which is in the list). It's an awesome environment. Max (General) with MSP (Audio) and Jitter (Video) can do a lot of stuff, even control full lighting rigs + video, or even have a nice visual interface to an arduino. They recently integrated with Ableton Live too so you can use MSP patches as instruments. It's a great platform.

s_kilk• 12 years ago

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.

jmyc• 12 years ago

HyperCard could be added to the list

http://arstechnica.com/apple/2012/05/25-years-of-hypercard-t...

http://en.wikipedia.org/wiki/HyperCard

evanspa2• 12 years ago

It is.

Serow225• 12 years ago

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

lekanwang• 12 years ago

Max is also a popular visual music programming system http://cycling74.com/products/max/

ken_railey• 12 years ago

Great list, thanks for putting this together!

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

troymc3• 12 years ago

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.

pandler• 12 years ago

There are distinct differences between (1) visualizing a program (e.g. light table), (2) using a visual interface to generate the underlying (e.g. XCode Storyboard), and (3) a "language" whose primary or sole mode of "programming" is visual (e.g. LabView).

Can't we dispense with the notion of a "visual programming language"?

In most cases I agree that label is a misnomer, but I think something like LabView genuinely does fall under the category of a visual programming language.

Renaud• 12 years ago

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.

troymc3• 12 years ago

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)

bergie• 12 years ago

NoFlo has a textual format as well as the visual one seen on the article: http://noflojs.org/documentation/fbp/

ericHosick11• 12 years ago

If you really get to thinking, programming is all about abstraction. We talk about abstract concepts like functional programming, object oriented programming, structured programming, objects, functions, methods, inheritance, etc. But, in the end, it's all just playing around with stack pointers, instructions and malloc.

As Permit points out here (https://news.ycombinator.com/item?id=7274956), a large part of a programmers job is to build a "mental model of their program".

We abstract things and come up with constructs to represent these abstractions to make it easier for us to program a computer: to improve on our mental model.

So, we come up with different programming languages and label them by their approach. This is a functional programming language, this one is declarative, this one is procedural and this one is visual.

My 2 cents.

dinkumthinkum2• 12 years ago

No I think you're being sort of outlandishly ridiculous .... just to be honest. You would have us not allow for any sort of classification of programming languages then because they are Turing complete.

troymc3• 12 years ago

It's fine to classify programming languages. It's not fine to get confused between a programming language and a way of representing a particular program.

For analogy, there's only one true physical Earth, but there are many possible maps (representations) of the same area: one showing the temperature at the surface (using color), one showing wind direction at various points, one showing roads, etc. Which map is correct? Which map is best?

spyder• 12 years ago

I agree, they should be called "visual programming environment"

agumonkey3• 12 years ago

To me it's neither of them. I don't know how I'd call that, semantic .. ontologic ? The 'text' is as much an interface to the abstract model as the 'visual'.

When I see repls with sophisticated real-time output representation it's as much visual as dataflow programming by connecting nodes to an output sink.

Brett Victor's work is bringing them even closer since usually dataflow/reactive was used in mathematical settings (time varying scala or scalar arrays... image or sound) but he demonstrated far more the benefits in non linear logic (games).

It's the disconnected, char per char ascii, file saving, build time, run time tradition that creates an artificial segmentation.

chevreuil• 12 years ago

Relevant Bret Victor video : https://vimeo.com/66085662#t=9m20s

gruseom• 12 years ago

Your argument is really that syntax is nothing and semantics everything. I sympathize, but it's not how most people see it.

As long as we accept syntax as a significant part of what defines a programming language, "visual language" is a reasonable concept.

Edit: Reasonable implementations are another matter. :)

twelvechairs• 12 years ago

This is exactly why most 'visual programming languages' don't take off - because they fixate on a single means of repreaentation - which will never cover all use cases (and text representations can cover the same territory just as well) rather than doing what they should do - allow varied representations of programs.

vorg• 12 years ago

Yes! All language, whether natural or programming, can have two primary structures: semantic and thematic (these are terms from Linguistics). Thematic structure (very roughly) refers to the effect of the writer, the medium, and the reader/s, which explains why one semantic structure can be represented in a variety of ways.

NAFV_P3• 12 years ago

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 C was represented in an olfactory manner my code would be deemed a bio-hazard.

aaronem• 12 years ago

Certainly lends new meaning to the concept of "code smell".

coldtea• 12 years ago

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"?

Yes. But that doesn't say much.

Visual programming languages don't just naively show some token graph. You can get that with a parser and a graph library for any language with half a day's work.

It's about the interaction models they explore, the levels of abstraction, and the tools they offer.

What you say is like getting rid of the notion of writing, since everything that can be spoken can be also written.

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

It very much does. For a visual language it's syntax was designed as a set of drawn objects to be manipulated. That probably also influence its very semantics.

Quartz Composer: A Visual Language.

C: Not so much.

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"?

No, it just means that it also has a smell-based representation (that is impractical and noone uses). On the other hand, visual programming languages were pragmatically designed to work in a visual environment, and enable coding by the manipulation of graphical elements.

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.

A visual programming language is not about a mere representation. It's about the core way the syntax is expressed to the programmer.

What you say is like "there are no declarative, logical or functional programming languages because everything is imperative at the assembly level anyway".

Well, the level at abstraction at which the programmer is supposed to work with a language (the language's syntax) is important, even if the code can be represented in a different way. Interfaces (in the UI sense) are important.

jimbokun4• 12 years ago

"What you say is like getting rid of the notion of writing, since everything that can be spoken can be also written."

I think this analogy works better for the original argument, as pretty much any sentence can be either written or spoken. There's nothing about English restricting it to be only a written or only a spoken language.

jimbokun4• 12 years ago

The project I work on has a custom querying DSL, and recently we have been working on a visual query builder for this language. So this is a very concrete example of a language with both a textual and visual representation.

Of course, keeping fidelity between both representations can be a challenge. Our design could be improved by being more diligent in sharing the same underlying model for both.

I imagine there are other cases like this, where you have a visual tool for building expressions for some textual language.

(Are there SQL tools like this? Seems likely there would be.)

aufreak3• 12 years ago

At its core, a programming environment provides a link between a formal system and some aspect of our world. You could think of a general purpose Computer as providing a link between any formal system and the aspects of our world that it ties int, but we can limit ourselves to programming environments for simplicity of discussion.

With that perspective, we can ask what representations of a formal system do we find easy to manipulate in ways that produce results that are significant for us (in a specific problem context).

A visual representation would certainly be a better match for a spatial problem domain (Sutherland's work, for example). Similarly, an audio representation can work well for an audio domain (ex: beardyman's realtime performance system he presents in his ted talk). Likewise, I'm quite sure a system for exploring cuisine art would match a "smell representation".

The notion of a "universal turing machine" guarantees that all of these representations can be mapped to that of a symbol stream. That is a mathematical result, but which representations appeal to humans involved in various kinds of work is not a mathematical question - it is a HCI question.

MSF2014• 12 years ago

(1) Look at CPWCT, a visual programming language (based on the C programming language, and developed/used inside Programming Without Coding Technology (PWCT) See this online movie to get quick idea without downloading the software : http://www.youtube.com/watch?v=461iVUl08mQ&list=PLpQiqjcu7Cu...

When you see this movie you will discover the difference between a Visual Programming Language like CPWCT and a text-based programming language like C

(2) When we use a text-based programming language, think of this using ( command-line / terminal ) of the operating system instead of using the GUI to do your tasks.

(3) Designing a visual programming language is an art (more complex than designing a text-based programming language) because the user interface of the visual language is more advanced.

(4) Using a Visual Programming Language, we can see the visual representation text in natural language (English, French, any other language) and we can change the visual representation and we can allow the programmer to change the visual representation (not easy to allow the programmer to change the syntax of a text-based programming language, we can do this, but the programmer will need to recompile the lexical analysis program, and it will be another language that can't recognize programs that are written using the old syntax, while in visual language we can allow this customization and we still open any programs create before or after this customization).

(5) We can add more dimensions to the visual programming language (like the time dimension). this dimension is not known to text-based programming language. you can move forward/backword during application construction process, and you can run programs in the past, you can see a movie of how to create the program step by step

See this movie : http://www.youtube.com/watch?feature=player_embedded&v=wpxbf...

weixiyen• 12 years ago

<3 Quartz Composer

reustle• 12 years ago

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

[0] http://flowhub.io

[1] http://noflojs.org

pan69• 12 years ago

I think Macromedia Authorware was pretty big for a while: http://en.wikipedia.org/wiki/Macromedia_Authorware

agersant• 12 years ago

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

cswetenham• 12 years ago

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 [2] http://www.old-games.com/download/3399/widget-workshop

renownedmedia• 12 years ago

Widget Workshop is what got me into computers!

pirateking• 12 years ago

I have very fond memories of Widget Workshop as a kid. Glad to see it mentioned!

evanspa2• 12 years ago

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...

madengr• 12 years ago

What, no LabView?

swalsh• 12 years ago

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.

jbranchaud• 12 years ago

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

danielsiders• 12 years ago

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

hayesdaniel• 12 years ago

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)

Nzen• 12 years ago

I'm glad some have taken the 3D tack. The neattools network was pretty imposing because it was so compact. Perhaps it would behoove the designers to pair a visual language with an oculus rift and 3D mouse to take advantage of the flexibility their medium offers over text.

agumonkey3• 12 years ago

Ha, I had the exact same idea on its disqus comment thread.

dtf• 12 years ago

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.

VPrime• 12 years ago

We also developed our own visual programming system for our free iPad app GamePress (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.

bitcuration• 12 years ago

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.

dethstar• 12 years ago

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/ 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.

ericHosick11• 12 years ago

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).

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.

z3phyr• 12 years ago

You should add Nengo http://www.nengo.ca/, since it is one of the forefronts in neuromorphic engineering

simonster• 12 years ago

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.

ericHosick11• 12 years ago

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...

BlackFingolfin2• 12 years ago

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

MarkTee• 12 years ago

I think Alfred's Workflows would fit in here.

http://support.alfredapp.com/workflows/

NAFV_P3• 12 years ago

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

greatsuccess2• 12 years ago

All I can say about this is thank you.

dimitar• 12 years ago

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.

t1m• 12 years ago

Another one that is missing is Touch by Derivative (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.

meerita• 12 years ago

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

exDM69• 12 years ago

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.

narag• 12 years ago

Thank you for putting all this together. Very interesting!

forgottenpaswrd• 12 years ago

Bret Victor's?

http://vimeo.com/64895205

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

collyw• 12 years ago

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.

RamiK• 12 years ago

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/

FollowSteph3• 12 years ago

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

jcromartie• 12 years ago

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.

seanmcdirmid4• 12 years ago

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

jimbokun4• 12 years ago

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.

CmonDev• 12 years ago

Agent Model is even more interesting IMHO.

TeMPOraL• 12 years ago

Yup. My first reaction to this:

http://blog.interfacevision.com/assets/img/posts/example_vis...

was 'omg, lisp displayed with TreeView; and let me guess what the serialization format of this is' (probably XML).

subb• 12 years ago

Cryengine also have VPL similar to Unreal's Kismet. http://media.moddb.com/images/articles/1/25/24522/FG_Tutoria...

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

vinodkd• 12 years ago

Here are some more:

1. http://slidetocode.com/

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

drd• 12 years ago

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.

m_mueller• 12 years ago

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/

bokchoi• 12 years ago

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

craigching• 12 years ago

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~...

makeset• 12 years ago

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

SimpleXYZ• 12 years ago

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

phantom_oracle• 12 years ago

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?

Visual Programming Languages – Snapshots

Related Stories