From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
LabVIEW
LabVIEW Roadmap (2022)
It is a bit of a double edged sword for sure. On the one hand I too love being able to remove some old rarely (or never) used feature getting rid of that legacy code cleaning things up, and making it better or refactoring it. But LabVIEW's forward and backward compatibility has been pretty great lately. I feel like when I started doing LabVIEW you could only really get away with opening something that was a couple versions older without, seeing all kinds of weird ness usually in the multiple mutations needed. I remember going backwards you could only do one version at a time, unless I'm misremembering it. So if you had a 8.0 VI and you needed it to go to 6.1 you needed to go to 7.0 first, or maybe 7.1 first? Details are fuzzy.
My point is I'd be in favor of cutting off features, but I recognize the fact that it has been nice having versioning be more fluid in recent releases.
Can I also add Units on doubles as a rarely used feature to be removed? What about Node Setup when right clicking a subVI? Or Enable Database Access when right clicking a subVI? Or remove the legacy Icon Editor? I've never created an Express VI, maybe get rid of that? I also haven't used the Advanced >> Edit Palette Set, since the Read/Write Palette functions were added. There are also lots of private nodes that have been listed as deprecated for probably 10 years or more that are still in there. These are almost always because a more complete function has been released that supersedes it. Still I also recognize that after changing to a subscription model, and charging double or more, while removing perpetual license options, might not be the best time to also remove features from the IDE.
EDIT: Also there is code built into LabVIEW today that allows for saving a VI as an XML file. I assume it was a bit of an experiment by NI, or maybe just parts of it were used for library files and they made it support all file types. In any case it isn't the silver bullet people thought it would be and so it really shouldn't be used other than for fun.
@billko wrote:
@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.
Free Labels would accomplish the same job...
@crossrulz wrote:
@billko wrote:
@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.
Free Labels would accomplish the same job...
To me, that's unnecessary BD clutter. Developers don't need to have the history of the VI cluttering their BD; they can look it up in the revision history if they need to, where it belongs.
I think the actual problems are not just or not mainly old features somewhere bitrotting but rather architectural choices made in the late 80ies and early 90ies that make the code hard to modify. And as already alluded some of that is not just caused by bad choices at that time.
First some of the choices were very common and normal back then. C99 didn't even exist, and compilers supporting C89 were also pretty rare to non-existent. C++ was not an option. I remember some one from LabVIEW R&D telling during one session that they tried to compile the code in a C++ compiler. The result was abysmal and would never fit on a computer back in that time, not even beefy workstations.
Even the C compilers were straining to manage the amount of LabVIEW code. The Apple MPW back then had to be multiple times hand-patched by Apple engineers in order to extend the symbol table space to let the LabVIEW team compile their code. (Yes back then you could get direct contact with engineers in a company and when you send them your bug report they would send you the next day or so a patched executable).
That code looks crude, variable names were kept as short as possible to not overflow the symbol tables to quickly and many assumptions were made that are encrusted into the code. Back then a pointer fit nicely into an int32, so why not just use int32 everywhere? I'm sure the guy who did work on porting LabVIEW to support being compiled for 64-bit was likely swearing his socks off during that work.
The assumptions that a string is completely equivalent to a byte stream was very deeply ingrained in the whole architecture, with the result that supporting Unicode is nowadays a real hells task.
The GUI was implemented with a thin abstraction layer on top of the according OS API, Quartz for Mac, GDI for Windows, and XWindows for all Unix variants. Putting a HTML5 layer in there is a very difficult task, but trying to make it WPF would be a total failure. It's really just the umptient attempt from Microsoft to create Yet Another UI framework and can by nowadays standards be considered as dead. They barely manage to make minor bug fixes to it anymore.
So yes there are challenges but we have also seen that a lot of things LabVIEW has and does actually do well seem to be very hard to recreate, which resulted in LabVIEW NXG getting much much slower to a useful state than they had hoped for.
@billko wrote:
@crossrulz wrote:
@billko wrote:
@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.
Free Labels would accomplish the same job...
To me, that's unnecessary BD clutter. Developers don't need to have the history of the VI cluttering their BD; they can look it up in the revision history if they need to, where it belongs.
That's debatable. Most will say it belongs in SCC. Commit often.
Search LabVIEW like a graph!
wiebe@CARYA wrote:
@billko wrote:
@crossrulz wrote:
@billko wrote:
@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.
Free Labels would accomplish the same job...
To me, that's unnecessary BD clutter. Developers don't need to have the history of the VI cluttering their BD; they can look it up in the revision history if they need to, where it belongs.
That's debatable. Most will say it belongs in SCC. Commit often.
I do commit often. Sometimes the commits are minutes apart. And the notes from the revision text goes into the commit message. And what's "debatable"? It's called "revision history".
@billko wrote:
wiebe@CARYA wrote:
@billko wrote:
@crossrulz wrote:
@billko wrote:
@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.
Free Labels would accomplish the same job...
To me, that's unnecessary BD clutter. Developers don't need to have the history of the VI cluttering their BD; they can look it up in the revision history if they need to, where it belongs.
That's debatable. Most will say it belongs in SCC. Commit often.
I do commit often. Sometimes the commits are minutes apart. And the notes from the revision text goes into the commit message. And what's "debatable"?
It's debatable that a VI's history belongs in the revision history.
In fact, I am debating it.
@Hooovahh wrote:
I remember going backwards you could only do one version at a time, unless I'm misremembering it. So if you had a 8.0 VI and you needed it to go to 6.1 you needed to go to 7.0 first, or maybe 7.1 first? Details are fuzzy.
Compatibility chart... Needs updating for the latest few versions. I blame COVID.
http://info-labview.org/LabVIEW%20Version%20Compatibility.pdf
Shows how to update from version 1.0 onwards. And how to save for previous range.
-Scott (when you get confused, listen to the music play)
@sth wrote:
Compatibility chart... Needs updating for the latest few versions. I blame COVID.
http://info-labview.org/LabVIEW%20Version%20Compatibility.pdf)
Thanks, that's way better than I remembered. But I do see the change around version 8.0 making things better.
wiebe@CARYA wrote:
@billko wrote:
wiebe@CARYA wrote:
@billko wrote:
@crossrulz wrote:
@billko wrote:
@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.
Free Labels would accomplish the same job...
To me, that's unnecessary BD clutter. Developers don't need to have the history of the VI cluttering their BD; they can look it up in the revision history if they need to, where it belongs.
That's debatable. Most will say it belongs in SCC. Commit often.
I do commit often. Sometimes the commits are minutes apart. And the notes from the revision text goes into the commit message. And what's "debatable"?
It's debatable that a VI's history belongs in the revision history.
In fact, I am debating it.
I guess probably soon now this should be taken offline, but I'm curious what you think should belong there? If not a VI's history, what history?
