[analog31]

I did a fair amount of work with LabVIEW long ago. I also played with another visual language for the Mac that was floating around in the 90s. This isn't a slam against LabVIEW, which would be unfair in any event since it's been that long and their product has changed a lot.

Advantage: It seemed easy for beginners to learn how to do simple things, such as sequencing the operations and measurement in a lab experiment or instrument prototype. That's pretty cool.

Disadvantages: 1) For me, I happen to suffer from severe eyestrain and wrist / neck fatigue when dealing with tiny graphics and fine mouse work. I would not be able to program a graphical language all day.

2. My impression that it's hard to modify / refactor code because of the laborious manual effort needed to move graphics around. Programs tend to become unwieldy when they expand beyond one screen.

3. I think that text is the easiest and quickest way to prototype a new programming language idea, and there is rapid evolution and proliferation of both text based languages and programming tools like specialized editors and environments. It's also easier to port a text based language to a new machine. I think that evolution would be slower if people had to develop a graphical framework to try out a new language. It's also very easy to share source code, either full programs or snippets, on the Internet via text, even across different languages with a bit of manual translation.

[DonaldFisk]

1. Not all visual languages are the same, just as not all text-based languages are the same. The main problem is there aren't many in widespread use, and they tend to be quite specialized, so you might not find one which you're completely happy with.

2. Programs, or rather functions/procedures/subroutines should, with very few exceptions, be displayable on a single screen. If they are larger, they should be split up. This applies whether the language is textual or graphical. Moving graphics around should make no difference to how a dataflow program executes.

3. Yes, it's easier to develop a new text-based language, because so much research has been done on them, and you don't need to develop an editor along with the language. But there are hundreds in active use, which are constantly evolving. If you want a new set of features, you can add it to an existing language or create your own dialect. Visual code must have either a text or binary representation of the source which can be shared. It may not be human-readable but that's not the intention.

[darkmighty]

1) I think although LabView is quite useful, it's interaction design is terrible (that users play along only attests to it's utility!)

3) It's essentially a way of displaying code, so perhaps any new languages could reuse the same graph/flowchart environment. But inherently visual languages are designed either towards people who don't want to learn a language or who are performing specific tasks where the graphic flow improves their reasoning. I'd say for the vast majority of 'coding' those are not the case, since the "concept density" is very low (but visual UIs may help a lot of get started programming people anyway).

Having a graphical environment also helps remove a lot of cruft from languages that newcomers shouldn't really have to deal with.

For example, if I want to make a C program to computer the distance between tow points on a plane, I have in my head something like "d=sqrt((x1-x2)^2+(y1-y2)^2); output d", and actually programming I'm going to have to import a couple of libraries to take care of both floating point arithmetic and IO. The only way a novice can know that is looking at an online reference basically; while a decent UI could easily provide a searchable list of math/IO functions and include libraries automatically. Those are always taken care of in visual programming languages. The syntax itself of languages is arbitrary in many ways you have to learn on a case by case basis (in the example, how exactly do you use printf to "output d"?), while in an UI you are forced to use the correct syntax, because it's the only option.

When you are programming an operating system or low level application none of those really matter, but for a newbie making a simple Mobile app it's going to involve googling a lot and copious amounts of copy-pasting templates for getting trivial things done.

[analog31]

Those are valid points. My first language, BASIC, didn't require libraries. You could just enter those two statements and it would figure out the libraries and types required, from the context. It was my understanding that the additional "overhead" of C is to direct the compiler to make more efficient code, and to head off certain kinds of failures of larger programs.

But still, I think your point stands. The tools that beginners like to use, whether the underlying "language" is represented by text or graphics, tend to be fairly self contained with zero overhead and a built in lookup system for library functions and user interface design, and those systems tend to be implemented as graphical software.

[seanmcdirmid]

Code completion evolved from a graphically structured language, AlicePascal, for this reason. We've been adding visual features into our text based lnaguages via tooling for quite some time.