4 ms·

I think that it is interesting that testing plays such a part in these plans. I guess it shouldn’t be a surprise after so many years of TDD, Clean Code and what

by devjab 2y ago

I think that it is interesting that testing plays such a part in these plans. I guess it shouldn’t be a surprise after so many years of TDD, Clean Code and whatever nonsense the pseudo industry of “best practices” has been successfully selling. Odd on its own considering software seems to be just as broken as it was 20 years ago despite all these efforts. Anyway, if it was me I would look closer at how NASA build things. Which includes testing, but the key tool for finding actual programming errors was assertions. I’ve worked in medial software for a short while. The key features of development when lives are at stake are, assertions, avoid interpretation and no dynamic memory allocation. You should test things, but your assertions should catch any programming errors without a test/debug suite. You should never use an interpreted language, because that is a head ache you don’t want, but you also shouldn’t parse data like JSON. If you need to send data you send bytecode. You do this because you really don’t want dynamic memory allocation in software that will kill people if it fails. Now a little anecdote. In Denmark we have digital elections, not the voting but the voter registration and the system where each municipality reports the results. These systems run on COBOL and are ancient. There has been multiple attempts to replace them with “modern” software, because the old system can only be run by one private company and that is a monopoly. This is because we privatised the sector 20ish years ago. Anyway, every attempt at replacing it with modern long term software has failed, and a big part of the reason is because people have forgotten how to write code which isn’t infected with all sorts of OOP bullshit. So even the best suppliers and large companies like IBM have failed to make something with the same resilience. It’ll be interesting to see if we’re also going to infect embedded software with these things as the public sector decides to enter and hand out “best practices”.

rramadass 2y ago
Great points! Regarding assertions what techniques/practices did you guys follow? What did you do when an assertion failed? I myself am a fan of DbC and hence am interested in knowing more about how others use/modify/extend the technique. > If you need to send data you send bytecode. I presume you mean some encoding of binary-to-text; eg. base64 etc. ?
- devjab 2y ago
  We used runtime assertions both as executable documentation and to avoid system corrution by failing on any false. Since you can't just stop a critical system we would use triple modular redundancy ultimately leading to devices running in a "safe state". If this happened you would need to get your device recalibrated but you wouldn't die. Base64 would require dynmaic memory, you would likely use a packed struct. How you would do it depends on your compiler, but we would use #pragma.
  - boomlinde 2y ago
    You can parse and encode JSON without dynamic memory allocation. You can encode base64 without dynamic memory allocation, and you can even decode it in-place. You just need to know the appropriate buffer sizes for a valid payload. For base64 this is a trivial function of the input size. For a streaming decoder you don't even need more than a fixed few bytes of state. I am not arguing that either of these are appropriate for your application, particularly not base64, which doesn't address the basic problem of representing structured data, but it isn't true that they require dynamic allocation, which is good to keep in mind if you ever find yourself in need of these encoding schemes in a resource constrained system.

by devjab 2y ago

rramadass 2y ago

Great points! Regarding assertions what techniques/practices did you guys follow? What did you do when an assertion failed? I myself am a fan of DbC and hence am interested in knowing more about how others use/modify/extend the technique. > If you need to send data you send bytecode. I presume you mean some encoding of binary-to-text; eg. base64 etc. ?

devjab 2y ago
We used runtime assertions both as executable documentation and to avoid system corrution by failing on any false. Since you can't just stop a critical system we would use triple modular redundancy ultimately leading to devices running in a "safe state". If this happened you would need to get your device recalibrated but you wouldn't die. Base64 would require dynmaic memory, you would likely use a packed struct. How you would do it depends on your compiler, but we would use #pragma.
- boomlinde 2y ago
  You can parse and encode JSON without dynamic memory allocation. You can encode base64 without dynamic memory allocation, and you can even decode it in-place. You just need to know the appropriate buffer sizes for a valid payload. For base64 this is a trivial function of the input size. For a streaming decoder you don't even need more than a fixed few bytes of state. I am not arguing that either of these are appropriate for your application, particularly not base64, which doesn't address the basic problem of representing structured data, but it isn't true that they require dynamic allocation, which is good to keep in mind if you ever find yourself in need of these encoding schemes in a resource constrained system.