>Don't know enough Labview mainly Don't learn it. Its a terrible language, and a worse IDE. Yeah you'll learn over 6 figures with 2 years experience. But you'l

>Don't know enough Labview mainly Don't learn it. Its a terrible language, and a worse IDE. Yeah you'll learn over 6 figures with 2 years experience. But you'll waste a lot of time debugging issues with the runtime itself, also the langauge itself isn't consistent which can lead to extreme headaches/development lagging. But NI will compensate lost development time with free hardware so companies love it. The tools for tracing/testing in Labview are annoying and kinda primitive. Hence why a separate callable logger is useful. Mainly in Labview all functions start out as heap allocated monands wrapped in a mutex. So basically every function has state initially. You then have to opt-out of this to get a pure function. >Hmm. That's more straight-forward than most async Well yes. We're not exactly concerned with verification of the asynchronous system. Just making sure everything happens in the right order, and each thread is actually doing what its commended to do. At a certain level you can abuse asynchronous systems to make certain measurements easier. Just assume your input has a half-Gaussian input lag level, and suddenly a 200 sample moving average becomes sufficient for smoothing data not jumping though hoops of fire doing weird data synchronization.