> If that is true, what is remarkable is the low death rate.
Death count is also very much under reported.[1] I am not able to find the reference but only testing count is reliable, positive case and death counts are highly under reported.
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.
> 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.
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?
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.
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).
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?
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.
Me and my wife are T1D since childhood. I have started with reusable glass syringe with bovine insulin then Insulin pen and recently switched to pump. Living in developing county and having diabetes is nightmare. Constant mood changes due to sugar imbalance and highly chaotic environment of developing county make the things more difficult. People and even doctors are not able to understand about this decease related situations. Since last 5 years, we are not able to decide whether we should have baby or not.
One of my friend was telling me that I am not participating much in adventure activities I smiled and told that for me, living life itself is far more adventurous.
DraftSight[1] is good tool for CAD and it is very similar to AutoCad. I am using it frequently. But it is free for only 2D drawing, it is the biggest limitation.
Recently, I started learning SQLite. I have some knowledge of python so I want to organize my information using SQL and python (Being electrical engineer, I am not coding for earning).
Earlier, we were depended on others (relatives and neighbors) for many things. Now dependency has reduced drastically, so there is no need for relationships. I have have seen strong bonding in neighborhood where they are economically weak.
[1] https://github.com/jupyterlite/jupyterlite