LabVIEW
LabVIEW Roadmap (2022)
@ThomasV wrote:
wiebe@CARYA wrote:
@ThomasV wrote:Now that NXG is dead, I am surprised that they have chosen to somehow keep developing onto that 40 years old code...
LabVIEW NXG is cancelled. NXG isn't.
NXG is still used (and developed?) for at least the G Web Module.
Okay, some add-ons may appear, based on NXG. But that doesn't change the fact that the foundations of LabVIEW will remain. I doubt that this will prevent NI from modernising the IDE.
Do you mean you think [the fact that the foundations of LabVIEW will remain] will prevent NI from modernizing the IDE?
It probably does.
Search LabVIEW like a graph! 
wiebe@CARYA wrote:
Do you mean you think [the fact that the foundations of LabVIEW will remain] will prevent NI from modernizing the IDE?
It probably does.
It makes things a bit more complicated. But considering that the NXG platform had serious problems to get close to feature parity with LabVIEW Classic you could argue that both paths were equally complicated.
There is some cruft in the LabVIEW code and some of the things are not as clean as modern C# programmers would like. The craftsmanship with C and C++ has diminished over the years so that code gets harder to tackle for new developers. Add to that some less than neat coding from the days where multithreading was not even a consideration and compilers were fighting with overflowing symbol tables when told to compile a reasonably complex C source file and you have some code base that is not so easy to maintain.
It doesn't mean that it can't be done, but it may be hard to find developers willing to tackle it. Old code is never sexy and rewriting everything from scratch is the first jerk reaction of most developers. Once you have dug into the code and started to understand it in its depth, things are changing considerably though.
I feel like I've heard that a lot of things are impossible "due to maintaining legacy compatibility". I wonder if they'll wind up biting the bullet and starting to deprecate some of the older stuff and release a non-backward-compatible version. I have no idea what kinds of features might break though... just spitballing.
@BertMcMahan wrote:
I feel like I've heard that a lot of things are impossible "due to maintaining legacy compatibility". I wonder if they'll wind up biting the bullet and starting to deprecate some of the older stuff and release a non-backward-compatible version. I have no idea what kinds of features might break though... just spitballing.
I have personally been advocating for the removal of "ancient", rarely used features. First on my list would be "revision history" as that is something that belongs in external tools, ie Source Code Control.
I do see a possible benefit in removing "old" mutation code (pre-2009? 2012?). That is something that would need some strong consideration though (how many people are still trying to upgrade LabVIEW 8.6 or earlier code?).
@crossrulz wrote:
@BertMcMahan wrote:
I feel like I've heard that a lot of things are impossible "due to maintaining legacy compatibility". I wonder if they'll wind up biting the bullet and starting to deprecate some of the older stuff and release a non-backward-compatible version. I have no idea what kinds of features might break though... just spitballing.
I have personally been advocating for the removal of "ancient", rarely used features. First on my list would be "revision history" as that is something that belongs in external tools, ie Source Code Control.
I do see a possible benefit in removing "old" mutation code (pre-2009? 2012?). That is something that would need some strong consideration though (how many people are still trying to upgrade LabVIEW 8.6 or earlier code?).
That's funny. I know I'm in the minority, but I put stuff in the revision notes all the time so when it comes to actually committing, I have notes for my commit.
@crossrulz wrote:
I do see a possible benefit in removing "old" mutation code (pre-2009? 2012?). That is something that would need some strong consideration though (how many people are still trying to upgrade LabVIEW 8.6 or earlier code?).
They've done this (at least?) once before- if you want to upgrade code from <v6, you have to upgrade to 8.2 first. 8.2 was 2007 so it seems like we're due for another "break" in version continuity. I don't know if the "old legacy features" would simply be deprecated or if they'd be upgradeable across the version boundary. I'd love to understand some of the "ye olde features" that are preventing some of the major updates.
I just have no idea if they're something rarely used but important, or if they're something fundamental under the hood with far-reaching implications, or if it's just a fundamental architectural change- for example, changing the way splitter bars or subpanels work (or even just how panels work in general). I feel like I've heard some of this discussion revolving around dynamically creating controls, which (IIRC) NXG supported but "is impossible" with current LabVIEW, outside of some fairly tricky workarounds.
@BertMcMahan wrote:
I feel like I've heard that a lot of things are impossible "due to maintaining legacy compatibility". I wonder if they'll wind up biting the bullet and starting to deprecate some of the older stuff and release a non-backward-compatible version. I have no idea what kinds of features might break though... just spitballing.
Hear! Hear!
Not only should obsolete IDE stuff be removed (even at the cost of backward compatibility), functions should be removed from the core.
It used to be a huge advantage that LabVIEW would have everything you'd ever wanted. But that's just not feasible anymore. I now want a LabVIEW where I can add everything I want.
XML based files? Documented plug in structure? Yes please!
I know this is just cherry picking. Nothing wrong with that (except when my customers do it).
@BertMcMahan wrote:
I'd love to understand some of the "ye olde features" that are preventing some of the major updates.
That's not too hard.
For instance, if we wanted an XML based file it would be a lot easier if the binary file didn't need to coexist. Supporting n methods is typically not n times as hard, but more like x^n as hard (x will be >2 😊).
A new GUI system based on HTML5 or WPF (sigh) or whatever would be much harder to make if the old GUI system needs to coexist.
You could argue that a converter has to be made anyway. But keeping this separate will keep the both code bases smaller. Testing this functionality separate will also be easier.
