Dear NI

[Neil Pate]

Dear Santa NI

I am now in my 40s with youngish kids, so despite the fact that all I got for Christmas this year was a Pickle Rick cushion I am not actually complaining. However, I would like to get my order in to the Elves as early as possible. This is my wishlist, in no particular order. I expect this list will not be to everyone's taste, this is ok, this is just my opinion.

• Make LabVIEW free forever. The war is over, Python has won. If you want to be relevant in 5 to 10 years you need to embrace this. The community edition is a great start but is is probably not enough. Note: I accept it might be necessary to charge for FPGA stuff where I presume you license Xilinx tools. NI is and has always been a hardware company.
• Make all toolkits free. See the above point.
• Remove all third party licensing stuff. Nobody makes any money from this anyway. Encourage completely open sharing of code and lead by example.
• Take all the software engineering knowledge gained during the NXG experiment and start a deep refactor of the current gen IDE. Small changes here please though... we should not have to wait 10 years.
• Listen to the feedback of your most passionate users during this refactor. NXG failed because you ignored us and just assumed we would consume whatever was placed in front of us. I am talking about the people like those reading this post on Christmas day and their spare time because they are so deeply committed to LabVIEW
• My eyes are not what they used to be, so please bring in the NXG style vector graphic support so I can adjust the zoom of my block diagram and front panel to suit accordingly
• As part of the deep refactor, the run-time GUI needs to be modernised. We need proper support for resizable GUIs that react sensible to high DPI environments.
• Bring the best bits of NXG over to current gen. For example the dockable properties pane. (Sorry not much else comes to mind)
• Remove support for Linux and Mac and start to prune this cross compatibility from the codebase. I know this is going to get me flamed for eternity from 0.1 % of the users. (You pretty much made this decision for NXG already). Windows 10 is a great OS and has won the war here.
• Get rid of the 32-bit version and make RT 64-bit compatible. You are a decade overdue here.
• Add unicode support. I have only needed this a few times, but it is mandatory for a multicultural language in 2021 and going forward
• Port the Web Module to Current Gen. All the news I have heard is that the Web Module is going to become a standalone product. Please bring this into Current Gen. This has so much potential.
• Stop adding features for a few years. Spend the engineering effort polishing.
• Fix the random weirdness we get when deploying to RT
• Open source as many toolkits as you can.
• Move the Vision toolkit over to OpenCV and make it open source
• Sell your hardware a bit cheaper. We love your hardware and the integration with LabVIEW but when you are a big multiple more expensive than a competitor it is very hard to justify the cost.
• Allow people to source NI hardware through whatever channel makes most sense to them. Currently the rules on hardware purchasing across regions are ridiculous.
• Bring ni.com into the 21st century. The website is a dinosaur and makes me sad whenever I have to use it
• Re-engage with universities to inspire the next generation of young engineers and makers. This will be much easier if the price is zero
• Re-engage with the community of your most passionate supporters. Lately it has felt like there is a black hole when communicating with you
• Engineer ambitiously? What does this even mean? The people using your products are doing their best, please don't patronise us with this slogan.
• Take the hard work done in NXG and make VIs into a non-binary format human readable so that we can diff and merge with our choice of SCC tools
• Remove all hurdles to hand-editing of these files (no more pointless hashes for "protection" of .lvlibs and VIs etc)
• Openly publish the file formats to allow advanced users to make toolkits. We have some seriously skilled users here who already know how to edit the binary versions! Embrace this, it can only help you.
• Introduce some kind of virtualenv ala Python. i.e. allow libraries and toolkits to be installed on a per-project basis. (I think this is something JKI are investigating with their new Project Dragon thing)
• For the love of all that is holy do not integrate Git deeply into LabVIEW. Nobody wants to be locked into someone else's choice of SCC. (That said, I do think everyone should use Git anyway, this is another war that has been won).

That is about it for now.

All I want is for you guys to succeed so my career of nearly 20 years does not need to be flushed down the toilet like 2020.

Love you

Neil

(Edited: added a few more bullets)

Edited December 26, 2020 by Neil Pate

[Mads]

19 hours ago, Neil Pate said:

Take the hard work done in NXG and make VIs into a non-binary format human readable so that we can diff and merge with our choice of SCC tools

I see a lot of people wanting this, but why? We code graphically after all. The way to make sense of the underlying code to a G-programmer is to present it as G-code, not text...

Ideally we had a SCC-system made specifically for graphical code, but I do not expect that to become a reality (unless someone made it on top of an existing one perhaps). Personally I live relatively comfortably with the solutions we can set up already, but would prefer to see it better integrated into LabVIEW and/or have out of the box solutions on how to get started with various major SCC alternatives. 

If the VIs were humanly readable it might make it easier to create more powerful alternatives to VI Scripting though, and to generate code at run-time in built applications...That is something else.

[ShaunR]

42 minutes ago, Mads said:

I see a lot of people wanting this, but why? We code graphically after all. The way to make sense of the underlying code to a G-programmer is to present it as G-code, not text...

Ideally we had a SCC-system made specifically for graphical code, but I do not expect that to become a reality (unless someone made it on top of an existing one perhaps). Personally I live relatively comfortably with the solutions we can set up already, but would prefer to see it better integrated into LabVIEW and/or have out of the box solutions on how to get started with various major SCC alternatives. 

If the VIs were humanly readable it might make it easier to create more powerful alternatives to VI Scripting though, and to generate code at run-time in built applications...That is something else.

It is presented as G code...when loaded into LabVIEW. All that is being proposed is for the on-disk representation to be in a format that normal SCC can deal with rather than a proprietary binary format that prevents us from incremental differencing.

Projects et. al. have already gone this route. The suggestion is to extend it to the VI's themselves. We know that VI's *can* be represented in forms such as XML from some of the under-the-hood tools we have seen. The current state of affairs in how SCC's deal with LabVIEW source is the equivalent of using SCC for C/C++ object code, and the NI graphical solution is far too manually intensive.

As for the rest of Santa's list. Most of it is "gibs free stuff"

Edited December 26, 2020 by ShaunR

[X___]

Free is maybe pushing it. Zero technical support without a SSP would be an appropriate model associated with open source. Of course this wouldn't prevent a vibrant community support (independent from NI) from existing, but this is not what the big industrial companies using LV would go for. They would remain NI's proverbial cash cows. 

I think the misunderstanding on the corporate side of why open source is beneficial for code safety and reproducibility is understandable, as I can witness the same ambivalence if not resistance in academia.

As for NXG and webUI (or whatever they call it now), as discussed elsewhere, it looks like NI doesn't have the resources to bring the vision (whatever it was originally) to fruition, and their recent decision  to abandon it will probably lead (or has already led) to morale cratering and talent effusion, so I wouldn't hold my breath...

One thing I'd add to the list is this: stop the yearly versioning breaking backward compatibility. This is frankly moronic and the clear and only reason why this exists is NI pricing scheme. Adopt the scheme suggested in the first paragraph and this can go right away.

Edited December 26, 2020 by X___

[MarkCG]

I agree with all your points. Definitely on making LabVIEW free for all purposes, if not even open source. NI may hang on to the mega-costumers for a while with its current business model. But eventually it'll get marked as a legacy software and slowly replaced by younger people with newer ideas and experience in different, more accessible languages. The idea that a company can sell a programming language these days is ridiculous when there are so many free alternatives. I am not counting the community edition. It needs to be free for any purpose.

Edited December 26, 2020 by MarkCG

[Mefistotelis]

On 12/25/2020 at 7:30 PM, Neil Pate said:

Remove support for Linux and Mac and start to prune this cross compatibility from the codebase. I know this is going to get me flamed for eternity from 0.1 % of the users. (You pretty much made this decision for NXG already). Windows 10 is a great OS and has won the war here.

I actually don't care enough for LV to get triggered by the first sentence. But the last one... 😡

[codcoder]

Couldn't agree more.

I also believe NI really need to push LabVIEW more aggressively to the maker community. This is a group of people who adores things that are "free", "open", "lite" and today, LabVIEW simply doesn't make the cut. Of course the coolness factor will still be an issue (a night/dark mode could probably help?) but surely there must be a way to position LabVIEW as a great tool to help creative geniuses to focus less on grit and more on, well, actually creating stuff.

I work in the aerospace-defense-industry. With hardware. But we are fewer and fewer who does. The majority of the engineers now are software engineers who either work purely with software or come from that background. To explain to them why NI's offering makes sense is extremely difficult.

Of course, for now, what we do is relatively complicated and closely tied to the performance of the hardware. So using NI’s locked-in eco system saves us time and money. But NI’s pyramid is crumbling from the base. At other companies I’ve seen well-made LabVIEW application been ripped out and replaced with “anything” written in Python. Of course it didn’t work any better (quite the opposite), but it was Python and not LabVIEW. And that single argument was strong enough.

Edited December 28, 2020 by codcoder

[ShaunR]

I think there is a compromise here that would help with contending with Python, if it's not too late - make Linux repositories available for older LabVIEW versions.

I remember vaguely that there was one for 8.6. So if there were, say, repositories of versions older than 5 years; it would be a route for people to get into LabVIEW and enable makers, students, and the terminally curious to code in LabVIEW without impacting the current sales.

But be careful what you wish for. The probable solution to the demands for free stuff will ultimately end up as LabVIEW-as-a-service.

[Rolf Kalbermatter]

The problem with the argument about better mergeability if LabVIEW would use a text based file format is that XML and really any format that can represent more complex data structures, can not easily be merged with current tools. It doesn't even fully work for normal text based languages as the merge tool can NOT determine what to do when two code modifications occurred at the same or immediately adjacent  line location in a text file. You end up with conflicts that have to be resolved manually. While that is doable although not fully painless for normal text based languages, XML and similar formats pose an additional challenge since a change in one element can actually cause changes in multiple line locations, often separated by many text lines. As soon as two different changes are somehow not totally independent in line location, you can't merge just based on line information. And in the worst case a single change can basically mean a modification right in the beginning of the file and one at the end. With such a change any other change is potentially very problematic to merge. And just doing the standard conflict resolution for text files as it is done now, with including both sections and letting the user manually decide which to use, would basically just create a double as big file, which would be pretty useless to try to manually merge.

So while converting LabVIEW binary files to XML or similar sounds like a good idea, it won't solve the problem of merging in source code control really. In a way the current situation is easier: You know it can't be done automatically so are forced to plan accordingly! XML may in that respect seem to many to promise something that could not be delivered anyways in most merge situations. To do any meaningful merging for anything but the most trivial modifications in XML format, one would have to create a diff/merge tool that fully understands XML and to make matters worse, it should also be aware of the actual schema used in the XML file. Even then creating an XML format from that merge result would be only partly helpful, one would really need an interactive merge visualizer that presents the XML data structure to the user directly in a suitable graphical form such as a tree view and lets him select the relevant modification when there are any logical conflicts.

As to creating external tools for dealing with LabVIEW files without the need to script things in LabVIEW itself, the idea sounds good, but I doubt it will be used a lot. Maybe a translation tool for different languages but many such things are rather runtime features than edit time features.

About throwing away LabVIEW for non-Windows platforms: That is hardly an argument to even start to try to remain relevant in comparison to things like Python or in a far far future from now maybe .Net. Python runs on pretty much every hardware you can imagine that has a C compiler available, from low end 8-bit microprocessors to extreme high end system.

There are also literally exclusive points in that list.

* Stop adding new features to LabVIEW for several years

This directly contradicts several other items in that list.

Edited December 30, 2020 by Rolf Kalbermatter

[Porter]

- LVCompare and LVMerge should be unlocked with the LabVIEW base edition. Or even better, an open source merge and compare tool could be released to the community.

[Bryan]

On 12/27/2020 at 7:58 AM, Mefistotelis said:

I actually don't care enough for LV to get triggered by the first sentence. But the last one... 😡

I agree, I have garnered great disdain for Winblows over the years as far as the negative impacts to our testers from updates mandated by IT departments, obsolescence, the pain to install unsigned drivers, just to name a few.  I would hate to see NI stop support for Linux as it has been growing in popularity and getting more user friendly.

Linux is a great and stable platform, though not for the faint of heart.  It takes more effort and time to build the same thing you could do in shorter time with Windows.  However, If LabVIEW were open source and free, you could theoretically build systems for just the cost of time and hardware.  I've been wishing over the years that they would support LabVIEW on Debian based systems as well.

I've created two Linux/LabVIEW based setups in the past and never had the issues I've run into with Windows.  Yes, it took more time and effort, but as far as I know - the one(s) I created (circa 2004-5) have been working reliably without issue or have even required any troubleshooting or support since their release.  One is running Mandrake and the other an early version of Fedora.

Edited December 31, 2020 by Bryan

[Neil Pate]

5 hours ago, Bryan said:

I agree, I have garnered great disdain for Winblows over the years as far as the negative impacts to our testers from updates mandated by IT departments, obsolescence, the pain to install unsigned drivers, just to name a few.  I would hate to see NI stop support for Linux as it has been growing in popularity and getting more user friendly.

Linux is a great and stable platform, though not for the faint of heart.  It takes more effort and time to build the same thing you could do in shorter time with Windows.  However, If LabVIEW were open source and free, you could theoretically build systems for just the cost of time and hardware.  I've been wishing over the years that they would support LabVIEW on Debian based systems as well.

I've created two Linux/LabVIEW based setups in the past and never had the issues I've run into with Windows.  Yes, it took more time and effort, but as far as I know - the one(s) I created (circa 2004-5) have been working reliably without issue or have even required any troubleshooting or support since their release.  One is running Mandrake and the other an early version of Fedora.

Maybe 2021 will be the year of Linux on the desktop, but given that this has been predicted every year since about 2003 I would not hold my breath.

LabVIEW will never be open source. It would not make sense, nobody outside of NI would be able to maintain it. LabVIEW is not the Linux kernel which is of huge interest to millions of others. The area of the intersection on the Venn diagram of skilled enthusiastic LabVIEW developers, ultra-skilled C++ developers, and those with enough spare time is approximately zero. The full complement of engineers at NI can barely make any progress into the CAR list, what hope is there for anyone else?

Edited December 31, 2020 by Neil Pate

[LogMAN]

It could be open source and still be maintained by NI, as long as they have a way to generate revenue. There is also great potential in the NXG platform, which - as far as I know - is written in C#. Even if LabVIEW is not of interest to millions of people, keep in mind that most open source projects only receive contributions from a small portion of their users.

The Linux kernel is probably not a good comparison, because it is orders of magnitudes more complex than LabVIEW. Nevertheless, Linux "only" received contributions from approx. 16k developers between 2005 and 2017 - 2017 Linux Kernel Report Highlights Developers’ Roles and Accelerating Pace of Change - Linux Foundation. Compare that to relatively young projects as Visual Studio Code (~1400 contributors), or the .NET Platform (~650 contributors). These are projects with millions of users, but (relatively speaking) few contributors.

2 hours ago, Neil Pate said:

The full complement of engineers at NI can barely make any progress into the CAR list, what hope is there for anyone else?

It depends. Companies might be willing to pay developers to fix issues. Enthusiasts might just dive into the code and open a pull-request with their solution. Some items might not be of particular importance to anyone, so they are just forgotten.

[ShaunR]

1 hour ago, Neil Pate said:

Maybe 2021 will be the year of Linux on the desktop, but given that this has been predicted every year since about 2003 I would not hold my breath.

It never will be until they resolve their distribution issues which they simply do not even acknowledge. Even Linus Torvalds refuses to use other distro's because of that.

What Windows did was to move common user space features into the kernel. The Linux community refuses to do that for ideological reasons. The net result is that application developers can't rely on many standard features out-of-the-box, from distro-to-distro, therefore fragmenting application developers across multiple distro's and effectively tieing them to specific distro's with certain addons. Those addons also have to be installed by the end-user who's level of expertise is assumed to be very high.

[Mefistotelis]

21 hours ago, ShaunR said:

application developers can't rely on many standard features out-of-the-box, from distro-to-distro, therefore fragmenting application developers across multiple distro's

There are two APIs to graphical systems: X-window and Wayland.

X-window contains compatibility layer for Wayland, Wayland contains compatibility layer for X-window. And most libraries which help creating GUIs allow to compile the same user code for both.

 

Microsoft won by donating Windows to schools, and providing courses for teachers. This paid out over years, making Windows a template by which all OSes are judged.

Now, at least is EU, there is a movement to require open-source OS in all public institutions. This should, over years, remove some of that bias.

 

[Rolf Kalbermatter]

20 hours ago, Mefistotelis said:

There are two APIs to graphical systems: X-window and Wayland.

X-window contains compatibility layer for Wayland, Wayland contains compatibility layer for X-window. And most libraries which help creating GUIs allow to compile the same user code for both.

Microsoft won by donating Windows to schools, and providing courses for teachers. This paid out over years, making Windows a template by which all OSes are judged.

Now, at least is EU, there is a movement to require open-source OS in all public institutions. This should, over years, remove some of that bias.

XWindows is not the main problem, although admittedly not the most easy API to tackle UI drawing. I think QT would be a lot easier but there you have licensing issues if you are not a truly open source project. But XWindows as an API is pretty standardized and has very few of the problems Shaun alluded too. But XWindows is just a basic UI API. Once you want to tackle things that are more user related you end up with a myriad of different desktop management standards that are all fundamentally different and while there were some attempts to standardize things they are usually not much more than recommendations that different projects adhere to in very different ways.

Also another problem in the Linux world are various system interfaces that sometimes change on an eye wink and also can greatly vary between Linux distributions. And if they don't  change entire subsystems just because they can, it is quite common to make binary incompatible API changes that require often specific version of libraries and aren't upwards compatible at all.

So if you want to install library XY you end up needing library Z, V, A and T all in specific versions except that library ZV needs some of these in different versions and if your project depends both on XY and ZV you are screwed. That each of those Linux distributions uses their own packaging system doesn't help this at all either. It's not just the repositories that vary but also the format, dependency tracking and all that.

If you want to develop an application like LabVIEW that should support all major Linux distributions you end up spending countless hours of debugging and code tweaking to work around all these kind of trouble only to have to do the whole work again 6 months from now. 

[ShaunR]

23 hours ago, Rolf Kalbermatter said:

So if you want to install library XY you end up needing library Z, V, A and T all in specific versions except that library ZV needs some of these in different versions and if your project depends both on XY and ZV you are screwed.

This is the problem that WinSxS solves, as you probably know.

The various Linux packaging systems aren't much help here either. There is, of course, a binary version control under Linux that utilises symlinks-usually the latest version is pointed to though. That is where we end up trying to find if the version is on the machine at all and then creating special links to force an application to use a particular binary version with various symlink switches to define the depth of linking. It's hit-and-miss at best whether it works and you can end up with it seeming to work on the dev machine but not on the customers as the symlink tree of dependencies fails. That resolution needs to be handled much better before I re-instate support for the ECL under Linux again.

And like Rolf says, that has to be done again in 6 (I argue weeks, not months) for the release of a new version in order for the application to continue working when there have been zero changes to the application code.

Edited January 3, 2021 by ShaunR

[Rolf Kalbermatter]

On 1/2/2021 at 8:51 PM, ShaunR said:

This is the problem that WinSxS solves, as you probably know.

Yes, except that without WinSxS you had one problem, with WinSxS you end up having several more problems! 😀 

While maintaining binary compatibility across library versions requires some real discipline, abandoning that and trying to solve it with something like WinSxS is simply getting you further down the rabbit hole.

[Antoine Chalons]

In reply to Neil's opening, here's my 2 cents about what I suggest NI should do :

From what I read in this thread

It seems that NI's NXG dev team was made of people who didn't have enough love for LV-CG- or enough experience using LV-CG for real world applications.

Well now that NI's plan is to move forward with LabVIEW, my suggestion is that they make every NXG dev spend 50% of their time contributing on LabVIEW related open source project.

There's a lot of great project on GitHub, Bitbucket, GitLab, etc. started by passionate LabVIEW users who have the greatness to share their toolkits, frameworks, API, etc.

They have limited resources in most cases, so now that NI has a full team of developers with no real purpose and and not enough understanding of what makes LV-CG great, then let's make them contribute to growing the LV-CG eco-system.

 

edit :

if you agree >> https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Make-NXG-dev-team-contribute-to-LV-related-open-source-projects/idi-p/4110996

Edited January 7, 2021 by Antoine Chalons

[Neil Pate]

3 hours ago, Antoine Chalons said:

In reply to Neil's opening, here's my 2 cents about what I suggest NI should do :

From what I read in this thread

It seems that NI's NXG dev team was made of people who didn't have enough love for LV-CG- or enough experience using LV-CG for real world applications.

Well now that NI's plan is to move forward with LabVIEW, my suggestion is that they make every NXG dev spend 50% of their time contributing on LabVIEW related open source project.

There's a lot of great project on GitHub, Bitbucket, GitLab, etc. started by passionate LabVIEW users who have the greatness to share their toolkits, frameworks, API, etc.

They have limited resources in most cases, so now that NI has a full team of developers with no real purpose and and not enough understanding of what makes LV-CG great, then let's make them contribute to growing the LV-CG eco-system.

 

edit :

if you agree >> https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Make-NXG-dev-team-contribute-to-LV-related-open-source-projects/idi-p/4110996

I think the NXG team was outsourced to a C# dev house outside of the US. I suspect the contract has been terminated.

[crossrulz]

My understanding is that NXG is a full platform effort, not just LabVIEW.  The LabVIEW part was scrapped, not everything else.  I suspect the devs for LabVIEW NXG have already been moved on to work on Instrument Studio, TestStand (2020 has the NXG look), VeriStand, Flex Logger, etc.

[Antoine Chalons]

On 1/7/2021 at 1:32 PM, Neil Pate said:

I think the NXG team was outsourced to a C# dev house outside of the US. I suspect the contract has been terminated.

My informations from inside NI is that this is largely untrue.

NXG team will be re-assigned to other projects and a large part focusing on non-Windows OS support 😮

I don't have much details but different sources corroborate this.

Edited January 20, 2021 by Antoine Chalons

[Neil Pate]

1 hour ago, Antoine Chalons said:

NXG team will be re-assigned to other projects and a large part focusing on non-Windows OS support 😮

That is good to hear.

[Sparkette]

On 12/28/2020 at 8:32 AM, ShaunR said:

But be careful what you wish for. The probable solution to the demands for free stuff will ultimately end up as LabVIEW-as-a-service.

You just had to say it...

[Neil Pate]

2 hours ago, flarn2006 said:

You just had to say it...

Ouch.