6 ms·

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/un

by 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.
  - deltaonefour 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 programmed both for my career. At one point I was literally full stack as in device and sensor integration code all the way through application code and databases to react and typescript on the browser. An undefined can be traced backwards following previous logic. You can also set breakpoints earlier and earlier and eventually find the problem. It's tedious but straightforward. Additionally the error is reproducible. In C++ If you write to memory out of bounds anything can happen and the behavior is actually random. Changing things in unrelated places can actually affect the outcome and give you false positives. It might hit an unallocated page, in which case you get a segfault. Or it might hit unused data on a page that is allocated to your process in which case it won't have any practical effect (unless it is properly initialized afterwards, overwriting your first, illegal, write, and you then try to read from it, expecting the original (invalid) value to still be there. Or it might hit data that's actually in use, in which case you'll get errors later, when the program tries to read that data. Pretty much the same scenarios exist when reading data. You can be lucky and get a segfault immediately, or you can hit unused and uninitialized memory, and read garbage data out (which will most likely cause an error later, when that data is used), or you can read from memory addresses that are already in use (which will also give you garbage out). There is no direct backwards path from a segfault to the source of the error. All you know is that a segfault happened here, and the cause of the segfault must've happened somewhere before it. Sure you can also code safely in a way that avoids these foot gun errors. But you can do the same in any language. People have been doing this with the "Good parts" of javascript prior to ES6 and typescript for years, but that's not the point. There are also tools like valgrind and asan, but these tools are ALSO not the point. What we're talking about is the difference in safety intrinsic to the language not intrinsic to your style of coding. C++ is definitively worse. OpenGL is also a lower level C library and tracing errors is also hard for the same reason why C++ has segfaults. Basically there's no intrinsic checks anywhere so although things are faster, things are much more error prone as a result. If you really want to have fun try vulkan.
    - _gabe_ 5y ago
- MrJohz 5y ago
  It's worth noting that Python also has NaN, and it behaves the same way as in JavaScript when being added to other numbers. This has little to do with the safety of the language, and more to do with the IEEE 754 spec on floating point numbers. For example, `math.nan + 1` in Python should equal NaN as well. While NaN technically is a kind of null, it's one embedded in the spec for floating point numbers, and therefore present in every language that uses them, including far safer languages like Rust. It's also worth noting that neither language has the behaviour described in this article, which is that doing anything to a null (not NaN) value returns a new null value. In Python, there are a handful of allowed operations on `None` (such as converting it to a string), and everything else will return an error. Javascript is somewhat more lenient, in that it allows type coercion, so in a numeric context, `null` will first be converted to 0, and `undefined` will first be converted to NaN. Likewise, in the presence of other strings, these values will be coerced to string values. However, if you attempt to access attributes on these objects, call methods on them, or pass them to methods that don't accept null values, then they will throw errors. This is the big difference to a language like Objective C.
  - deltaonefour 5y ago
    Yes I'm fully aware of the technical details behind most of this stuff. However the high level consequences of it is exactly as I said. IEEE floating point values aren't really used that much in python as much as they are in JS because python chooses to crash the entire program rather then return a NaN. Probably the only thing I use out of that spec is infinite. In the end for JS, The user ends up seeing 3 values equivalent to null in javascript and these values propogate through the program stealthily. Lenient isn't the right word... error prone is more inline with the consequence of javascript type coercion. Additionally yes, I am aware of how every function in Obj C is the maybe monad as the article mentions. I'm just addressing the comment. Thank you but there's no need to reiterate the article to me.
    - MrJohz 5y ago
      Python definitely returns NaNs when required to by the spec (which is to say: whenever maths is happening with NaNs). I think you're getting confused between propagation and coercion. NaNs are always propagated in both languages when doing operations on numeric values. This is the IEEE specified behaviour. `null`, `None`, and `undefined` are never propagated implicitly in either language (although Javascript now has a null chaining operator that can propagated nulls explicitly). In Javascript, the `null` and `undefined` values can be coerced to different values if you apply certain operators to them. This is different to null propagation (although it's still not a good design choice for a language). For example, when added to a number, `undefined` will be coerced to NaN, and `null` will be coerced to 0. (The NaN value will then it course be propagated if you do further operations with it, but, like I say, this is true in both Python and Javascript.) In Python, there is no implicit type coercion (except arguably between different numeric types e.g. int to float and vice versa), so this does not happen. NaN is not really equivalent to null in either Javascript or Python, except explicitly in floating point operations. Rather, in both cases, the rest of the language treats NaN as a regular floating point value (which it is).

by olliej 5y ago

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.
- deltaonefour 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 programmed both for my career. At one point I was literally full stack as in device and sensor integration code all the way through application code and databases to react and typescript on the browser. An undefined can be traced backwards following previous logic. You can also set breakpoints earlier and earlier and eventually find the problem. It's tedious but straightforward. Additionally the error is reproducible. In C++ If you write to memory out of bounds anything can happen and the behavior is actually random. Changing things in unrelated places can actually affect the outcome and give you false positives. It might hit an unallocated page, in which case you get a segfault. Or it might hit unused data on a page that is allocated to your process in which case it won't have any practical effect (unless it is properly initialized afterwards, overwriting your first, illegal, write, and you then try to read from it, expecting the original (invalid) value to still be there. Or it might hit data that's actually in use, in which case you'll get errors later, when the program tries to read that data. Pretty much the same scenarios exist when reading data. You can be lucky and get a segfault immediately, or you can hit unused and uninitialized memory, and read garbage data out (which will most likely cause an error later, when that data is used), or you can read from memory addresses that are already in use (which will also give you garbage out). There is no direct backwards path from a segfault to the source of the error. All you know is that a segfault happened here, and the cause of the segfault must've happened somewhere before it. Sure you can also code safely in a way that avoids these foot gun errors. But you can do the same in any language. People have been doing this with the "Good parts" of javascript prior to ES6 and typescript for years, but that's not the point. There are also tools like valgrind and asan, but these tools are ALSO not the point. What we're talking about is the difference in safety intrinsic to the language not intrinsic to your style of coding. C++ is definitively worse. OpenGL is also a lower level C library and tracing errors is also hard for the same reason why C++ has segfaults. Basically there's no intrinsic checks anywhere so although things are faster, things are much more error prone as a result. If you really want to have fun try vulkan.
  - _gabe_ 5y ago
MrJohz 5y ago
It's worth noting that Python also has NaN, and it behaves the same way as in JavaScript when being added to other numbers. This has little to do with the safety of the language, and more to do with the IEEE 754 spec on floating point numbers. For example, `math.nan + 1` in Python should equal NaN as well. While NaN technically is a kind of null, it's one embedded in the spec for floating point numbers, and therefore present in every language that uses them, including far safer languages like Rust. It's also worth noting that neither language has the behaviour described in this article, which is that doing anything to a null (not NaN) value returns a new null value. In Python, there are a handful of allowed operations on `None` (such as converting it to a string), and everything else will return an error. Javascript is somewhat more lenient, in that it allows type coercion, so in a numeric context, `null` will first be converted to 0, and `undefined` will first be converted to NaN. Likewise, in the presence of other strings, these values will be coerced to string values. However, if you attempt to access attributes on these objects, call methods on them, or pass them to methods that don't accept null values, then they will throw errors. This is the big difference to a language like Objective C.
- deltaonefour 5y ago
  Yes I'm fully aware of the technical details behind most of this stuff. However the high level consequences of it is exactly as I said. IEEE floating point values aren't really used that much in python as much as they are in JS because python chooses to crash the entire program rather then return a NaN. Probably the only thing I use out of that spec is infinite. In the end for JS, The user ends up seeing 3 values equivalent to null in javascript and these values propogate through the program stealthily. Lenient isn't the right word... error prone is more inline with the consequence of javascript type coercion. Additionally yes, I am aware of how every function in Obj C is the maybe monad as the article mentions. I'm just addressing the comment. Thank you but there's no need to reiterate the article to me.
  - MrJohz 5y ago
    Python definitely returns NaNs when required to by the spec (which is to say: whenever maths is happening with NaNs). I think you're getting confused between propagation and coercion. NaNs are always propagated in both languages when doing operations on numeric values. This is the IEEE specified behaviour. `null`, `None`, and `undefined` are never propagated implicitly in either language (although Javascript now has a null chaining operator that can propagated nulls explicitly). In Javascript, the `null` and `undefined` values can be coerced to different values if you apply certain operators to them. This is different to null propagation (although it's still not a good design choice for a language). For example, when added to a number, `undefined` will be coerced to NaN, and `null` will be coerced to 0. (The NaN value will then it course be propagated if you do further operations with it, but, like I say, this is true in both Python and Javascript.) In Python, there is no implicit type coercion (except arguably between different numeric types e.g. int to float and vice versa), so this does not happen. NaN is not really equivalent to null in either Javascript or Python, except explicitly in floating point operations. Rather, in both cases, the rest of the language treats NaN as a regular floating point value (which it is).