LabVIEW
Cross-platform alternative to LabVIEW
@lucian.grec wrote:
I think we're forced to deal with this cost one way or another.
The most recent feature was support for Apple silicon and thankfully that bridge was crossed by NI. Who's to say that in 5 years there won't be another breaking change like this that?The plan is to stick around on LV2023 but we need to plan ahead.
DLLs/frameworks could be an option but our code is pretty tightly coupled so we need some upfront investment there. We'd also need to separate the UI from the logic of the application.
Anyway these are specifics and don't really matter to the general question I had.
C# - not so much macOS afaik. Visual Studio is being retired for macOS so it doesn't look like a very promising alternative
Java - seems to be a better fit but what GUI library would you standardize on
Python - irrelevant for most of the application. we do have support for calling python script to extend the functionality of our application so we'd need python bindings in this new language.
I was assuming by "alternative to LabVIEW" you mend actually graphical programming.
I'm sure most C#, Java and Python programmers will say it's perfect (even the best) for cross-platform programming.
You don't need VS for C# programming. .NET has a build in C# compiler I use all the time 😁.
.NET (not C# per se) would be my best bet for cross platform development.
AFAIK, .NET Core is (like all .NET I think) open source, and AFAIK it will run on most OSs. .NET Multi-platform App UI (.NET MAUI) | .NET (microsoft.com) is specifically suited for cross platform UI design.
Also, even without VS running on MacOS, with unified framework an application build on Windows should (now or in the future) be able to run on MacOS. And Linux. And Windows. Maybe even Android.
This is all WIP, but it seem to proceed pretty fast. Faster than NI can keep up, I admit.
Search LabVIEW like a graph! 
@lucian.grec wrote:
C# - not so much macOS afaik. Visual Studio is being retired for macOS so it doesn't look like a very promising alternative
Java - seems to be a better fit but what GUI library would you standardize on
Python - irrelevant for most of the application. we do have support for calling python script to extend the functionality of our application so we'd need python bindings in this new language.
Well, it is highly unlikely that NI will reconsider the decision. Mac OS support was for years something that was based on one or two enthusiastic developers who were willing to go the extra mile and keep it working. That Jeffry Kodosky was still working at NI certainly did also help to delay the decision to retire LabVIEW for Macintosh.
My post was not meant to say that staying with the last version of LabVIEW for Mac is a long term solution. It's not even for Windows but for the Mac much less so. But it should give you several years in which you can consider and develop other options. It won't be easy.
Since you want to have cross platform support too, the contenders are very limited.
But I didn't know that Visual Studio Code for Mac will be retired. I thought this only applied to Visual Studio itself, not the open source variant Visual Studio Code. According to this C# (and other packages) for Visual Studio Code is still a fully supported option.
Some people claim that LabVIEW's UI looks very yesteryear, but I guess they never had to work with Java development. There UI development is stone age in comparison with LabVIEW. They do have layout engines, but if you want to do a somewhat complex UI, the automatic layout tends to be a major pitta, and doing it with fixed layout is an exercise in patience.
Python is of course the cool kid on the block that everyone scrambles to, but UI development isn't easy either and in terms of performance you quickly get into mixed mode development with external shared libraries if you want to do something serious.
As far as LabVIEW's multiplatform architecture goes, NI developed in the early days a multiplatform layer of managers entirely in C, that would do things like Memory, Windows, Network, File IO, and many more things. Then they build the rest of LabVIEW on those layers. It's a completely inhouse proprietary development, in some ways a C variant of what Trolltech later did in C++ with QT. Later they did move to C++ and new developments were made in that language, but the old standard C managers still are present and still a heavy part of the platform abstraction layer in LabVIEW. This is both LabVIEW's strength and Achilles heel at the same time. These managers are fairly well thought out but in some ways limited to what was possible in the 90ies of last century when programming in C. Extending them to support new features is usually a very tricky and time consuming task.
@lucian.grec wrote:
Wiebe, there must be some alternatives...after all there are plenty of applications running on both mac and windows. Just take any of JetBrains's IDEs or Matlab, Autocad, Audacity, LabVIEW, VSCode and probably many more. Worst case you can use Chromium and other web tech but I assume a solution of this kind would be very sluggish.
That crossed. See my previous post.
@Andrey_Dmitriev wrote:
@lucian.grec wrote:
Is Avalonia mature enough to compare to LV and do you see this company existing in 10 years? They seem like a small company.
Who knows... At least this is completely Open Source (and free, you don't need to pay subscription fee).
That doesn't reflect from the website at all. I stopped looking as it sure looks like a commercial product.
This didn't help:
@lucian.grec wrote:
What I meant by comparable to LabVIEW was more in terms of flexibility, UI capabilities and parallel programming(something like actors) not in terms of the language. At this early stage I'm open to any language. We've tried doing MVVM in LabVIEW but I think it mostly wasn't worth it at the end of the day due to the extra complexity.
IMHO, there is nothing even remotely comparable to LabVIEW. There used to be ActiveX libraries, also from others than NI that tried to do that. All of them dead now. There was some sort of initiative by some to do the same with .Net libraries. But I suppose most players in that field had been burned with their ActiveX attempts that were costly to develop and even more costly to maintain and not enough people were willing to pay handsomely for some "trivial" UI controls. So it never really took off.
The entire Microsoft debacle with different UI standards being replaced constantly with yet an even newer and cooler kid on the block and then abandoning the older standards more or less completely before the new standard even had caught up with the previous one, did certainly not help either.
There are some people who feel that the LabVIEW controls and UI look very last century, but as far as I'm concerned, I do not need always the newest and most shiny hype that is considered yesteryear in a few months anyhow. I still use predominantly the classic control style for non user facing VIs and the System style for user facing UI panels. Never liked the 3D "Modern" look, nor the NXG control palette, and the Silver palette looks horrible IMHO.
wiebe@CARYA wrote:
That doesn't reflect from the website at all. I stopped looking as it sure looks like a commercial product.
Same here, was put off by the license costs of this one..... Almost makes LV look cheap in comparison. Pricing "Per App" or even "Per app, per year"
OTOH, even they include a "perpetual fallback" which enables the version of the year of purchase to still be functional even after a subscription expires. Just like the old Developer Suites.
