We already have "visual" languages.
Visual Basic
Visual C
Visual C#
( to name a few )

*facepalm*

Visual languages have been tried, and the consensus is they quickly become too unwieldy for anything but the most trivial of programs.
Note: "visual" as in Visual Basic and Visual Studio is a marketing term, and has nothing to do with "visual programming"
ing language" is Turing Complete, but what's the point?

by visual, i didn't mean vb or vc++ etc. like shippou listed. I noticed that "they quickly become too unwieldy" part a lot while searching the net and LabView appeared a lot. One other thing i also noticed is that they are usually regarded as tools meant for beginners and not for actual programming and professional work.
I hope my approach won't be nearly similar.

We already have "visual" languages.

*facepalm*

Those have drag - and - drop mechanics that take 95% of the work out of building a GUI

Those have drag - and - drop mechanics that take 95% of the work out of building a GUI

That's a feature of the IDE, not the language. What you listed are names of Microsoft applications, not programming languages.

by visual, i didn't mean vb or vc++ etc. like shippou listed. I noticed that "they quickly become too unwieldy" part a lot while searching the net and LabView appeared a lot. One other thing i also noticed is that they are usually regarded as tools meant for beginners and not for actual programming and professional work.
I hope my approach won't be nearly similar.

I know you didn't mean vb. My comment was meant for shippou.

There are some areas where a visual representation of data flow is useful. The new Unreal Engine uses this kind of thing to allow artists to create particle and material effects. Skip to about 3:20 to see this in action. It works reasonably well for purely functional languages dealing with small discrete sets of functionality, but I don't see it ever taking off for a general purpose programming language.

By visual languages, I'm assuming you mean languages like CODE, Drakon, Simulink, or Toontalk. As for my view on them, I don't have one because when I need a language I learn it and use it, but otherwise I don't stress over it.

I program in LabVIEW for my job

LabVIEW kicks butt at interfacing with National Instruments (NI) hardware (NI makes LabVIEW) For anything else, it is usually not the best choice. It doesn't really simply a whole lot - you still typically have to use loops/branching/case statements. Block diagrams can quickly turn into a mess Yes the obvious thing is to make sub routines, but sometimes this is a pain when you have to query or update something a control the GUI, it involves making a passing a control reference to the subVI (like a subroutine, function, method, etc.) It has OO, but last I looked I didn't like what I saw

The only potential advantage for visual programming I can see, is that it can make parallelism much easier. The flow chart does not impose order except for what you wire. LabVIEW is relatively strongly typed and passes arguments to its subroutines by value based on (there are references, but not as easy to use). But in making parallelism easy, it also creates problems such as unintentional data copying.

For whipping up a quick GUI though, its pretty awesome compared to other solutions I have come across

I made a post about node based programming. And I do think this is the age for it to get big in, with touch screen so popular.

I have been using the gamepress app more often now to prototype games. The node based system it uses is awesome, and what would take pages and pages of code takes only a matter do minutes to do using that system.

I program in Labview too in my work. It's pretty visual and I think it's suited for professional programming too. Parallelism (multithreading) becomes quite easy with Labview. It's said to be an easy tool and that no programming experience is needed, but I don't think that's true. Programming experience (in "project level" too) is needed very much. Otherwise you'll end up with a mess, bugs, all kinds nested loop related control issues with their nasty workarounds. You'll need state machines; events; you need to know what's passed by value, what's by reference; etc. Stuff you can't really just figure out with no experience.

Thanks szecs for that mention, going to check out labview when I get a chance to add it to my collection of node based programming information. I only saw the first few seconds of the video.