NI abandons future LabVIEW NXG development

[CaseyM]

21 hours ago, Maciej Kolosko said:

In reality my biggest concern is that the G language and the IDE of LabVIEW are joined at the hip and that is I think the crux of the issue. In order for G to survive as a viable option for the future it would need to be de-coupled from the old IDE of LabVIEW. But it seems to me like now they will be entangled together till the bitter end... until the user base of LabVIEW retires, and no new cutting edge projects will be created in G, not because G sucks but because LabVIEW IDE is holding it back.

This 100%. I guess we have to all wait and see, but I'm not feeling very good about this for my long-term career aspirations at the moment.

[ShaunR]

46 minutes ago, CaseyM said:

This 100%. I guess we have to all wait and see, but I'm not feeling very good about this for my long-term career aspirations at the moment.

 

NXG had an inherent fatal flaw. It wasn't (and would never be) cross platform. That was exacerbated by the slow progress of development to the point that NI lost the T&M market to Python. It was a good decision, rarely seen by large multinationals.

 

The good news is that they figured out how to represent VI's as XML properly and convert the VI format to it. We have already seen that format creeping into LabVIEW in the form of projects and libraries but the VI's themselves remained propriety. Porting the ability to represent VI's in XML would be a huge improvement to LabVIEW enabling source control tools to work properly-the bane of LabVIEW for over a decade.

 

The other much needed LabVIEW improvement is internationalisation. We have had UTF8 for a long time but have been unable to display it. Instead, we had a *hack* that never worked right and never would with the resources allocated to NXG.  It's been fraught to try and display it and other means were found. If the lessons learnt from NXG means we can display UTF8, that would be another huge improvement to LabVIEW and, I think, easier than UTF16/32 without impacting current string manipulation.

 

I'm ambivalent about the IDE. It works fine enough for me to develop but it is a poor user interface for applications. I got around this user interface problem a long time ago with Websockets so, although a bit more effort, it's not a big issue anymore. I hated the restrictive framing of NXG and it seemed to promote huge monolithic diagrams with the zoom facility. The standard LabVIEW IDE encouraged me to make small, encapsulated code modules and I could see many parts of the architecture at once when debugging.

 

If shelving NXG means the first two issues get addressed by either more effort or porting; those alone would mean, IMO, LabVIEW has a future - a bright future. It would once again be a cross-platform equivalent to all the other text languages with all the advantages *over* the other languages that it originally had.

Edited December 7, 2020 by ShaunR

[X___]

23 hours ago, X___ said:

The official statement (by two top brasses, not a mere webmaster) is not particularly crystal clear as to what is forthcoming. Coming right after the Green New Deal campaign and in the midst of the pandemic, it might just as well be a forewarning of major "reorganization" within NI... The surprise expressed by AQ in a different thread would seem to support this hypothesis.

Maybe that is relevant: https://www.cmlviz.com/recent-development/2020/10/29/NATI/national-instruments---announced-workforce-reduction-plan-intended-to-accelerate-its-growth-strategy-and-further-optimize-operations-cost-structure

Another variant: https://www.honestaustin.com/2020/10/30/mass-layoffs-at-national-instruments-remedy/ ("Thursday, he said that sales staff and administrative staff would be most affected", so maybe unrelated to NXG's demise after all...)

And from the top dog's mouth: https://www.reddit.com/r/Austin/comments/jkyid6/ni_is_laying_off_9_of_its_global_workforce/

Edited December 7, 2020 by X___
added link

[Phillip Brooks]

It seems to me that the biggest adoption stoppers I saw re: NXG were the availability of NI Toolkits that hadn't been ported.

If the timescale to complete those big toolkit conversions was also going to impede expansion as a large system-solution provider, management may have asked,

"If we already have the software and hardware in place today to do that, what does NXG offer long term?"

[Maciej Kolosko]

2 hours ago, ShaunR said:

NXG had an inherent fatal flaw. It wasn't (and would never be) cross platform.

I agree with Shaun that lack of support for other platforms is fatal. Although I remember speaking with NI folks early on and I think the idea as far as I understood it during one of the CLA summits that the IDE of NXG was going to be Windows only, but I do think they were thinking of having runtimes capable of running on different OSes. However as far as it stands right now for NXG 5.0  I don't see any indication of the possibility of running NXG code on a platform other than Windows...  ( I'm getting' old I might not be remembering stuff correctly anymore )

So I think the plan was there to be able to deploy on different platforms and OS flavors early on, but with all the other things not going right I think they never got to it and it kept getting pushed down the backlog.

[ShaunR]

16 hours ago, Maciej Kolosko said:

I agree with Shaun that lack of support for other platforms is fatal. Although I remember speaking with NI folks early on and I think the idea as far as I understood it during one of the CLA summits that the IDE of NXG was going to be Windows only, but I do think they were thinking of having runtimes capable of running on different OSes. However as far as it stands right now for NXG 5.0  I don't see any indication of the possibility of running NXG code on a platform other than Windows...  ( I'm getting' old I might not be remembering stuff correctly anymore )

So I think the plan was there to be able to deploy on different platforms and OS flavors early on, but with all the other things not going right I think they never got to it and it kept getting pushed down the backlog.

Considering the distribution issues with Linux variants - and often within the same variant - where even things compiled on a different machine often won't work unless everything is "just-so"; that was at best a pipe dream. The main reason I stopped supporting Linux for ECL was for this very reason. The only safe way to build executables is on the target Linux variant - preferably on the same machine - and for that you would need the full LabVIEW. It's one of the main reasons why interpreted languages are so prevalent on Linux platforms (PHP, Python, Javascript etc).

Edited December 8, 2020 by ShaunR

[hooovahh]

Yeah deploying to a target that I don't have the option to run source on the same OS sounds like a nightmare.  Where I'm from that "throwing it over the fence" which usually results in dozens of builds trying to figure troubleshoot the issue.  I'll agree this is a bad situation.  But I think it would be worst if NI made the same decision in 2 years.  LabVIEW is dead, long live LabVIEW. (hopefully)

[Metroid9]

What's most likely to happen to the popularity of LabVIEW in the next couple years? After reading some of these posts, the future looks grim. However, LabVIEW is an integral part of the software that is used in most industries. Could LabVIEW be succeeded by a better graphical programming language without the limitations of LabVIEW in the near future?

[Maciej Kolosko]

3 hours ago, Metroid9 said:

What's most likely to happen to the popularity of LabVIEW in the next couple years?

The future is Python for many of the applications, it is easy to get in to for newcomers to programming, works great has a strong package management system and large community, and can be applied to virtually any OS you can think of, as well as it can be even used to program GPUs if you are so inclined.

The huge advantage of using G and LabVIEW is that paired with NI Hardware, in the hands of someone skilled with LV you can bang out a solid prototype of a product or a Test and Measurement system so fast it will make people's heads spin.
NI hardware is absolutely top notch for High End use cases or rapid prototyping, complex one offs , scientific use or complicated Test and Measurement end of line test space.

However in the IoT there is strong competition for the NI SB RIO line up, for a SB RIO you will pay 1500 US.

There are so may cheap programmable & capable pieces of hardware, such as Jetson Nano (ARM7+NVidia GPU for vision) or Raspberry PI (ARM7 1.4 GHz with 8GB RAM) or even Asus Tinker Board ... which will serve so many purposes and have onboard GPIO and can be purchased for 50-60 bucks ... that in that space Python paired with Linux knowledge is really making headway.

And if you want to go with ZynQ from Xlinix you can get a board with FPGA ~300 Bucks, which is basically the same HW as SB RIO, all you have to do is use different software tools.

If NI would consider unlocking the ability use NI FPGA with the ability to deploy to non NI Hardware ... I think this is where G absolutely would take off like wildfire and be used on millions of IoT devices everywhere in the world that are powered by and ARM7 + FPGA module... but as it stands now if you use NI FPGA you must deploy on a target you've purchased from NI.

3 hours ago, Metroid9 said:

Could LabVIEW be succeeded by a better graphical programming language without the limitations of LabVIEW in the near future?

I'll really be a stickler but if we're talking about the programming language we should talk of G. LabVIEW the IDE.

Never say never, I am not aware of any other graphical programming language which could be used for general purpose programing and is as complete as G. If you have come across something interesting I would like to look at it, but I feel that it would be at best an academic project, which I would not use in production code.

 

Edited December 9, 2020 by Maciej Kolosko

[brian]

The other day, I wrote up a lengthy response to a thread about NXG on the LabVIEW Champions Forum.  Fortunately, my computer blue-screened before I could post it--I kind of had the feeling that I was saying too much and it was turning into a "drunk history of NXG" story.  Buy me some drinks at the next in-person NIWeek/CLA/GLA Summit/GDevCon, and I'll tell you what I really think!

First, I'll say that abandoning NXG was a brave move and I laud NI for making it.  I'm biased; I've been advocating this position for many years, well before I left NI in 2014.  I called it "The Brian Powell Plan".   

I'm hopeful, but realistic, about LabVIEW's future.  I think it will take a year or more for NI to figure out how to unify the R&D worlds of CurrentGen and NXG--how to modify teams, product planning, code fragments, and everything else.  I believe the CurrentGen team was successful because it was small and people left them alone (for the most part).  Will the "new world without NXG" return us to the days of a giant software team where everyone inside NI has an opinion about every feature and how it's on the hook for creating 20-40% revenue growth?  I sure hope not.  That's what I think will take some time for NI to figure out.

Will the best of NXG show up easily in CurrentGen?  No!  But I think the CurrentGen LabVIEW R&D team might finally get the resources to improve some of the big architectural challenges inside the codebase.  Also, NI has enormously better product planning capability than they did when I left.

I am optimistic about LabVIEW's future.

[Neil Pate]

1 hour ago, brian said:

I believe the CurrentGen team was successful because it was small and people left them alone (for the most part).

Conversely, it feels like NXG was built by devs not actually intimately familiar with LabVIEW.

[ShaunR]

5 hours ago, Maciej Kolosko said:

If you have come across something interesting I would like to look at it, but I feel that it would be at best an academic project, which I would not use in production code.

Not really general purpose (yet?) but you mentioned IoT so Node-Red is worth looking at for the not-too-distant future.

[X___]

17 hours ago, brian said:

The other day, I wrote up a lengthy response to a thread about NXG on the LabVIEW Champions Forum.  Fortunately, my computer blue-screened before I could post it--I kind of had the feeling that I was saying too much and it was turning into a "drunk history of NXG" story.  Buy me some drinks at the next in-person NIWeek/CLA/GLA Summit/GDevCon, and I'll tell you what I really think!

First, I'll say that abandoning NXG was a brave move and I laud NI for making it.  I'm biased; I've been advocating this position for many years, well before I left NI in 2014.  I called it "The Brian Powell Plan".   

I'm hopeful, but realistic, about LabVIEW's future.  I think it will take a year or more for NI to figure out how to unify the R&D worlds of CurrentGen and NXG--how to modify teams, product planning, code fragments, and everything else.  I believe the CurrentGen team was successful because it was small and people left them alone (for the most part).  Will the "new world without NXG" return us to the days of a giant software team where everyone inside NI has an opinion about every feature and how it's on the hook for creating 20-40% revenue growth?  I sure hope not.  That's what I think will take some time for NI to figure out.

Will the best of NXG show up easily in CurrentGen?  No!  But I think the CurrentGen LabVIEW R&D team might finally get the resources to improve some of the big architectural challenges inside the codebase.  Also, NI has enormously better product planning capability than they did when I left.

I am optimistic about LabVIEW's future.

This is material for the Ph D thesis on the NXG fiasco I was fearing (in another related thread on this forum) would never be written... and is now lost to the microcosm of LabVIEW Champions (I understand knuckleheads like us were not intended to be privy to this juicy stuff)

It seems that one way to give a future (or definitely burry any hopes for LabVIEW at the sight of the quagmire) would be to open source it.

[ShaunR]

13 minutes ago, X___ said:

This is material for the Ph D thesis on the NXG fiasco I was fearing (in another related thread on this forum) would never be written.

You don't need a Ph D thesis. Some people thought they could do <INSERT PROJECT HERE> better with the latest whiz-bang stuff and convinced management they could do it. I've seen it a hundred times.

[Antoine Chalons]

Laying off 9% of the workforce, mostly in sales and admin. It might indicate a dramatic change of strategy. New CEO, new logo, new strategy.

For sure there's a lot going on inside of NI.

Hope for the best, prepare for the worst. Learn Python?

[smithd]

11 hours ago, ShaunR said:

You don't need a Ph D thesis. Some people thought they could do <INSERT PROJECT HERE> better with the latest whiz-bang stuff and convinced management they could do it. I've seen it a hundred times.

WPF is 14 years old, maybe not so 'whiz-bang'

[Mads]

1 hour ago, Antoine Chalons said:

Laying off 9% of the workforce, mostly in sales and admin. It might indicate a dramatic change of strategy. New CEO, new logo, new strategy.

The new branding is not my cup of tea so hopefully that does not tell too much about the new management. Reducing (the need for) administrative positions could be a good thing.

As for raising the quality and speed of the LabVIEW development I hope they use their savings to keep and build a highly skilled, tight nit, centralized team.

The developers should all worship Graphical programming🧚‍♂️🧚‍♀️, even though many of themselves have to be proficient with many an awful text based tool.  If they have seen the light from the many lessons  about the uniqueness of graphical vs textual programming embedded in current LabVIEW, they might not stray to the dark path of NXG 😀 Steal the best (the graphics) of the textual worlds, keep the spirit and innovations of G. The first letter graphic in the next LabVIEW should be G.👼

Edited December 10, 2020 by Mads

[ShaunR]

3 hours ago, smithd said:

WPF is 14 years old, maybe not so 'whiz-bang'

A decade is about how long things need to percolate through the learning institutions to reach a critical mass of employees skilled in it. Relatively speaking - yes, it is "whiz-bang" when compared to Javascript. C++ et. al. Even Rust is 10 years old. C# is 20  

We really haven't moved on much from about 30-40 years ago when there was truly spectacular explosion of ground breaking invention and innovation in software and hardware by some very special people...and one of those was LabVIEW. We've tweaked, revised and added spokes to the existing wheels on the back of huge leaps forwards in hardware technology that has hidden the industry's mediocrity.

Edited December 10, 2020 by ShaunR

[brian]

On 12/8/2020 at 11:22 PM, Neil Pate said:

Conversely, it feels like NXG was built by devs not actually intimately familiar with LabVIEW.

There are some (including me) who believe that more people in LabVIEW R&D (both CurrentGen and NXG) should better understand how LabVIEW is used in the real world.

Regardless, there is a lot of truthiness to your comment, and the reality is way more complicated to explain until I've had at least a couple of beers in me.

19 hours ago, X___ said:

It seems that one way to give a future (or definitely burry any hopes for LabVIEW at the sight of the quagmire) would be to open source it.

I've thought a lot about this, but I just don't think it would be a successful open source project.  It's not like it's a small library that's easy for someone to understand, much less modify.  You need guides with really strong flashlights to show you the way.  I speak from experience.  When I led the team that created 64-bit LabVIEW 10+ years ago, I had to visit every nook and cranny in the source code, and find the right people with the right flashlights.

I think a more viable alternative (if NI didn't want to own LabVIEW any more) would be to spin it out as a subsidiary (or maybe non-profit?) along with the people who know the source code.  It wouldn't be super profitable, but might be strong enough to independently support its development.  The main impediment to this happening is that LabVIEW FPGA (and to a lesser extent, LabVIEW Real-Time) are really valuable to NI and probably too intertwined with the rest of LabVIEW for NI to keep FPGA and spin out the rest.

[Antoine Chalons]

1 hour ago, brian said:

I think a more viable alternative (if NI didn't want to own LabVIEW any more) would be to spin it out as a subsidiary (or maybe non-profit?) along with the people who know the source code. 

Has this option ever been evaluated by NI? I mean by the top management?

[X___]

3 hours ago, brian said:

I've thought a lot about this, but I just don't think it would be a successful open source project.  It's not like it's a small library that's easy for someone to understand, much less modify.  You need guides with really strong flashlights to show you the way.  I speak from experience.  When I led the team that created 64-bit LabVIEW 10+ years ago, I had to visit every nook and cranny in the source code, and find the right people with the right flashlights.

I think a more viable alternative (if NI didn't want to own LabVIEW any more) would be to spin it out as a subsidiary (or maybe non-profit?) along with the people who know the source code.  It wouldn't be super profitable, but might be strong enough to independently support its development.  The main impediment to this happening is that LabVIEW FPGA (and to a lesser extent, LabVIEW Real-Time) are really valuable to NI and probably too intertwined with the rest of LabVIEW for NI to keep FPGA and spin out the rest.

There is a problem right there (in the flash light story), but who is really surprised about it? 

Of course there would be a cost to open sourcing the code: cleaning it up and documenting it as the team fixes things up in the upcoming releases is something that would be expected from a pro team anyway.

They wouldn't have to accept any and all contributing candidate, and they wouldn't have to commit any and all contributions. But they might get some good feedback from dedicated believers (see e.g. https://openjdk.java.net/contribute/). At worse none, but that in itself might be a good indicator for management to take a hard look at LV's relevance. They could spin-off improvements to control/indicator modifications to the community and focus on the things that matter most to their core business.

You'd be surprised how focused debuggers would be at squishing those pesky bugs of yore... not mentioning expanding the capabilities of LV. There is no guarantee that LV would eventually rule the world (I don't think anyone of us has ever had this dream). But maybe it would give it a chance to not look hopelessly outdated.

The real obstacle seems to be the "NI culture". I have no idea what it is, but the recent past has painted it has rather quitoxic if not readily toxic. 

[brian]

50 minutes ago, X___ said:

Of course there would be a cost to open sourcing the code: cleaning it up and documenting it as the team fixes things up in the upcoming releases is something that would be expected from a pro team anyway.

Which might be the main impediment to open-sourcing it.  The developers working on both products are proud of their work and would be reticent to release it "as-is".  They'd want to spend the time to make it presentable to people without flashlights.  And NI wouldn't want to spend the money to do it.  For NI to choose the open-source route, I think they'd have to consider it the easy (read "cheap") way out, and this isn't it.

 

50 minutes ago, X___ said:

The real obstacle seems to be the "NI culture". I have no idea what it is, but the recent past has painted it has rather quitoxic if not readily toxic. 

Did you mean quixotic?  I'm not familiar with quitoxic, but it might be a jargon word.

Regardless, I am familiar with the NI culture and also with toxic cultures, and NI doesn't have a toxic culture.  Believe me on this.  It has a good--if not great--culture, with a few aberrations here and there.  Many of those aberrations have been sacked.   I wouldn't describe it as quixotic, either--I think the NXG decision was reluctantly chosen after years of angst.

If you would like to hear my stories about a toxic workplace culture, invite me back for a second night at the bar and I'll tell you all about it. 😮 

[hooovahh]

5 minutes ago, brian said:

If you would like to hear my stories about a toxic workplace culture, invite me back for a second night at the bar and I'll tell you all about it. 😮 

The first time you mentioned this I thought it was a nice gesture, now I think you are just desperate for friends...or an alcoholic.  I'm down.

[brian]

1 hour ago, X___ said:

They could spin-off improvements to control/indicator modifications to the community and focus on the things that matter most to their core business.

XControls, anyone?

More seriously, Jeff's vision is for more of LabVIEW to be written in LabVIEW, with the intent that it empowers users like us to extend it.

LabVIEW doesn't have to be open source to do that, and my optimism comes from the possibility that the R&D team is going to have more resources to increase extensibility.

Edited December 10, 2020 by brian

[brian]

1 minute ago, hooovahh said:

The first time you mentioned this I thought it was a nice gesture, now I think you are just desperate for friends...or an alcoholic.  I'm down.

"Nice gesture" depends on who's buying, and the other two are... not inaccurate.