what different between labview and other programming languages?

[egilbro]

what different between labview and other programming languages like c or c++ ?

 What makes me chose it ??

[aputman]

I'm sure there are a lot of articles about this topic.  Here is one.  Do a little legwork on your own and you'll find out very quickly.

http://www.ni.com/newsletter/51675/en/ 

[egilbro]

thank you for help

[PaulG.]

Ignore the article "why I hate, despise, detest, and loathe LabView." It was written by someone who had no idea what he was talking about. Some programmers just don't "get" LabVIEW. It requires a different way of thinking than a text-based language. I think they find that frustrating. But the problem is the programmer, not the language.

[egilbro]

Dear PaulG..

               Thank you for the wonderful words

               We have to accept the speech even if it is criticism or praise

[palanivel]

Hi egilbro....
The main difference according to me as a LabVIEW developer is as follows:
Readability is efficient..
less development time
graphical language which provides interest in development..

Even C C++has its own advantage but as a Automation engineer LabVIEW plays major role than C C+++

It's my opinion.........

[natasftw]

---

@egilbro wrote:

Dear PaulG..

               Thank you for the wonderful words

               We have to accept the speech even if it is criticism or praise

---

I think you missed the point of his argument.

Let's take two arguments against peanuts:

1)  They're stupid and look funny.  I don't think they'd taste good.

2)  I'm allergic to peanuts.  No matter how amazing they taste, they're not worth my life.

We can all see validity in the second argument.  It makes a rational point.  We should take that into consideration.  The first argument is nonsense.  If you didn't know better, it could sound reasonable.  But, it's not a valid argument.  The article he referenced is similar to that.  If you don't know much about LabVIEW, the points may sound like they make sense.  But, the argument is entirely nonsense.  It contains such gems as "the code isn't commented so it's impossible to read."  That's true of some applications in both LabVIEW and text-based languages.  It's the fault of the programmer in either case.

You NEVER have to accept a terrible argument.  This is also true when it agrees with your decision.  You should break yourself of this idea now.  Let me give you a programming analogy to the statement you made:  We must accept x = y + 0 - 0 *1 /1 *x/x as a good way to assign the value of y to x as good code.  Just because you wouldn't program like this doesn't mean it's bad programming.

[JÞB]

---

@egilbro wrote:

what different between labview and other programming languages like c or c++ ?

 What makes me chose it ??

---

I could go on for pages about my experience programming in various languages and various methods of programming.  I started with punch cards and a 77 Baud Terminal  on a Plato II, moved through Apple Basic, Pascal, Turtle Logo, C/C++ and LabWindows CVI.  Along the way I even learned to read a paper tape with Baudot code.  Each had their advantages at the time (Turtle Logo -- Whatever could be done in Turtle logo?  Well, I once wrote a smart "Othello" game that was <2kBytes in Turtle Logo)

All of that changed in 2001 when I started using LabVIEW.  Its a language with a higher level of abstraction than those other first second and third generation paradigms.  It allows me to program without thinking about the Silicon (or Vacuum tubes in earlier cases) What I write for one processor works on another what I write for one OS works cross platform - without changing compilers! (Granted that are Windows Features that can't port to Mac - thats Apple's fault for not having those hooks not LabVIEWs limitation)

LabVIEW Employs a Different programming paradigm, Dataflow.  Once understood, Dataflow programming is intuitive.  Better, If you absolutly NEED to "Break Dataflow" LabVIEW offers methods to shift paradigm with Events, Queues, Local Variables, Semaphores....Try enforcing a shift away from sequential flow to Dataflow in a text based language.

LabVIEW has a Graphics based development enviornment (or more correctly LabVIEW IS a graphic based Development envionment for the G Language but, that's splitting hairs)  the realative information density between graphics and text has been known for eons and Graphics wins in a landslide.  Examples: Cave paintings, Heiroglphys, Petroglyphs, Mosaics, Stained Glass windows, modern signage (do you walk into the wrong gendered washroom in any language?) So, the Block Diagrams I write in the United States Midwest are just as readable in Guadalajara, Taipei, Kuala Lampur, Dresden or Kiev! to name a few places some of my work product may be found.  (Do THAT with C#!)

I'll stop there.  but go ahead and look at the reasons HERE as well

[mikeporter]

Jeff's last point is excellent. Most people don't think about it but to write code well in most text based languages you have to be able to, on some level, understand English. For example if you understand English you can sort of figure out what a function called "printf" might do because you recognize the English word "print". But to someone who has no knowledge of English it's just an unintelligible jumble of symbols.

However with pictrues you don't necessarily have that problem. People can, and do, choose to type words on incons but the code at its lowest level is pictorial using a common graphical lexicon.

Mike...

[palanivel]

In addition to the above list I just wanted to list one more point...
syntax is not a big deal in LabVIEW. Even if any mistake LabVIEW will point you the exact place to correct....