Leaderboard

At risk of derailing this topic I've seen you make many arguments as such, but they rely on the assumption that the user is utilizing an HTML "View" and can plug and play LV or Python or whatever behind it. In your workflow I 100% believe that is the case. However, I do not think that is common. Certainly I will admit my knowledge of python driven UIs is lacking. However, flawed and outdated as LV UIs are, they are still an advantage from my perspective. I have dabbled with your approach and do see the positives there, but it's not dissimilar to having to program a host application for an RT target and adding an additional layer to every application.

Python. I know of very few LabVIEW positions in Europe for T&M. Very few vacancies are for LabVIEW now, generally. This seems to be a move to specific corporate customer types, like CERN. This will hit consultants. start-ups and small niche suppliers the hardest and say goodbye to most open source toolkits. With no new growth in uptake of LabVIEW and walled-off, future-proofing for existing customers, I see this as the death-throes of LabVIEW as eventually the corporate customers move away.

No you cannot. Your simplified example, if the interface is truly abstract, is equivalent to trying to prevent someone from dropping a "empty string constant" on the block diagram. Fundamentally though, it would prevent you from using the direct cast to exercise the override, as shown in the bottom example. The only restriction is that one cannot create a DVR of the interface from outside the interface itself. I have to admit that I have not investigated the consequence of such a pattern in the context of interfaces...

Yes, built applications will continue to work like they did so far. This means for the LabVIEW runtime you can install it and your executable on any computer you want and run it. Eventual Runtime licenses such as for IMAQ Vision etc, will still be per machine licenses and not leases, just as they are now. The Realtime and FPGA Module will be also a software lease but you only need them to write and build the compiled code, after that you can run them on any licensed hardware just like you do now. Deployment will of course only work from a licensed LabVIEW Development system with activated Realtime Module but once it is deployed, the target can run for as long as you want without limitations by a software lease. If they ever would change that that will be the day our company will definitely stop to use LabVIEW. We can not have a machine stop execution because the NI license server takes some vacation or some software lease has expired. The Debug Deployment licenses of the different NI software products will also stay as perpetual licenses. They are in principle the same as the Development system but you only have the right to use them to debug an application, not to write and build it. They are meant for the computers on the factory floor where you want to run your built application but may need to be able to also execute the VIs in source code to debug problems on the real hardware instead of on your development machine.

The market has spoken. While you may be correct from a technical point of view, Python is now dominant in T&M and for everything else, there is Matlab. That leaves FPGA and Hardware still in NI's wheelhouse with regards to LabVIEW. UI isn't a strength in LabVIEW and I take your point about Python with regards to WISIWIG component forms but when you do everything with an HTML interface-it's just a back-end choice with Python being a lot easier to interface to. The question to ask is...if I wanted to create an application that produced a walled garden like NI are now doing (a service in the cloud); how easy would it be with LabVIEW? I can guarantee that a lot of the services they are now promoting have very little LabVIEW programming in them and this is where many industries, including NI now, have already moved to.