Interesting topic on Lifehacker visual vs text programming.

[Jordan Kuehn]

Found this today.  It's interesting to me to read what non-labview people have to say about it.

 

http://lifehacker.com/im-curious-what-are-everyones-opinion-on-visual-vs-w-1442104740

 

Edit// It tends to slide into discussions about HTML/CSS style visual editors after a bit.

[Val Brown]

Yes, it's interesting.  The basic argument against visual IDEs is: "I grew up using text-based coding and so it's easier for me."  While that observation may well be germane for the individual, it really is fairly ludicrous as a general statement.  It would be like saying: "I first learned to program FORTRAN so, if I really want to get the job done, I'll go back to what I know".

 

The Big Battleship Admirals resisted Aircraft Carriers even Torano, sinking Bismark and the other German Capital ships, as well as Pearl Harbor.  Data rarely convinces -- it frequently just hardens the arteries and attitudes.

[Jordan Kuehn]

That and seeing the topic shift toward visual IDEs that generate text code (HTML/CSS/etc.) are fundamentally different from LabVIEW but it seems to be the way that people view LV.  Visual == bloat in many minds.  Or the past marketing has limited the scope of LV in peoples' minds to just DAQ and R&D.

[Val Brown]

I think it's all of that and more.  Even when embracing some aspect of the new the beliefs and commitments almost demand that there is a return to the familiar. So no matter how easy, intuitive, fluid, capable, amazing the visual IDE, until it can generate text-based code it means nothing -- because text-based code is REAL programming....

[MikeC3]

I've been doing LabVIEW almost exclusively for the past two years, after coming from a C++/Perl based development team (with a smattering of other languages thrown in there too, including LabVIEW).  And coding in LabVIEW just feels different from coding in a text based language.  I don't think that coding on either side really feels like work, but LabVIEW feels more like a game to me.  Maybe it's all the mousing, since I tend to like mouse heavy strategy games.  Just line up your functional armies and march towards the tunnel .  I consider this a huge benefit, since it helps me like my job, but I can see how others have a hard time seeing it as a "serious" language, when it's all pretty pictures with lots of colors.  "Programming by cartoon" as my perl and python co-workers called it.

 

Another part of the difference for me is just how different the sound of coding is.  Intense bursts of keyboarding vs click-drag-release.

 

Also, my co-worker has a USB hamster wheel that is supposed to spin faster as you type faster.  Just doesn't do much in LabVIEW.

[Val Brown]

Right.  LV is "coding by cartoon" but text based is actually "coding by typewriter".  So you're using technology (viz the layout of the keyboard) that was standardized in the 1920's specifically to SLOW DOWN typists -- so the mechanical typewriters of the day wouldn't jam.  No one is even using the Dworak keyboard arrangement (http://en.wikipedia.org/wiki/Dvorak_Simplified_Keyboard), which was at least developed in 1936.

 

That all DOES seem much more advanced than having fun and "coding in cartoons", doesn't it?

[hooovahh]

Also, my co-worker has a USB hamster wheel that is supposed to spin faster as you type faster.  Just doesn't do much in LabVIEW.

Speak for your self.  I am a no-Auto-Tool kinda guy so while my mouse is moving to the new position my left hand is repeatedly mashing Tab, CTRL+E, CTRL+W, CTRL+S, Quick Drop (CTRL+D for me), and all the Quick Drop short cuts.  I've been nicknamed the "Certified Keyboard Finger F***er".

 

Most will not admit that they don't like visual programming because they didn't grow up with it.  Most will make up some other excuse so to not sound so suborn.  If they do admit that they don't like it because it is unfamiliar, then I think something can be said about new developers who have never programmed anything and see which the majority pick up faster.  When you have 8 year olds developing MineStorm robots I think we can agree that visual programming is easier to pick up.

 

I've also had others say they don't like LabVIEW because they don't know what the compiler is doing.  And I ask them what the compiler in C is doing?  What assumptions or optimizations is it doing?

 

EDIT:  Do we have a curse word filter on LAVA?  We can swear on the internet right?

Edited October 10, 2013 by hooovahh

[Jordan Kuehn]

One thing that annoys me is the "I know 5000 languages and can pick up any other in seconds, but visual languages suck" 'argument' I see around.  While syntax is generally independent of style and architecture, it feels like at best the argument from a freshman CS major who is 'proficient' in one language.

 

In the thread linked, I also find humorous the argument against visual languages the fact that the 'skilled' programmer cannot simply search sourceforge (or the like) to find code to copy/paste and piece together what he/she wants to accomplish.  While perhaps a valid argument against the accessibility of LabVIEW, at least have the decency to say that you're a hack rather than a programmer.

[Val Brown]

One thing that annoys me is the "I know 5000 languages and can pick up any other in seconds, but visual languages suck" 'argument' I see around.  While syntax is generally independent of style and architecture, it feels like at best the argument from a freshman CS major who is 'proficient' in one language.

 

In the thread linked, I also find humorous the argument against visual languages the fact that the 'skilled' programmer cannot simply search sourceforge (or the like) to find code to copy/paste and piece together what he/she wants to accomplish.  While perhaps a valid argument against the accessibility of LabVIEW, at least have the decency to say that you're a hack rather than a programmer.

 

Yes to your first point and also yes to your second; however, one can hack around the LabVIEW community pretty well too.  Search the CR here or the NI website, or, or, or and there are plenty of sources from which one can utilize already developed toolkits, code samples, etc.  This allows you to see good coding techniques -- as well as some less than optimal ones -- and also come to understand licensing arrangements, etc.  Not to mention start up some very good collegial relationships.  

[Jordan Kuehn]

http://developers.slashdot.org/story/13/10/18/0038237/has-flow-based-programmings-time-arrived