431
average c++ dev (programming.dev)
submitted 1 year ago by to c/programmer_humor@programming.dev
110 comments fedilink hide all child comments
 

I don't think that casting a range of bits as some other arbitrary type "is a bug nobody sees coming".

C++ compilers also warn you that this is likely an issue and will fail to compile if configured to do so. But it will let you do it if you really want to.

That's why I love C++

a screenshot from linkedin reading "I don't think that casting a range of bits as some other arbitrary type "is a bug nobody sees coming". C++ compilers also warn you that this is likely an issue and will fail to compile if configured to do so. But it will *let you do it* if you really want to. That's why I love C++"
you are viewing a single comment's thread
view the rest of the comments
[–] 7 points 1 year ago* (last edited 1 year ago) (4 children)

100%. In my opinion, the whole "build your program around your model of the world" mantra has caused more harm than good. Lots of "best practices" seem to be accepted without any quantitative measurement to prove it's actually better. I want to think it's just the growing pains of a young field.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 5 points 1 year ago (3 children)

    Even with qualitative measurements they can do stupid things.

    For work I have to write code in C# and Microsoft found that null reference exceptions were a common issue. They actually calculated how much these issues cost the industry (some big number) and put a lot of effort into changing the language so there's a lot of warnings when something is null.

    But the end result is people just set things to an empty value instead of leaving it as null to avoid the warnings. And sure great, you don't have null reference exceptions because a value that defaulted to null didn't get set. But now you have issues where a value is an empty string when it should have been set.

    The exception message would tell you exactly where in the code there's a mistake, and you'll immediately know there's a problem and it's more likely to be discovered by unit tests or QA. Something that's an value that's supposed to be set may not be noticed for a while and is difficult to track down.

    So their research indicated a costly issue (which is ultimately a dev making a mistake) and they fixed it by creating an even more costly issue.

    There's always going to be things where it's the responsibility of the developer to deal with, and there's no fix for it at the language level. Trying to fix it with language changes can just make things worse.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 5 points 1 year ago (2 children)

    For this example, I feel that it is actually fairly ergonomic in languages that have an Option type (like Rust), which can either be Some value or no value (None), and don't normally have null as a concept. It normalizes explicitly dealing with the None instead of having null or hidden empty strings and such.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 1 year ago (1 child)

    I just prefer an exception be thrown if I forget to set something so it's likely to happen as soon as I test it and will be easy to find where I missed something.

    I don't think a language is going to prevent someone from making a human error when writing code, but it should make it easy to diagnose and fix it when it happens. If you call it null, "", empty, None, undefined or anything else, it doesn't change the fact that sometimes the person writing the code just forgot something.

    Abstracting away from the problem just makes it more fuzzy on where I just forgot a line of code somewhere. Throwing an exception means I know immediately that I missed something, and also the part of the code where I made the mistake. Trying to eliminate the exception doesn't actually solve the problem, it just hides the problem and makes it more difficult to track down when someone eventually notices something wasn't populated.

    Sometimes you want the program to fail, and fail fast (while testing) and in a very obvious way. Trying to make the language more "reliable" instead of having the reliability of the software be the responsibility of the developer can mean the software always "works", but it doesn't actually do what it's supposed to do.

    Is the software really working if it never throws an exception but doesn't actually do what it's supposed to do?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 1 year ago

    It is fair to have a preference for exceptions. It sounds like there may be a misunderstanding on how Option works.

    Have you used languages that didn't have null and had Option instead? If we look at Rust, you can't forget not to check it: it is impossible to get the Some of an Option without dealing with the None. You can't forget this. You can mess up in a lot of other ways, but you explicitly have to decide how to handle that potential None case.

    If you want it to fail fast and obvious, there are ways to do this. For example you, you can use the unwrap() method to get the contained Some value or panic if it is None, expect() to do the same but with a custom panic message, the ? operator to get the contained Some value or return the function with None, etc. Tangentially, these also work for Result, which can be Ok or Err.

    It is pretty common to use these methods in places where you always want to fail somewhere that you don't expect should have a None or where you don't want your code to deal with the consequences of something unexpected. You have decided this and live with the consequences, instead of it implicitly happening/you forgetting to deal with it.

  • permalink
  • fedilink
  • source
  • parent