3 ms·

> There's only a few articles in my collection on asynchronous systems (outside I/O) because they're so hard to verify. GRR isn't hard just time consuming. Yes

> There's only a few articles in my collection on asynchronous systems (outside I/O) because they're so hard to verify. GRR isn't hard just time consuming. Yes its not fully verified >I also figured you were forced to use aging crap that motivated you to try alternatives. I'm actually a polygot programmer trying to pay the bills. Working in aging tester frameworks pays a lot more then web development. I like Rust b/c its basically C-With-A-Type-System. Its still very easy to reason about how the Cee-LangVM will handle your code. But yes. Working in a code base from the 80's and switching to Rust is lovely. :.:.: The core purpose is exception logging. A lot of the exceptions will get mutated/modified before being reported. "Servo drive failed." is a lot less useful then "Servo communication fault 0x274077343" which I've memorized to tell me that a power surged knocked a comport off line.

nickpsecurity 11y ago
Oh shit, replied to you at exact time you replied to me here: https://news.ycombinator.com/item?id=10954970 https://news.ycombinator.com/item?id=10954970 "GRR isn't hard just time consuming. Yes its not fully verified" I believe it now after pulling papers. I even know exactly how hard it is and what parts are decidable. " Working in aging tester frameworks pays a lot more then web development." Makes sense. It's why I advise against commodity jobs. The niche or unpopular stuff usually pays better. Not always, but usually. "The core purpose is exception logging. A lot of the exceptions will get mutated/modified before being reported. "Servo drive failed." is a lot less useful then "Servo communication fault 0x274077343" which I've memorized to tell me that a power surged knocked a comport off line." Hmm. That's more straight-forward than most async. Just detail-oriented work as you said. The taint idea of tracking exact sequence of mutations combined with design-by-contract tracks of function call contexts would certainly help that. How much I can't say as your combination of tech obscures it. Don't know enough Labview mainly. Microsoft has things like Spec# and verifiers for C# part with VB6 easy to ignore if you keep logic out of it. So, you're in better shape than many doing multi-language, legacy work. At least as far as verification concerns.
- valarauca1 11y ago
  >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.
  - nickpsecurity 11y ago
    "But NI will compensate lost development time with free hardware so companies love it." WOW! I never even thought about that business angle to dealing with shoddy tech. Thanks for the warnings. "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." Glad you at least have an easy approach to dealing with that nonsense. :)
    - valarauca1 11y ago
      >WOW! I never even thought about that business angle to dealing with shoddy tech. Thanks for the warnings. Well most companies don't supply hardware and software. Also NI's hardware is great, best in the business. Their software is complete poop.

nickpsecurity 11y ago

Oh shit, replied to you at exact time you replied to me here: https://news.ycombinator.com/item?id=10954970 https://news.ycombinator.com/item?id=10954970 "GRR isn't hard just time consuming. Yes its not fully verified" I believe it now after pulling papers. I even know exactly how hard it is and what parts are decidable. " Working in aging tester frameworks pays a lot more then web development." Makes sense. It's why I advise against commodity jobs. The niche or unpopular stuff usually pays better. Not always, but usually. "The core purpose is exception logging. A lot of the exceptions will get mutated/modified before being reported. "Servo drive failed." is a lot less useful then "Servo communication fault 0x274077343" which I've memorized to tell me that a power surged knocked a comport off line." Hmm. That's more straight-forward than most async. Just detail-oriented work as you said. The taint idea of tracking exact sequence of mutations combined with design-by-contract tracks of function call contexts would certainly help that. How much I can't say as your combination of tech obscures it. Don't know enough Labview mainly. Microsoft has things like Spec# and verifiers for C# part with VB6 easy to ignore if you keep logic out of it. So, you're in better shape than many doing multi-language, legacy work. At least as far as verification concerns.

valarauca1 11y ago
>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.
- nickpsecurity 11y ago
  "But NI will compensate lost development time with free hardware so companies love it." WOW! I never even thought about that business angle to dealing with shoddy tech. Thanks for the warnings. "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." Glad you at least have an easy approach to dealing with that nonsense. :)
  - valarauca1 11y ago
    >WOW! I never even thought about that business angle to dealing with shoddy tech. Thanks for the warnings. Well most companies don't supply hardware and software. Also NI's hardware is great, best in the business. Their software is complete poop.