15 ms·

It’s only “brilliant” if you think data corrupting bugs that fail to run expected code and silently spread “nil” throughout your application’s data model are br

It’s only “brilliant” if you think data corrupting bugs that fail to run expected code and silently spread “nil” throughout your application’s data model are brilliant. If something can be nil, handle the case. There’s nothing brilliant about objective-C’s nil kludge.

nicky0 4y ago
Like any language feature, you have to know what you are doing.
- teakettle42 4y ago
  It’s a foot-gun, and a significant source of bugs in just about all software of any complexity written in ObjC.
  - nicky0 4y ago
    Writing code is a significant source of bugs in just about all software of any complexity.
    - teakettle42 4y ago
      Good news, then; languages with an Optional<T> type don’t require you to write more potentially buggy code to check for (or forget to check for) nil.
      - nicky0 4y ago
        Meh, different languages give you different tools, different degrees of nannying vs freedom. Some may give you a foot gun, but at least you have a gun and you aren’t required to point it at your foot.
        teakettle42 4y ago
        I prefer languages that make it easy for me to focus on solving novel problems, rather than wasting my mental energy just trying to not blow my foot off with a rusty musket.
    - pilif 4y ago
      Bugs exist. No question. What does bother me is where you detect the bug. Is it at compile-time? Is it at run-time through a crash? or is it months later after you notice that many of your users seem to have January 1st 1970 as their birthday with no way of recovering the lost data. But hey - at least stuff kept running. Right?
      - nicky0 4y ago
        If you write bad code then your code will be bad.
        pdpi 4y ago
        That’s a pretty unhelpful attitude. This year has already seen CVE-2022-25636 (heap out-of-bounds write), CVE-2022-27666 (buffer overflow), and CVE-2922-0847 (uninitialised memory). Three vulnerabilities in the Linux kernel, in pretty important (and therefore, presumably, closely scrutinised) bits of the code base. And this is the Linux kernel, arguably the most important open source project in the world, worked on by some of the most skilled developers out there. Everybody writes bad code, and everybody misses bad code on review, even in the really important bits, even when they’re well-known bug classes. Criticising a language for leaving these foot guns lying about is perfectly reasonable, and it’s important we talk about avoiding those languages wherever possible.
    - yakshaving_jgt 4y ago
      This might help you. http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html
- threatripper 4y ago
  Programming languages are like shepherds. They offer a compromise between the freedom to do stuff efficiently and the danger of unwanted behavior. You cannot maximize both at the same time. You can, however, minimize both by making bad design decisions. Footguns are more and more considered a fault in the language design and less the responsibility of the programmer.
  - smitty1e 4y ago
    Sometimes the serious training wheels on the system make sense, especially when navigating the learning curve. Other times, the need to have direct hardware access from the BIOS on up cannot be avoided. The bugaboo is the quest for the One True System that is all things to all people. Emacs is as close as we get to that Nirvana.
- ebingdom 4y ago
  This is terrible reasoning. You're basically saying that language features have no impact on bugs, putting all the blame on the programmers. But programmers are humans, and as such they make mistakes (even the best of us). We should embrace tools which are designed to help us catch mistakes. The correct reasoning would be to recognize that certain language features make entire classes of bugs impossible. For example, in my Rust projects, I never have to worry about null pointer errors. Sure, there might be other types of bugs in my code. But at least I don't have bugs due to nulls. Also, there are no data races in my code—yet another thing I don't have to worry about thanks to the design of the language. (I'm not saying Rust is perfect. I'm just using it as an example.)
afc 4y ago
Well said. This feels terrible: just silently ignore logical errors (where some code expects but doesn't receive a fully constructed object) and ... keep going. I'd rather take a crash (that way I'll know soon that I have a bug and it'll be easy to fix) or, even better, a compiler/type error ("code is expecting a fully constructed object but doesn't always receive one"). In C++ I recently started using a NonNull<> templated type (with specializations for std::unique_ptr<> and std::shared_ptr<>): https://github.com/alefore/edge/blob/af1192a70646f662539bfe6b2be154508ef0dc8e/src/language/safe_types.h#L66 https://github.com/alefore/edge/blob/af1192a70646f662539bfe6... It's slightly verbose, but has allowed me to delete a ton of CHECK(x != nullptr) statements (since the type will already carry the information that x can't be null) and this use of types has helped me detect a few mismatches (where e.g. the consumer had unnecessary complexity to deal with null but the caller always emitted fully constructed types, or the, much worse, symmetric case).
larsrc 4y ago
I notice that all the comments that agree with this one point out specific dangers, while those disagreeing basically say "Eh, bugs happen". Yes, you need to know what you're doing in any language, the difference is whether those things are due to the language or the problem you're actually trying to solve. The more things in the language you have to keep in mind, the less of your domain problems you have room for.

nicky0 4y ago

Like any language feature, you have to know what you are doing.

teakettle42 4y ago
It’s a foot-gun, and a significant source of bugs in just about all software of any complexity written in ObjC.
- nicky0 4y ago
  Writing code is a significant source of bugs in just about all software of any complexity.
  - teakettle42 4y ago
    Good news, then; languages with an Optional<T> type don’t require you to write more potentially buggy code to check for (or forget to check for) nil.
    - nicky0 4y ago
      Meh, different languages give you different tools, different degrees of nannying vs freedom. Some may give you a foot gun, but at least you have a gun and you aren’t required to point it at your foot.
      - teakettle42 4y ago
        I prefer languages that make it easy for me to focus on solving novel problems, rather than wasting my mental energy just trying to not blow my foot off with a rusty musket.
  - pilif 4y ago
    Bugs exist. No question. What does bother me is where you detect the bug. Is it at compile-time? Is it at run-time through a crash? or is it months later after you notice that many of your users seem to have January 1st 1970 as their birthday with no way of recovering the lost data. But hey - at least stuff kept running. Right?
    - nicky0 4y ago
      If you write bad code then your code will be bad.
      - pdpi 4y ago
        That’s a pretty unhelpful attitude. This year has already seen CVE-2022-25636 (heap out-of-bounds write), CVE-2022-27666 (buffer overflow), and CVE-2922-0847 (uninitialised memory). Three vulnerabilities in the Linux kernel, in pretty important (and therefore, presumably, closely scrutinised) bits of the code base. And this is the Linux kernel, arguably the most important open source project in the world, worked on by some of the most skilled developers out there. Everybody writes bad code, and everybody misses bad code on review, even in the really important bits, even when they’re well-known bug classes. Criticising a language for leaving these foot guns lying about is perfectly reasonable, and it’s important we talk about avoiding those languages wherever possible.
  - yakshaving_jgt 4y ago
    This might help you. http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html
threatripper 4y ago
Programming languages are like shepherds. They offer a compromise between the freedom to do stuff efficiently and the danger of unwanted behavior. You cannot maximize both at the same time. You can, however, minimize both by making bad design decisions. Footguns are more and more considered a fault in the language design and less the responsibility of the programmer.
- smitty1e 4y ago
  Sometimes the serious training wheels on the system make sense, especially when navigating the learning curve. Other times, the need to have direct hardware access from the BIOS on up cannot be avoided. The bugaboo is the quest for the One True System that is all things to all people. Emacs is as close as we get to that Nirvana.
ebingdom 4y ago
This is terrible reasoning. You're basically saying that language features have no impact on bugs, putting all the blame on the programmers. But programmers are humans, and as such they make mistakes (even the best of us). We should embrace tools which are designed to help us catch mistakes. The correct reasoning would be to recognize that certain language features make entire classes of bugs impossible. For example, in my Rust projects, I never have to worry about null pointer errors. Sure, there might be other types of bugs in my code. But at least I don't have bugs due to nulls. Also, there are no data races in my code—yet another thing I don't have to worry about thanks to the design of the language. (I'm not saying Rust is perfect. I'm just using it as an example.)

afc 4y ago

Well said. This feels terrible: just silently ignore logical errors (where some code expects but doesn't receive a fully constructed object) and ... keep going. I'd rather take a crash (that way I'll know soon that I have a bug and it'll be easy to fix) or, even better, a compiler/type error ("code is expecting a fully constructed object but doesn't always receive one"). In C++ I recently started using a NonNull<> templated type (with specializations for std::unique_ptr<> and std::shared_ptr<>): https://github.com/alefore/edge/blob/af1192a70646f662539bfe6b2be154508ef0dc8e/src/language/safe_types.h#L66 https://github.com/alefore/edge/blob/af1192a70646f662539bfe6... It's slightly verbose, but has allowed me to delete a ton of CHECK(x != nullptr) statements (since the type will already carry the information that x can't be null) and this use of types has helped me detect a few mismatches (where e.g. the consumer had unnecessary complexity to deal with null but the caller always emitted fully constructed types, or the, much worse, symmetric case).

larsrc 4y ago

I notice that all the comments that agree with this one point out specific dangers, while those disagreeing basically say "Eh, bugs happen". Yes, you need to know what you're doing in any language, the difference is whether those things are due to the language or the problem you're actually trying to solve. The more things in the language you have to keep in mind, the less of your domain problems you have room for.