1. 29
  1.  

  2. 6

    This is an interesting idea, especially for unit calculations as in the examples they provide, but I’m sure I’m not the only one who would frown upon it if it was used heavily in library code that I wanted to use, which is sad. C programmers tend to hold on to the flexibility that the language provides, even at the expense of safety, which is completely the wrong idea of course.

    This, and other reasons are why Go intrigues me. I’ve built decently large systems in Go in very short timespans which had next to no bugs due to improper integer usage. Go makes it easy to give new meaning to types that the compiler honors, like in the post, without the sad face everytime you use it.

    1. 4

      Thankfully, it’s not that unusual to have a module export an opaque type handle for a resource in C, particularly in embedded code. You’re absolutely right that it adds more verbosity, though - after I learned OCaml, I saw a bunch of ways to apply its type system tricks in C, but C also made them sufficiently verbose that I probably would’ve never learned how to use them effectively in C alone. Type inference and pattern matching go a long way.

      Using techniques like his struct type-boxing to add type safety adds extra work, and people often find it too much trouble unless the threat of planes crashing or something justifies the time.

      1. 4

        ok, so we can start the change by trying not to frown when we see new things in c code! we can take the vow of progressive c and share the secret handshake.

        i feel the culture of c should change, slowly, to reflect new ideas. it can only do that if we make the mental effort to accept things like this.

        (another language that is, perhaps surprisingly, like a “nice c” is julia. even though it comes from a completely different direction - mathematical programming - its emphasis on performance means that it’s not far from “c plus gc” (actually, you need to add dispatch by types too…). in particular, its types are “obviously” “just c structs”)

        1. 3

          I agree that the C mentality needs to change a bit, and I wish to believe that future versions of the C standard will adopt some of these ideas. However, it seems to be the case that the way the C standard evolves is by asking the compiler writers what non-standard things are you already doing that we can all agree on? That’s my impression of the changes in C11. This methodology is unlikely to ever produce a feature in the standard to address this.

          Because this will likely never be standardized officially, I think the only way to get people to not frown upon this is to ensure that any of the libraries that people need to use, use these ideas. Only then would you get enough eyeballs on this idea to start a snowball effect that standardizes the practice in the community.