Presentation - Why LabView is better than C++

[lavalava]

Both LV and C++ originated from C language but the differences are day and night obvious.  You will need to weight in your decision based on the industry you're working in.  If you're working in IT, then most likely LV isn't the way to go but for most engineers, they're man best friend.  If you ever tune into the History or Discovery channel late night show "Modern Marvel" you'll find LV being used in just about every field of disciplines when it comes to engineering.

Pro:

- For every 1sec you spend you LV, you'll most likely spend about 30s doing the same thing in any text based language even if you have GVIM installed.

- Very easy learning curve means your manager don't need to spend money to send you to school.  

- More visibility (bling-blings) to your end production.  

- Talking to test instruments via VISA protocol is a peezza cake.  Just too easy.

- Scientific computation is a lot easy to work with, even easier than Matlab.

Con:

- You'll need very big monitors, recommended that you get yourself 2x30" running at full blast resolution of 2560x1600

- Multithreading in LV isn't quite easy and neither does LV support true concurrency like the one you find in C++.

- LV is expensive but still a lot cheaper than Matlab.  Whereas C++ doesn't cost anything if you use open source such as Cygwin or MingW. Plus, you can even get a free Netbean IDE for those too if you need one.

- Doesn't support Multiple Document encapsulation Interface (MDI) like you will find in C++.

- Because LV is a G language, the search function blows.  I think it's about time NI fixes it!  I could never get it to work when I need it most.

- Compiling into a DLL is waste of feature.  For example if your DLL is made to generate a string output of anywhere between 1 to 100 characters but if you don't know the length in advance then you can't get it to generate the number of chars you wanted.  That being said, if you need generate DLL, stick to C++.

- XControl is a beatitful idea but not ready for primetime and will occasionally corrupt your VI that embedding the xcontrol to the point of irreparable.

- Must constantly upgrade to newer version because old versions are not forward compatible like you will find in traditional programming languages.

[FraggerFox]

Personally, I feel that C++ would be much better when it comes to programming strength (Full OOP). When it comes to GUI, LabVIEW is better.

But we can never say that C++ is better than LV or vice versa. Both have their different places.

[tst]

---

lavalava wrote:

Both LV and C++ originated from C language

---

What makes you think that LV originated from C? It's a completely different paradigm. Parts of the LV compiler may be written in C, but that's irrelevant.

---

- Very easy learning curve means your manager don't need to spend money to send you to school.  

---

But then you have to consider that your code might suck. The fact that LV has a low learning curve means you can write bad code which still works more easily.

---

- More visibility (bling-blings) to your end production.  

---

Many people consider the standard LV look to be quite outdated when you compare it to modern GUIs.

---

- You'll need very big monitors, recommended that you get yourself 2x30" running at full blast resolution of 2560x1600

---

I manage just fine with a 15" laptop, although I often add a 22" screen for comfort.

---

- Multithreading in LV isn't quite easy and neither does LV support true concurrency like the one you find in C++.

---

Multithreading and concurrency (including true multi-core fully parallel execution) are the default in LV. They are so easy you can have them even without intending to. Why do you think it's not as easy?

---

- Doesn't support Multiple Document encapsulation Interface (MDI) like you will find in C++.

---

Not sure what you mean by that. LV can call the OS API reparenting functions just like any other language can. It's true that LV has some issues in this area, and that there is nothing built in, but it can certainly be done. Since C++ doesn't offer any kind of GUI on its own, I'm not sure what the difference is.

---

- Because LV is a G language, the search function blows.  I think it's about time NI fixes it!  I could never get it to work when I need it most.

---

The search function works fine. It certainly could be improved considerably to allow searching for some more complex data and allow better filtering, etc., but it basically works correctly. If there's anything the graphical nature of LV makes difficult, it's diffing and merging.

[FraggerFox]

---

tst wrote:

---

- Very easy learning curve means your manager don't need to spend money to send you to school.  

---

But then you have to consider that your code might suck. The fact that LV has a low learning curve means you can write bad code which still works more easily.

---

I agree. And also, the GUI seeming outdated is also true. Compare the C# .NET GUI with LabVIEW GUI and you would know!

[Norbert_B]

---

lavalava wrote:
[...]

Con:

- You'll need very big monitors, recommended that you get yourself 2x30" running at full blast resolution of 2560x1600

- Multithreading in LV isn't quite easy and neither does LV support true concurrency like the one you find in C++.

[...]

---

Sorry, i have to disagree with those two Cons.

Regarding Monitors:

Yeah, LV very likely misleads developer to enlarge the block diagram or front panel to huge sizes. But there is a style guide on developing good code and it clearly states that neither front panel nor block diagram should exceed one monitor resolution. The resolution is suggested to be 1024x763, but could nowadays be understood as 1200x1024 as well.....

Having two monitors on the other hand can improve efficiency of the developer by a great deal. But to be honest, they could help in textual languages as well (e.g. comparing files).

Regarding Multithreading:

First of all, LV does support real concurrancy. I do not known why you think it does not....

Second point: Programming multithreading in LV is so easy, that many developer do not even know about the fact that they already are programming multithreading. Since multithreading sometimes/often(?) requires certain "security" mechanisms, such code could lead to strange behavior because those mechanisms are not incorporated....

So you are correct in such a degree that programming multithreading in LV is not as simple as it might look like from the beginning, but compare to any textual programming language, multithreading in LV is a piece of cake. And it works (if security is incorporated!). Concurrent.

Norbert

[Norbert_B]

---

Fragger Fox wrote:

[...] And also, the GUI seeming outdated is also true. [...]

---

There is a nice set of controls which might close the gap a bit. You can find them here.

Norbert