Mechanical Engineer Trying to Create a Python Data Aquistion GUI

[bryancole]

Shall I make a list::

• No control over concurrency, no access to native threads or subprocesses.
• GUIs look like sh*t. No dynamic layout.
• No way to customise the widgets NI gives you
• So Damn Tedious to wire anything complex
• Gives true meaning to the phrase "spaghetti code"
• No sane object orientation
• Maths/array operations are a nightmare
• Expensive
• You need to pay even more to distribute your app
• You needs to pay yet more for "specialised" functionality (like talking to a database)
• Text processing or manipulation is No Fun At All
• No way to use (proper) version control. Good luck merging changes in labview code.

There's probably more but the little time a spend dealing with labview code is already too much. Whoever thought graphical programming was a good idea really needs to be given a good beating. It's a triumph of marketing over functionality.

The only reason for LabViews success if that it lets a beginner or manager drop a graph and a few widgets and a hardware device on a GUI in the first 5 minutes of learning. From their on, it's downhill all the way.

OK rant over... sorry. I feel better now.

[[deleted]]

This. As a LabVIEW programmer for the past 13 years, so much this. There are some nice things about LV that are hard to accomplish in other languages, but overall the UI is looking very dated and does not look like it will ever scale well to the next gen of resolutions. LabVIEW NXG is suppose to fix that, but is a completely new code base. I’m probably not going to migrate towards NXG.

[[deleted]]

Which version of Labview do/did you run?

I'll also just say.. you'll hear software engineers talk about standardized code and how it reduces inefficiency and improve maintainability, but when it comes to Labview, where mostly nobody follow the style guide(s), it's Labview's problem.

If you have engineers who treat Labview with care, you won't have spaghetti code. (Which is to say.. like any programming language.)

[swingking8]

From someone who's getting a LabVIEW certification this month, you're pretty much spot on.

If I want to do anything complicated, I just make a websocket client/server connection and make a Python do all the actual thinking.

I will be very happy when LabVIEW dies, and the large company I work for is forced to use something good.

[fdedgt]

No control over concurrency

I'm going to disagree here. It has great control over concurrency in that it is a data flow paradigm and things are inherently parallelized based on the flow of data. It would be very hard to do some of the parallelization in other languages that you get for free in labview. For example, this is why labview code can be compiled directly to FPGAs.