3 ms·

> many things I learned designing gearboxes to the D programming language I'm curious about what are some of those things :- ) (embedded software for gearboxe

> many things I learned designing gearboxes to the D programming language I'm curious about what are some of those things :- ) (embedded software for gearboxes? Or physical design things that were translatable to software?)

WalterBright 6y ago
I wrote a couple articles about one aspect: https://www.digitalmars.com/articles/b39.html https://www.digitalmars.com/articles/b39.html https://www.digitalmars.com/articles/b40.html https://www.digitalmars.com/articles/b40.html which I learned from mechanical design at Boeing. Another aspect is making it impossible to assemble parts any way but the correct way. For example, you can write C code like this: for (i = 0; i < 10; ++i); do_something(); A colleague of mine, a very good programmer, was stymied by this for a full day. The next day I added a warning to my C compiler for it. As time went on, this warning became commonplace in other compilers. But in D, I didn't make it a warning. I made in an error. A ; cannot be used to create an empty statement, that can only be done with { }. I still can't believe C/C++ have never made that an error. Another one is: if (a < b < c) ... That doesn't do what one thinks it does. So in D it's an error. D is better because so many unnecessary things in C and C++ are minefields, and instead of warning the user, they're just illegal. (All have ways of doing the equivalent if one really needs to.)
- KajMagnus 5y ago
  > was stymied by this for a full day Oh it took a while until I noticed the extra ';' :- ) It'd likely have slipped past code review o.O > impossible to assemble parts any way but the correct way Hmm make me think about database constraints & foreign keys :- ) > As time went on, this warning became commonplace in other compilers Nice that different languages can help each other become better :- ) > D is better because so many unnecessary things in C and C++ are minefields I remember long ago when coding C++, we had to add a bunch of macros in each C++ class, to remove dangerous-by-default C++ auto generated things (like the copy constructor that copied pointers). I guess you know a lot about such things. D and Rust seems nice :- )
- KajMagnus 5y ago
  > Designing Safe Software Systems Part 2 https://www.digitalmars.com/articles/b40.html https://www.digitalmars.com/articles/b40.html > Dual Path Hmm there's something similar in the SRS book by Google, they call it "failure domains" (I haven't read all of it though). > Monitors: If the output is outside some preset bounds, the system is shut down Maybe in software, becoming read-only can be a similar good idea, when something looks weird > Deadman: A deadman is a hardware timer switch added to a computer system that shuts it down if it isn’t regularly reset. This is something I'm planning to add to the software I'm developing :- ) It's forum / blog-comments software, and, in case the admins have been away for too long (maybe vacation for some weeks), the forum would become read-only, maybe even retroactively hide some risky comments & discussions, until they're back — so there's always humans around that can remove toxic troll comments and such things. > Safe Systems from Unreliable Parts https://www.digitalmars.com/articles/b39.html https://www.digitalmars.com/articles/b39.html > Improving the quality of that component by a factor of 10 will get us there, but at a cost explosion of 10 times the price. But suppose we add in a backup component B, that also has a 10% failure rate. The odds of A and B both simultaneously failing are 10% of 10%, or 1%. This is achieved by a mere doubling of the cost instead of an order of magnitude increase I think it's interesting that this at the same time, doubles the attack surface, for hackers? Although the failure risk gets down to 1%, now the hackers can try to break in into both A and B? Hmm. I wonder if there're any ways to avoid this tradeoff, ... Maybe there aren't, in the same way as it's going to be 2 x expensive, too

WalterBright 6y ago

I wrote a couple articles about one aspect: https://www.digitalmars.com/articles/b39.html https://www.digitalmars.com/articles/b39.html https://www.digitalmars.com/articles/b40.html https://www.digitalmars.com/articles/b40.html which I learned from mechanical design at Boeing. Another aspect is making it impossible to assemble parts any way but the correct way. For example, you can write C code like this: for (i = 0; i < 10; ++i); do_something(); A colleague of mine, a very good programmer, was stymied by this for a full day. The next day I added a warning to my C compiler for it. As time went on, this warning became commonplace in other compilers. But in D, I didn't make it a warning. I made in an error. A ; cannot be used to create an empty statement, that can only be done with { }. I still can't believe C/C++ have never made that an error. Another one is: if (a < b < c) ... That doesn't do what one thinks it does. So in D it's an error. D is better because so many unnecessary things in C and C++ are minefields, and instead of warning the user, they're just illegal. (All have ways of doing the equivalent if one really needs to.)

KajMagnus 5y ago
> was stymied by this for a full day Oh it took a while until I noticed the extra ';' :- ) It'd likely have slipped past code review o.O > impossible to assemble parts any way but the correct way Hmm make me think about database constraints & foreign keys :- ) > As time went on, this warning became commonplace in other compilers Nice that different languages can help each other become better :- ) > D is better because so many unnecessary things in C and C++ are minefields I remember long ago when coding C++, we had to add a bunch of macros in each C++ class, to remove dangerous-by-default C++ auto generated things (like the copy constructor that copied pointers). I guess you know a lot about such things. D and Rust seems nice :- )
KajMagnus 5y ago
> Designing Safe Software Systems Part 2 https://www.digitalmars.com/articles/b40.html https://www.digitalmars.com/articles/b40.html > Dual Path Hmm there's something similar in the SRS book by Google, they call it "failure domains" (I haven't read all of it though). > Monitors: If the output is outside some preset bounds, the system is shut down Maybe in software, becoming read-only can be a similar good idea, when something looks weird > Deadman: A deadman is a hardware timer switch added to a computer system that shuts it down if it isn’t regularly reset. This is something I'm planning to add to the software I'm developing :- ) It's forum / blog-comments software, and, in case the admins have been away for too long (maybe vacation for some weeks), the forum would become read-only, maybe even retroactively hide some risky comments & discussions, until they're back — so there's always humans around that can remove toxic troll comments and such things. > Safe Systems from Unreliable Parts https://www.digitalmars.com/articles/b39.html https://www.digitalmars.com/articles/b39.html > Improving the quality of that component by a factor of 10 will get us there, but at a cost explosion of 10 times the price. But suppose we add in a backup component B, that also has a 10% failure rate. The odds of A and B both simultaneously failing are 10% of 10%, or 1%. This is achieved by a mere doubling of the cost instead of an order of magnitude increase I think it's interesting that this at the same time, doubles the attack surface, for hackers? Although the failure risk gets down to 1%, now the hackers can try to break in into both A and B? Hmm. I wonder if there're any ways to avoid this tradeoff, ... Maybe there aren't, in the same way as it's going to be 2 x expensive, too