Leaderboard

The IDE was in fact pretty much here when NI launched LabVIEW Web UI: https://www.youtube.com/watch?v=RiY35znIdUg which used Microsoft Silverlight. Since that must have been in the making for several years before it was released, this is more like 10+ years old. Does the IDE look 10 years old or older? The fact that pretty much every traditional LV developer feels horrible pain at the mere look of the IDE is saying either we are all hopelessly outdated or indeed the IDE is a step backwards in terms of nimbleness (agility?). The IDE should be modular, since the underlying code itself is not. In fact, it should be open, offering the ability to third party developers to hook their tools and customization. I am not particularly depressed anymore at the unfolding of this slow motion catastrophe, and in fact I am even willing to believe NI that indeed there is a new crop of developers who are going to prove us all wrong. But right now, this is not the direction we (academia) are going. We want openness (for reproducibility purposes), we want flexibility, customizability, and we are certainly not going to have our users pay runtime licenses for toolkits simply implementing public domain algorithms. I am still much more efficient at programming in LV, but there is zero incentive for me to choose NXG over Python at this point, based on my 25 years of dealing with NI.

A better way of looking at it might be that a variant is a specific data type. so if we assume c++ has some map<keyType, valueType> under the hood, the new labview map type exposes this directly and lets keyType and valueType be any labview type. the variant attribute system was specifically map<string, variant>. The api added some sugar on top so that if you specified a type, it performed variantToData(map.read(myStringKey), myDataType)...but it was still a map<string, variant>. If the content of your variant is a big array, this could potentially cause performance issues because of that variantToData. Vs 2019 where your map type might be map<string, lvArrayHandle> which doesnt need any of the weird memory allocation that happens if you call variantToData(myArrayInsideOfAVariant, dblArrayType). I dont know if this is precisely accurate, but thats what my general understanding was.

My experiment with NXG is now over. A simple web page has taken about 5x longer than I had planned for. Some of this is due to me underestimating the nuances of the web module but most of it has been me fighting the new IDE. The other night instead of happily diving into some after dinner software development fun I was actually filled with dread at the thought of having to open NXG and finish what I started, it really is that unpleasant to use. For me, NXG is nowhere near usable in a real project that I expect to have to develop, maintain and make money off. Some stuff seems to work, but everything has this toy feel about it. It is ugly, sluggish, unintuitive and absolutely repulsive to develop with. Sorry that sounds harsh, but it has been in development for over 8 years and has an incredibly strong pedigree to compare against. NI have taken almost everything that made current gen so special and thrown it in the bin. NXG is clearly being managed and developed by people who have never actually become intimately familiar with LabVIEW. I will check back in a few years time but at this point I am extremely disappointed and now need to think very strongly about where my professional systems development career is going. Current Gen is going to be sunsetted at some point and will fade into irrelevance due to its closed source nature (not that open sourcing something of its complexity would help now, it is too late for that). I could wait a few years if I had confidence that the ship was sailing in the right direction, but apart from AQ who consistently has the courage to actually even reply to these threads there is virtually nothing coming back from NI and I feel that the HMS NXG-itanic is sailing full steam ahead towards its doom. NI is run by extremely clever people who have no doubt done their sums and analyses and are charting the course for NXG that they think will bring them the most success in the long-run. I have a strong appreciation for just how big an undertaking something like NXG is, but given where it is after 8 years of development it just seems that I am not the target market and there is not too much I can do about it. Happily, given how robust NI hardware and current gen LabVIEW actually are I suspect there will be quite a bit of work supporting old systems for at least another decade (perhaps more).

Your argument is inconsistent. If it's not a priority then making a change to remove it is allocating resource to "the least important". Leaving it in would be the least impactful. However. If you are going to change it then you might as well make it a "Preference" since that is clearly what it is. You don't seem to have a preference or, at least, are indifferent. So why advocate taking away a feature that other people obviously feel strongly about?