5 ms·

I love(?) that he absolutely predicted a global disaster between 2020-2025, he just got the wrong type. Which is very JavaScript.

noman-land 4mo ago
He was pretty close to being NaN% correct.
- moritzwarhier 4mo ago
  To be fair there were a couple of disasters, such as [object Array] and undefined. Feels like the world is hanging on a single thread by now.
  - jschrf 4mo ago
    Protip: never even mention undefined in your codebase. Erase it from your vernacular. If you ever need to pass or return nothing, you use null.
    - moritzwarhier 4mo ago
      I do it this way, but this led to people asking me in reviews why I use NULL^^ My explanation was that it signals intent to me, and is different from some property not being part of the expected object shape or not having been initialized because of some accident or logic failure. Since then, I've sticked to it, and am "allowed" to use NULL ^^ It can lead to some annoying checks in TS for primitively-typed properties, so for these, I still allow explicit usage of undefined when it's simpler given the surrounding code. But I agree with you in principle. Using "undefined" as a "second nullish value" and explicitly checking for it is a programming error. When there's object/areay vs null/undefined, thankfully, the truthiness narrowing often allows me to interface with code relying on "undefined" without explicitly handling this "value" in my own parts of the code base :)
    - crdrost 4mo ago
      If you're a type purist then undefined looks nicer... It'd be like being upset at booleans because things get coerced to them or some 'ish. No: it's the type that has one inhabitant—it's not that type's fault that it appears as a default argument or var or was left out of JSON... So long as typeof null === "object", null is the absurd one
      - moritzwarhier 4mo ago
        undefined is not less absurd because there are parts of the standard that allow you to differentiate between undefined and a non-initialized value. Of course you shouldn't do that, but I once encountered a library that behaved differently depending on whether an option in an options bag object was not present or explicitly set to undefined. You can run into similar ugliness with function parameters, if you do evil things like using arguments And of course you can explicitly check keys of objects, including parameters that are going to be destructured. All not things you should do, but taints the "purity" argument, doesn't it? :D
    - ngruhn 4mo ago
      You can't get rid of undefined. You can't ban null either. They're both used in the core language all over the place: undefined camp: - out of bounds array index access [1,2,3][42] - non existent object key access {}.foo - array.find(...) no result - ... null camp: - document.querySelector(...) no result - regex.match(...) no result - ...
      - sheept 4mo ago
        In general the language uses `null` if it would otherwise return an object (similar to Java; this is also why null is an object but not really in both languages), while `undefined` is used if it could otherwise return any value. Could the language have done without both null and undefined? Definitely. But it's here and here to stay. Though, it's not the only language with two nulls. Julia has nothing and missing, though their semantics are more well defined and with different behaviors than in JavaScript.
    - Tade0 4mo ago
      null is of type 'object' though, while undefined is undefined - way better to have a separate type.
    - veidelis 4mo ago
      I personally think null is useless. I write TS not JS btw.
  - sheept 4mo ago
    You probably meant [object Object] :) Since arrays have their own default toString implementation (its own can of worms that is the basis for JSFuck[0]), you'd have to go out of your way with Object.prototype.toString.call to get [object Array] [0]: https://jsfuck.com/ https://jsfuck.com/ relies on Array#toString for casting values to strings
    - moritzwarhier 4mo ago
      I intentionally corrected it, because vanilla JS arrays used to behave like this in some contexts, but I'm not even sure about which ones still. Since the "Array" is a reference to the prototype, I think it might be outdated due to changes in undefined behavior of runtimes when serializing array objects, or logging them. I'm pretty sure that [object Array] used to be the result of logging an array at some point. Object.prototype.toString always returns the result of Array.prototype.join per spec, afaik, so for an empty array it's the empty string.
    - chrisandchris 4mo ago
      Yep, there are no arrays in JS. There are just objects, that behave like arrays.
      - moritzwarhier 4mo ago
        https://tc39.es/ecma262/multipage/indexed-collections.html#sec-array-objects https://tc39.es/ecma262/multipage/indexed-collections.html#s... > Arrays are exotic objects that give special treatment to a certain class of property names. See 10.4.2 for a definition of this special treatment. I just meant these special properties. The behavior, apart from the square-bracket syntax for construction, can be emulated using Object property descriptors, Symbol.iterator etc, but AFAIK, much of this is retro-fitted. Not disagreeing with the fact that arrays are almost just regular objects in JS, but the "just" in "just objects" does have nuances, AFAIK. JIT Optimizations for non-sparse arrays might just be part of a larger hot-path optimization system, but I think there are still differences. Is it possible to create an object for which Array.isArray returns true without it being instantiated using an array constructor or other array-returning function, the Array prototype, or square-bracket syntax? E.g. Array.from({"0": 1, "1: 2}) Array.from({length: 2}, (i) => i + 1) [1, 2] [...Object.values{"a": 1, "b": 2})] ... all implicitly use the built-in Array prototype. I'm not sure if it's possible to build an array using only primitives and functions from the Object. namespace, for example.

noman-land 4mo ago

He was pretty close to being NaN% correct.

moritzwarhier 4mo ago
To be fair there were a couple of disasters, such as [object Array] and undefined. Feels like the world is hanging on a single thread by now.
- jschrf 4mo ago
  Protip: never even mention undefined in your codebase. Erase it from your vernacular. If you ever need to pass or return nothing, you use null.
  - moritzwarhier 4mo ago
    I do it this way, but this led to people asking me in reviews why I use NULL^^ My explanation was that it signals intent to me, and is different from some property not being part of the expected object shape or not having been initialized because of some accident or logic failure. Since then, I've sticked to it, and am "allowed" to use NULL ^^ It can lead to some annoying checks in TS for primitively-typed properties, so for these, I still allow explicit usage of undefined when it's simpler given the surrounding code. But I agree with you in principle. Using "undefined" as a "second nullish value" and explicitly checking for it is a programming error. When there's object/areay vs null/undefined, thankfully, the truthiness narrowing often allows me to interface with code relying on "undefined" without explicitly handling this "value" in my own parts of the code base :)
  - crdrost 4mo ago
    If you're a type purist then undefined looks nicer... It'd be like being upset at booleans because things get coerced to them or some 'ish. No: it's the type that has one inhabitant—it's not that type's fault that it appears as a default argument or var or was left out of JSON... So long as typeof null === "object", null is the absurd one
    - moritzwarhier 4mo ago
      undefined is not less absurd because there are parts of the standard that allow you to differentiate between undefined and a non-initialized value. Of course you shouldn't do that, but I once encountered a library that behaved differently depending on whether an option in an options bag object was not present or explicitly set to undefined. You can run into similar ugliness with function parameters, if you do evil things like using arguments And of course you can explicitly check keys of objects, including parameters that are going to be destructured. All not things you should do, but taints the "purity" argument, doesn't it? :D
  - ngruhn 4mo ago
    You can't get rid of undefined. You can't ban null either. They're both used in the core language all over the place: undefined camp: - out of bounds array index access [1,2,3][42] - non existent object key access {}.foo - array.find(...) no result - ... null camp: - document.querySelector(...) no result - regex.match(...) no result - ...
    - sheept 4mo ago
      In general the language uses `null` if it would otherwise return an object (similar to Java; this is also why null is an object but not really in both languages), while `undefined` is used if it could otherwise return any value. Could the language have done without both null and undefined? Definitely. But it's here and here to stay. Though, it's not the only language with two nulls. Julia has nothing and missing, though their semantics are more well defined and with different behaviors than in JavaScript.
  - Tade0 4mo ago
    null is of type 'object' though, while undefined is undefined - way better to have a separate type.
  - veidelis 4mo ago
    I personally think null is useless. I write TS not JS btw.
- sheept 4mo ago
  You probably meant [object Object] :) Since arrays have their own default toString implementation (its own can of worms that is the basis for JSFuck[0]), you'd have to go out of your way with Object.prototype.toString.call to get [object Array] [0]: https://jsfuck.com/ https://jsfuck.com/ relies on Array#toString for casting values to strings
  - moritzwarhier 4mo ago
    I intentionally corrected it, because vanilla JS arrays used to behave like this in some contexts, but I'm not even sure about which ones still. Since the "Array" is a reference to the prototype, I think it might be outdated due to changes in undefined behavior of runtimes when serializing array objects, or logging them. I'm pretty sure that [object Array] used to be the result of logging an array at some point. Object.prototype.toString always returns the result of Array.prototype.join per spec, afaik, so for an empty array it's the empty string.
  - chrisandchris 4mo ago
    Yep, there are no arrays in JS. There are just objects, that behave like arrays.
    - moritzwarhier 4mo ago
      https://tc39.es/ecma262/multipage/indexed-collections.html#sec-array-objects https://tc39.es/ecma262/multipage/indexed-collections.html#s... > Arrays are exotic objects that give special treatment to a certain class of property names. See 10.4.2 for a definition of this special treatment. I just meant these special properties. The behavior, apart from the square-bracket syntax for construction, can be emulated using Object property descriptors, Symbol.iterator etc, but AFAIK, much of this is retro-fitted. Not disagreeing with the fact that arrays are almost just regular objects in JS, but the "just" in "just objects" does have nuances, AFAIK. JIT Optimizations for non-sparse arrays might just be part of a larger hot-path optimization system, but I think there are still differences. Is it possible to create an object for which Array.isArray returns true without it being instantiated using an array constructor or other array-returning function, the Array prototype, or square-bracket syntax? E.g. Array.from({"0": 1, "1: 2}) Array.from({length: 2}, (i) => i + 1) [1, 2] [...Object.values{"a": 1, "b": 2})] ... all implicitly use the built-in Array prototype. I'm not sure if it's possible to build an array using only primitives and functions from the Object. namespace, for example.