4 ms·

Author here. I considered the enum "solution" but found the match on usize tuples to be clearer because it requires less code. Introducing an enum doesn't help

Author here. I considered the enum "solution" but found the match on usize tuples to be clearer because it requires less code. Introducing an enum doesn't help because it neither: + helps better model the domain: P0 and P1 are already device ports, wrapping doesn't clarify anything, + nor does it buy you safety; arguably I'd say it makes it less safe, since the real risk with this sort of code is that you fat finger when copy/pasting between the electrical schematic and the firmware, so by adding extra wrapping you further obscure the pin assignments.

sammorrowdrums 6y ago
Ah, sorry I added further comment to above before seeing this. I can see why you would say that, but does the arbitrary integer risk of the 0, 1, _ match not create even greater risk? Compiler cannot help at all. _ => {}
- lynaghk 6y ago
  First, we should be clear that this is my goofy hobby keyboard project --- if I was concerned about safety, I'd have written it in MISRA C or something =D There are many things about this project that a compiler can't help me with. I had to read about all of the pinouts from a PDF, draw them on a circuit board, and then map those pins in the firmware. The code only deals with that last part, and in this particular example I decided that it was safer on the whole for the code to be obvious (easy to read + compare with hardware schematic) than to go through contortions with types to make some things more checkable by computer but less-checkable by human inspection. The main risk here is not passing the wrong value to this match, it's fat fingering the transcription from the schematic.
  - sammorrowdrums 6y ago
    Makes sense, and I guess given the above your conclusion not to use Rust seems like the correct call for your situation. Thanks for explaining further. It's true you say much of this in the article.
    - josephg 6y ago
      Yeah I think people like to match the values of a programming language to ourselves as people. (And by values I mean, correctness, speed, expressiveness, velocity, etc). Like, I’ll pick the values which I like the most and find languages which match the values I aspire towards. Eg maybe I like the idea of my programs being strongly typechecked without sacrificing speed - so I program in rust. Then I write clean rust code even when I’m doing a quick and dirty prototype. The better & harder approach matches a language’s virtues to the problem at hand. Strict correctness doesn’t matter much for a hobby program like this - moving fast and having fun are probably more important here. Expressing that with your tools might mean using Zig, or using rust but being sloppy with allocations and .clone() because it’s fine. Or treating rust like C and using unsafe everywhere. “Making invalid states inexpressible” isn’t that important in a fun side project - unless maybe that’s fun for you! The right question isn’t “What is my favourite tool?”. It’s “If this project had a soul, how would it want to express itself through code?”
      - ywei3410 6y ago
        I like that last sentence; is it something you came up with yourself or is it a quote?
        josephg 6y ago
        Thanks - that’s all me.
      - autarch 6y ago
        > The right question isn’t “What is my favourite tool?”. It’s “If this project had a soul, how would it want to express itself through code?” I somewhat disagree. What you're saying is basically "pick the right tool for the job", but more poetically (not a criticism, BTW, I like your phrasing). But what I think this is missing is that the "right" tool is at least in part based on your favorite tools are. Or to put it differently, using a tool that may be suboptimal for the job, but which you know extremely well, may be better than using a tool you don't know which is optimal for the job. Of course, this is much less of an issue for hobby projects, and if one of your goals for a project is "learn new stuff" (a goal I often have for my own hobby projects), then picking the optimal language may be exactly the right choice. You get to learn a new thing while not fighting with the language.
- sammorrowdrums 6y ago
  Oh and also, if the whole separate types for each mapping thing is so annoying and wrapping the tuples is unhelpful, which is understandable, then perhaps safer to wrap just the pins in emums and then always access them via the enum? Then it would be (enum type, usize) Then also at times where all Pins need handling, the.exhaustive matching can reduce risks of not doing so?

sammorrowdrums 6y ago

Ah, sorry I added further comment to above before seeing this. I can see why you would say that, but does the arbitrary integer risk of the 0, 1, _ match not create even greater risk? Compiler cannot help at all. _ => {}

lynaghk 6y ago
First, we should be clear that this is my goofy hobby keyboard project --- if I was concerned about safety, I'd have written it in MISRA C or something =D There are many things about this project that a compiler can't help me with. I had to read about all of the pinouts from a PDF, draw them on a circuit board, and then map those pins in the firmware. The code only deals with that last part, and in this particular example I decided that it was safer on the whole for the code to be obvious (easy to read + compare with hardware schematic) than to go through contortions with types to make some things more checkable by computer but less-checkable by human inspection. The main risk here is not passing the wrong value to this match, it's fat fingering the transcription from the schematic.
- sammorrowdrums 6y ago
  Makes sense, and I guess given the above your conclusion not to use Rust seems like the correct call for your situation. Thanks for explaining further. It's true you say much of this in the article.
  - josephg 6y ago
    Yeah I think people like to match the values of a programming language to ourselves as people. (And by values I mean, correctness, speed, expressiveness, velocity, etc). Like, I’ll pick the values which I like the most and find languages which match the values I aspire towards. Eg maybe I like the idea of my programs being strongly typechecked without sacrificing speed - so I program in rust. Then I write clean rust code even when I’m doing a quick and dirty prototype. The better & harder approach matches a language’s virtues to the problem at hand. Strict correctness doesn’t matter much for a hobby program like this - moving fast and having fun are probably more important here. Expressing that with your tools might mean using Zig, or using rust but being sloppy with allocations and .clone() because it’s fine. Or treating rust like C and using unsafe everywhere. “Making invalid states inexpressible” isn’t that important in a fun side project - unless maybe that’s fun for you! The right question isn’t “What is my favourite tool?”. It’s “If this project had a soul, how would it want to express itself through code?”
    - ywei3410 6y ago
      I like that last sentence; is it something you came up with yourself or is it a quote?
      - josephg 6y ago
        Thanks - that’s all me.
    - autarch 6y ago
      > The right question isn’t “What is my favourite tool?”. It’s “If this project had a soul, how would it want to express itself through code?” I somewhat disagree. What you're saying is basically "pick the right tool for the job", but more poetically (not a criticism, BTW, I like your phrasing). But what I think this is missing is that the "right" tool is at least in part based on your favorite tools are. Or to put it differently, using a tool that may be suboptimal for the job, but which you know extremely well, may be better than using a tool you don't know which is optimal for the job. Of course, this is much less of an issue for hobby projects, and if one of your goals for a project is "learn new stuff" (a goal I often have for my own hobby projects), then picking the optimal language may be exactly the right choice. You get to learn a new thing while not fighting with the language.
sammorrowdrums 6y ago
Oh and also, if the whole separate types for each mapping thing is so annoying and wrapping the tuples is unhelpful, which is understandable, then perhaps safer to wrap just the pins in emums and then always access them via the enum? Then it would be (enum type, usize) Then also at times where all Pins need handling, the.exhaustive matching can reduce risks of not doing so?