6 ms·

As someone who started writing Objective-C on macOS in 2003, the whole nil messaging syntax is pure hell compared to any modern language that disavows nulls ent

As someone who started writing Objective-C on macOS in 2003, the whole nil messaging syntax is pure hell compared to any modern language that disavows nulls entirely (like Rust, and to a large extent Swift). You can literally never trust anything - ever - is not nil because `nonnull` is just a hint, and messaging nil will never crash. It'll just return 0 (or {0} or 0.0 depending on context), which is sometimes valid - and sometimes a horrible failure mode. Failing silently like that is the worst option. As such you end up having a ton of boilerplate all over the place checking the validity of input parameters to methods and initializers for conditions which shouldn't be representable in the first place - even when the method signature warrants that it's not representable, because it still won't crash on ya. Let's say you have a chain of property accessors, a.b.c.d, the where d is a float. They're all supposed to be nonnull. You get 0.0. Is that valid? Shrugasaurus rex. Time for the ol' NSParameterAssert(a.b.c != nil). [edit] Also, canonically, there's 5+1 'null' values: nil, Nil, NULL, -[NSNull null] and 0 - plus nullptr in Objective-C++.

MaxBarraclough 5y ago
> Failing silently like that is the worst option. > As such you end up having a ton of boilerplate all over the place checking the validity of input parameters to methods and initializers for conditions which shouldn't be representable in the first place Dynamically typed languages (at least, JavaScript and Python) have been gradually learning this lesson.
- deltaonefour 5y ago
  Actually python fails hard and fast. This is very different from javascript. It actually makes python safer then C++ even though python is dynamically typed. It is far easier to debug a error caused by out of bounds memory writing/reading in python then it is in a strictly typed language like C++. This is because C++ doesn't actually fail hard and fast when you do this. If you ever programmed extensively in both languages you will actually see that python is by far less error prone then C++ despite being untyped. Javascript is actually the same, though a little worse then python because how an undefined can get propagated deep into a program. Still even though an undefined is hard to debug in javascript, it's still traceable through a step by step methodology. A C++ seg fault is not always so straight forward. I would argue that it doesn't depend on whether the language is dynamically typed, but more on the traceability of crashes.
  - olliej 5y ago
    What? No it doesn’t? Python doesn’t stop until you attempt to use Nil, no different from JS or any other lazy bound language. You might be conflating null/undefined handling with type coercion, which is very different, and much worse.
    - deltaonefour 5y ago
      That wasn't what the OP was talking about. He was talking about failure. Python doesn't stop you from using a None, it just fails hard and fast. Javascript on the other hand doesn't fail. It has 3 things equivalent to nil or Null. Called undefined and NaN and NULL. It lets you do some nutty things with undefined. undefined + 1 = NaN. NaN + 1 = NaN. NULL + 1 = 1. In python None + 1 is an instant hard crash. Still these types of errors are traceable by following the code path and even easier with a debugger. For C++ a seg fault could trigger an error anywhere and there's no direct path to the source of the error. For nullptr it triggers a runtime error but this is the same problem as javascript... not a huge deal. In terms of safety the order is: Python, Javascript, C++. C++ alone with the segfaults is what causes it to be on the bottom of the list despite the extensive type system. One seg fault alone is worse then a python program with 20 type errors due to the fact about how hard it is to trace seg faults. There are C++ production code bases where known segfaults exist but no one has ever been able to find the offending line.
      - _gabe_ 5y ago
        I program in C++ as a hobby and typescript for my day job. I would say if anything it's just as hard trying to figure out why a JS object is undefined as it is finding out why you get a segfault in C++. I will add it's really easy to have a custom memory allocator that allocates extra bytes at the beginning and end of every allocation to detect heap corruption in C++. It's also super easy to add memory leak detectors. I've written both of those utilities in a couple hundred lines of C++ I honestly can't remember the last time I had a segfault that wasn't immediately obvious. Nowadays my biggest problems are debugging OpenGL global state errors.
- ramesh31 5y ago
  >Dynamically typed languages (at least, JavaScript and Python) have been gradually learning this lesson. Modern JS avoids this issue entirely with destructuring, optional chaining, and default params. You can actually write completely safe Javascript now without using any awkward safety checks.

MaxBarraclough 5y ago

> Failing silently like that is the worst option. > As such you end up having a ton of boilerplate all over the place checking the validity of input parameters to methods and initializers for conditions which shouldn't be representable in the first place Dynamically typed languages (at least, JavaScript and Python) have been gradually learning this lesson.

deltaonefour 5y ago
Actually python fails hard and fast. This is very different from javascript. It actually makes python safer then C++ even though python is dynamically typed. It is far easier to debug a error caused by out of bounds memory writing/reading in python then it is in a strictly typed language like C++. This is because C++ doesn't actually fail hard and fast when you do this. If you ever programmed extensively in both languages you will actually see that python is by far less error prone then C++ despite being untyped. Javascript is actually the same, though a little worse then python because how an undefined can get propagated deep into a program. Still even though an undefined is hard to debug in javascript, it's still traceable through a step by step methodology. A C++ seg fault is not always so straight forward. I would argue that it doesn't depend on whether the language is dynamically typed, but more on the traceability of crashes.
- olliej 5y ago
  What? No it doesn’t? Python doesn’t stop until you attempt to use Nil, no different from JS or any other lazy bound language. You might be conflating null/undefined handling with type coercion, which is very different, and much worse.
  - deltaonefour 5y ago
    That wasn't what the OP was talking about. He was talking about failure. Python doesn't stop you from using a None, it just fails hard and fast. Javascript on the other hand doesn't fail. It has 3 things equivalent to nil or Null. Called undefined and NaN and NULL. It lets you do some nutty things with undefined. undefined + 1 = NaN. NaN + 1 = NaN. NULL + 1 = 1. In python None + 1 is an instant hard crash. Still these types of errors are traceable by following the code path and even easier with a debugger. For C++ a seg fault could trigger an error anywhere and there's no direct path to the source of the error. For nullptr it triggers a runtime error but this is the same problem as javascript... not a huge deal. In terms of safety the order is: Python, Javascript, C++. C++ alone with the segfaults is what causes it to be on the bottom of the list despite the extensive type system. One seg fault alone is worse then a python program with 20 type errors due to the fact about how hard it is to trace seg faults. There are C++ production code bases where known segfaults exist but no one has ever been able to find the offending line.
    - _gabe_ 5y ago
      I program in C++ as a hobby and typescript for my day job. I would say if anything it's just as hard trying to figure out why a JS object is undefined as it is finding out why you get a segfault in C++. I will add it's really easy to have a custom memory allocator that allocates extra bytes at the beginning and end of every allocation to detect heap corruption in C++. It's also super easy to add memory leak detectors. I've written both of those utilities in a couple hundred lines of C++ I honestly can't remember the last time I had a segfault that wasn't immediately obvious. Nowadays my biggest problems are debugging OpenGL global state errors.
ramesh31 5y ago
>Dynamically typed languages (at least, JavaScript and Python) have been gradually learning this lesson. Modern JS avoids this issue entirely with destructuring, optional chaining, and default params. You can actually write completely safe Javascript now without using any awkward safety checks.