LabVIEW
Search 1D Array ... Changed in 2020 SP1
@jacemdom wrote:
All this professional focus on the positive attitude is certainly useful but not saying the obvious unpleasant truth is not.
I hope someone at NI finds the processes or procedures or people that created or allowed that giant monstrosity before it creates another one.
I can certainly see how this can happen and would be a little less harsh with my criticisms about this. Someone went to the trouble to improve the Search 1D Array by writing two VIMs that separates the process into a binary search for sorted arrays and a linear search for unsorted arrays. And after reviewing and testing, it is considered that the Search Unsorted Array is in fact working the same as the old Search Array function, so leaving the old in the palette is only cluttering the menu unnecessarily (and yes I can very much imagine that if it had been left in, there would have been at least as much criticism for cluttering the menu palette with redundant functionality). Of course there is the huge concern of "what happens if you upgrade an existing program , which used the old node to this LabVIEW version?" and the answer is "Nothing, that node is still present in LabVIEW, so that upgraded program will continue to use it as it did before."
Except, in the field there comes someone using the function in a specific way that shows that the two functions don't exactly behave the same. They may be the same in terms of algorithmic calculation, but due to the differences of what a VIM can do in terms of auto adapting to wired terminals in comparison to a native node that has more possibilities to adapt to different data types, if and only if the according C++ code underneath does specifically provide for that adaptability across the various terminals, it suddenly generates a broken wire. Now if there was no way to get equal functionality with this new node and the code would stay broken no matter what, then I would also agree that it was a badly executed modification. But the function can be made to work fine, it just works a little different and somewhat unexpected during edit time. This is the classical case of adding an improvement and then discovering that there is actually a usability problem after the product is released. The ideal would of course have been if the VIM could be made to avoid that broken wire. It may be possible to do so and it was an implementation oversight that it doesn't, or it may not due to the limitations of what a VIM can do compared to the built in node with its underlying custom C++ auto-adaption magic.
If you truly require new features to be always top notch perfect, you can stop implementing and improving. There will always be corner cases that can't be thought of ahead, even if a team of developers is going to brainstorm hours or days over it. I think in that respect, that LabVIEW features are generally thought out quite extensively and tested and verified pretty well. That there will sometimes be bugs, or as in this case rather inconveniences, should be no reason not to do such improvements. Of course it should be tried to minimize them as much as possible, but I think the LabVIEW developers have done quite a good job so far in this.
In fact what you advocate in requesting for backwards incompatible changes to be allowed, would go a lot further than this inconvenience and cause a lot more uproar for sure. It would seem to me that you are advocating for two pretty contradictory requirements in your post. Allow for backwards incompatible changes but get pretty upset about a usability inconvenience?
@jacemdom wrote:And obviously I used this opportunity to try and stir up things so that maybe one day we get back to good old days where every year was a long wait to see the new features...I can't say that the last 5 years have been cliffhangers...LVOOP, VIMS...the LV Icon...
2017 - VIMs are amazing. They have simplified my code so much.
2018 - Expansion on VIMs. Can't remember anything else.
2019 - Maps and Sets!!!
2020 - LVOOP Interfaces. Haven't played around with them yet. I can see the usefulness, but I'm not totally excited yet.
So I would say there were some major new features to LabVIEW over the last 5 years. I specifically upgraded to 2019 for maps. I then played around with VIMs and found plenty of places where I could simplify (duplicate) code with them.
My main complaint with 2020SP1 is that it feels more like a full release than a SP release, especially with the new graphics. NI is just changing things without giving us a chance to chime in. And this isn't just a LabVIEW problem.
@jacemdom wrote:
If backward compatibility was never broken, we would all still be running Windows XP.
Well Windows is actually a rather bad example of this. There is a very substantial part of code in Windows that is all about backwards compatibility going back to support things that were necessary to run DOS applications. Not all of that may still be exercised nowadays but removing things has also risks of breaking other still used parts, so it often isn’t done unless absolutely necessary.
If you had said MacOS X I would agree. Apple likes to depreciate features, sometimes only a few versions after they were introduced and even if sometimes there is no good alternative. And they don’t shy from completely removing it a few versions later!
But the hard problem will be not breaking backwards compatibility once they dig into those arcane dungeons of old code. While such backwards compatibility will very likely happen and will cause uproar no matter what, there will also be simply new unintended bugs that will cause you to be remembered of the old days of LabVIEW 8.0, which crashed fairly regularly, and usability problems where this bad wire, that caused this thread, will look pretty harmless in comparison.
@jacemdom wrote:
@crossrulz wrote:
So I would say there were some major new features to LabVIEW over the last 5 years. I specifically upgraded to 2019 for maps. I then played around with VIMs and found plenty of places where I could simplify (duplicate) code with them.Feels like a misunderstanding here. VIMs are definitely in my top 3 features of all time, along with the undo and the event structure. To phrase it differently, I was saying that LabVIEW did not evolve as fast as before NI started investing heavily in NXG and I hope that now that NXG is gone, LabVIEW will get the much-needed attention it needs. On top of everything I hope they decide to make the bold move they should have done instead of starting NXG, I hope they put on their scuba diving suits and tackle the underlying issues that prompted them to start NXG in the first place. And if it breaks some backward compatibility, then so be it. If backward compatibility was never broken, we would all still be running Windows XP…
NXG isn't gone.
It's only LabVIEW NXG that is discontinued. NXG will still be available for web VIs, system link, and who knows what.
NI might still invest in NXG technology.
Search LabVIEW like a graph!
@jacemdom wrote:
I really had the feeling that LabVIEW new features had declined in quantity and awesomeness in the recent years but It looks like I definitely should reevaluate my position because I seem to be the only one thinking so...
No absolutely not! The output of new features for classic LabVIEW definitely has declined in the last 10 years. But that is not to say that there haven't been new features. In the long ago past something like the Maps and Sets feature would have been one single point in a longer list of interesting new features. For LabVIEW 2019 it was THE new feature.
Things like this were pursued because they stand pretty much on their own and can be added without changing almost anything of the existing LabVIEW code base. Things that would have been certainly disruptive such as adding proper support for Unicode and many other things, and which were due about 10 years ago at the latest, were stalled because there was this new and much better version of LabVIEW on the horizon that was planned to solve all these problems for once and for all.
Maybe when the beta program finally comes out I will be blown out of my chair with an long list of awesome new features...
I wouldn't hold my breath for this. Some of the much needed things in LabVIEW require substantial basic ground work first, that will not likely show up right away at all in the released product. For instance take Unicode. First there needs to be supporting code to do proper Unicode processing. Then there needs to be support for a new data type that supports Unicode. Then a library of nodes that makes the functionality available to the diagram. And at this point if it was done right they can also change the path handling to work internally consistently with Unicode and then suddenly the entire long path problem is solved under Windows. Last but not least the Unicode support needs to be added throughout the UI of LabVIEW including full Front Panel support for Unicode strings. Even if they put a whole team of programmers on this, it is likely going to take several years to get each of these steps fully implemented and tested. And you have to start with the base, which may not get visible to any LabVIEW users for at least one more version.
@jacemdom wrote:On top of everything I hope they decide to make the bold move they should have done instead of starting NXG, I hope they put on their scuba diving suits and tackle the underlying issues that prompted them to start NXG in the first place.
I have been told that a lot of work on LabVIEW was "untangling the web", which is basically trying to isolate libraries and therefore able to fix things at the lower level, while NXG was being developed. I was also told that this was only really possible because the LabVIEW 20XX team was smaller. So maybe it is worth keeping the team small for a little longer to refactor these lower level libraries and only have a couple of new features along the way. A lot of work needs to be done to libraries that have not been touched for decades in order to create the groundwork for features LabVIEW NXG was created in order to accomplish.
We should also note that NXG is a platform, not just LabVIEW. The NXG platform has been used on almost all NI products over the last few years (Veristand, FlexLogger, Instrument Studio, etc).
