[lokimedes]

While some rely on Mathematica most at Cern uses ROOT for data science. The impact on the science program is more likely to come from ditching Oracle databases and LabView... That said, this is an IT department initiative, users also have access to software from their home institutes.

[dguest]

There's a pretty sharp migration away from ROOT to numpy / pandas these days (at least in the younger generation).

[deven88]

Is there any reliable and good opensource alternative of LabView ?

[cycomanic]

I would argue any dynamic programming language is a good alternative to labview. I'm a proponent on using python for labautomation (we run workshops at some major optics conferences, see http://python4photonics.org for an unfortunately somewhat out of date summary about some of what we do). In my experience labview is a mess, it's only momentum (in particular drivers provided by vendors, but that is changing) that keeps it going. I find labview code developed by amateurs is an unmaintainable mess. Grad students pass along code from on generation to the next without anyone daring to fix some of the glaring bugs. Really use anything but labview, even if it's the buggy matlab instrument toolbox.

[nikofeyn]

> I would argue any dynamic programming language is a good alternative to labview.

why? labview is not a dynamic programming language.

> I'm a proponent on using python for labautomation (we run workshops at some major optics conferences, see http://python4photonics.org for an unfortunately somewhat out of date summary about some of what we do).

python is orders of magnitude slower than labview and doesn't have any ability like labview to do true mulithreading and multicore execution.

> In my experience labview is a mess, it's only momentum (in particular drivers provided by vendors, but that is changing) that keeps it going. I find labview code developed by amateurs is an unmaintainable mess. Grad students pass along code from on generation to the next without anyone daring to fix some of the glaring bugs. Really use anything but labview, even if it's the buggy matlab instrument toolbox.

in my experience, code developed by amateurs in any language is an unmaintainable mess. that isn't a valid critique of a language. the same thing happens with amateurs who code in python. i feel python, as a language is a mess, and also as an ecosystem. packages quickly become obsolete or only supported in certain versions.

drivers for labview are really not the thing keeping it going, at all. most third-party (i.e., non-national instruments) companies provide drivers in the form of c/c++ DLLs, .NET DLLs, and LabVIEW APIs. since labview can call any of these, this is indeed a plus. however, it is the ability in labview to program windows, real-time linux, and FPGA applications and the availability of natural instruments hardware that easily integrates into this software platform that makes it a killer. you can do some programming of NI hardware with .net languages, python, or c/c++, but you cannot do the full gamut of windows to real-time embedded linux to fpga. and if you know what you are doing, then the dataflow nature of labview makes it extremely easy to build and maintain large applications.

[mhneu]

Exactly. Labview is a mess anytime more than one person has to maintain a codebase. Source control tools are absolutely KEY to using any language for automation. Which mostly rules out Labview.

Do you have any more workshops/hackathons scheduled?

[lavezza]

I know I'm late to the discussion, but I've worked on a very large LabVIEW program with ~10 active developers and source control was extremely important. But I'm talking about SVN with the option to lock files. If by source control you mean "distributed, file merge-based" source control like git, than I would agree there aren't good options for LabVIEW. But a central repo with file locking, small changes and LabVIEW graphical diff worked fine.

[nikofeyn]

not even close. it would be very surprising to me if cern is getting rid of their labview dependence, as it will undoubtedly increase their development time and robustness (if they are doing things right).

[fock]

I'm not even sure where the notion appeared that they have a systemic, large scale labview dependence. I always thought their data acquisition pipeline was a lot of custom electronics, piping data into fibre-channel? Not exactly sure, how labview fits in there?

[nikofeyn]

i know that they use labview and national instruments for some components, but my comment was more along the lines of "if they have some large dependence on labview and ni hardware, then [it would be very surprising...]".

however, it does seem they have used it a lot, at least in the past. they have a site license (which is uncommon except for universities) and what appears to be a large internal component written in labview.

https://readthedocs.web.cern.ch/display/MTA/LabVIEW+support

https://readthedocs.web.cern.ch/display/RADE/RADE

https://sine.ni.com/cs/app/doc/p/id/cs-10795

http://sine.ni.com/cs/app/doc/p/id/cs-16048

if someone is heavily using ni hardware and software, then there are really not many alternatives at all.