LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW subscription model for 2022

Solved!
Go to solution

@JimB. wrote:

@TiTou wrote:

The question it raises in my mind is : has NI been too ambitious with NXG?


I don't know if too ambitious is the right description, but I think it's safe to say that mistakes were made considering that NXG didn't get much love from established users and was canceled two years ago.


I could've lived with some of the incomplete features, but there were some conscious design choices that I didn't agree with.  I tried loving NXG but it didn't love me back.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
Message 531 of 732
(1,664 Views)

NXG was just badly executed. NXG derailed when the project...
a.) Threw away good, well-proven elements of the LabVIEW project R&D environment to ape an environment appropriate for a text language.
b.) Assumed that developers would joyfully throw away their legacy code for a g-like language with trivial benefits of pastel colors and rounded rectangles. The effect was something akin to replacing C++ keywords with Esparanto and syntax with OCamel because someone on the team thinks it sounds cool.
c.) Succumbed to anti-skeuomorphic fanaticism. The primary LabVIEW application space is intrinsically skeuomorphic. Users operating the resulting software need to see something familiar that conveys information how to use the interface. They are not empowered by front-panel interfaces that are so flat, dull and abstract that their first impression is "WTF?"

 

What NI should have done for NXG was to start by modernizing the underlying LabVIEW codebase while retaining the overlying characteristics and functionality. The process should have fixed longstanding development problems, such as the tendency for the editing environment to bog down while working on hierarchies of complex VIs.

Message 532 of 732
(1,613 Views)

My opinion is that "LabVIEW everywhere" is technically achievable but NI prices LabVIEW outside that market space. Also, to attain that objective, LabVIEW needs to be pushed in the direction of supporting system programming, like C, C++ or Rust.

 

When NI increased prices and switched to subscription licensing, I invested many days in assessing text-language replacements for LabVIEW. As I was changing employment and needed to rebuild everything anyway, it was a good time to switch. Ultimately, I decided to stay with LabVIEW for certain high-level tasks.  So, I made a final 3-years permanent LabVIEW license purchase.

 

This is why I stayed with LabVIEW for some tasks for now:

1. Easier implementation of software for systems managing many concurrent hardware tasks.

2. Fast execution speed competitive with C++ (with careful programming).

3. Better ability to visualize and implement high-complexity software (Cyclomatic Complexity >>3).

4. Higher maintainability. It takes me less time to re-familiarize myself with legacy code.

5. Stronger reusability.

6. Less time to translate complex working solutions from LabVIEW to a text language than to do initial development in the text language, when the time comes to abandon LabVIEW.

Message 533 of 732
(1,600 Views)

I looked into Python and decided that I didn't like it. The language and syntax are like spew from a blender. There are indentation dependencies, akin to Fortran 77 in the early 1980s, for example. For now, I'm coding in C and C++ when I'm not using LabVIEW. I'm not fast at C and C++ but I can get the job done.

 

In the future, I want to invest more time into further explorations of Rust, Erlang, etc. But, Rust doesn't support true object oriented programing and that is limiting. Otherwise, I would have dropped LabVIEW for Rust after the change to subscription licensing.

0 Kudos
Message 534 of 732
(1,589 Views)

@daphilli wrote:

NXG was just badly executed. NXG derailed when the project...
a.) Threw away good, well-proven elements of the LabVIEW project R&D environment to ape an environment appropriate for a text language.
b.) Assumed that developers would joyfully throw away their legacy code for a g-like language with trivial benefits of pastel colors and rounded rectangles. The effect was something akin to replacing C++ keywords with Esparanto and syntax with OCamel because someone on the team thinks it sounds cool.
c.) Succumbed to anti-skeuomorphic fanaticism. The primary LabVIEW application space is intrinsically skeuomorphic. Users operating the resulting software need to see something familiar that conveys information how to use the interface. They are not empowered by front-panel interfaces that are so flat, dull and abstract that their first impression is "WTF?"

 

What NI should have done for NXG was to start by modernizing the underlying LabVIEW codebase while retaining the overlying characteristics and functionality. The process should have fixed longstanding development problems, such as the tendency for the editing environment to bog down while working on hierarchies of complex VIs.


This resulted in an entirely new workflow for me - which I was willing to do, if there were definite benefits to offset it.  But what I found instead was that they threw out basic LabVIEW tenets such that I couldn't even construct anything remotely complex.  And if you look at the source code port of OpenG, they only got like maybe 20% done before they threw in the towel, and for the same reasons.  Basic tricks they used to perform most of their magic no longer worked, and there were no replacement magic or workarounds for them.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 535 of 732
(1,557 Views)

Out of curiosity, what kind of things did they remove in NXG? I never tried it, as every time I looked it was lacking some major feature I needed but it wasn't a "core" thing, and it was usually "just over the horizon" to show up in an update. And I wasn't going to risk any projects (or my time learning) developing in a language that was still in the beta testing stages.

Message 536 of 732
(1,532 Views)

@BertMcMahan wrote:

Out of curiosity, what kind of things did they remove in NXG? I never tried it, as every time I looked it was lacking some major feature I needed but it wasn't a "core" thing, and it was usually "just over the horizon" to show up in an update. And I wasn't going to risk any projects (or my time learning) developing in a language that was still in the beta testing stages.


One annoying thing I can think of concerns bundling/unbundling clusters.  You had to explicitly unbundle every level of cluster instead of using cascading menus to get to the element you wanted to unbundle.  It led to ugly, long chains of code.  It was ugly, but at least it worked.

 

One showstopper was wires no longer carried properties with them, so you couldn't find the name of a control the way you could in LabVIEW Classic - that is, by using a variant datatype parser.  (This is what destroyed OpenG - their whole scheme of parsing clusters fell apart at the seams.)

 

I also could not find a way to access a control in another VI.  Refnums didn't seem to support this.  I like to keep my UI in a subVI, and because of this limitation, I could no longer do this.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
Message 537 of 732
(1,520 Views)

Scripting was missing, it could be done in C# but not in LabVIEW.

 

That was a huge limitation for a lot of people, and the fact that no one at NI - involved in NXG planning - understood that, supports the argument that :

@billko  a écrit :


Seems like they don't even understand their own product any more.

Also, I read a lot of very concerned feedback from early adopters who were complaining about very poor performance after porting apps from classic to NXG.

I never dug into that subject to see if performance issue were all over NXG or if the porting was poorly done, but the simple fact that NI's tool to port from classic to NXG would create something that was useless was extremely worrying to me.

As @daphilli said when LabVIEW classic is well written, it can competes with C++ in terms of performance, was it also the case for NXG?


We have two ears and one mouth so that we can listen twice as much as we speak.

Epictetus

Antoine Chalons

0 Kudos
Message 538 of 732
(1,437 Views)

@TiTou wrote:

Scripting was missing, it could be done in C# but not in LabVIEW.

 

That was a huge limitation for a lot of people, and the fact that no one at NI - involved in NXG planning - understood that, supports the argument that :

@billko  a écrit :


Seems like they don't even understand their own product any more.

Also, I read a lot of very concerned feedback from early adopters who were complaining about very poor performance after porting apps from classic to NXG.

I never dug into that subject to see if performance issue were all over NXG or if the porting was poorly done, but the simple fact that NI's tool to port from classic to NXG would create something that was useless was extremely worrying to me.

As @daphilli said when LabVIEW classic is well written, it can competes with C++ in terms of performance, was it also the case for NXG?


I could never write something complex enough to put it to the test.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 539 of 732
(1,428 Views)

@billko wrote:

I also could not find a way to access a control in another VI.  Refnums didn't seem to support this.  I like to keep my UI in a subVI, and because of this limitation, I could no longer do this.


It is mind boggling that they thought this was a good idea. Wire properties/variant datatypes/etc are important for a lot of background stuff that I'd guess 95% of people don't use during active development (despite using libraries that DO use this), but refnums not working across VI's? How did that get past any sort of review process?

0 Kudos
Message 540 of 732
(1,336 Views)