3 ms·

JavaScript was made in like ten days just to add missing interactivity to HTML. If Brendan Eich had known how it was going to be used today, the language would

JavaScript was made in like ten days just to add missing interactivity to HTML. If Brendan Eich had known how it was going to be used today, the language would have been very different, if at all. Edit: it seems I don't have to wonder. Type coercion is one of the worst features IMO, and coincidentally one of his regrets: > "One of the notorious ones was, ‘I’d like to compare a number to a string that contains that numeral. And I don’t want to have to change my code to convert the string to a number, or the number to a string. I just want it to work. Can you please make the equals operator just say, Oh this looks like a two, and this looks like a string number two. They’re equal enough.’" > "And I did it. And that’s a big regret, because that breaks an important mathematical property, the equivalence relation property… It led to the addition of a second kind of equality operator when we standardized JavaScript.” One of the people who helped standardize JavaScript was Guy Steele, one of the co-creators of Scheme. “Guy said, ‘Don’t worry about it. There are Lisps that have five kinds of equals operators. We’ll just add another one.'" https://thenewstack.io/brendan-eich-on-creating-javascript-in-10-days-and-what-hed-do-differently-today/ https://thenewstack.io/brendan-eich-on-creating-javascript-i...

deckard1 5y ago
The problem with equality and dynamic typing is rather deep and intractable. Kent Pitman (of Lisp fame) has an entire essay about it: https://www.nhplace.com/kent/PS/EQUAL.html https://www.nhplace.com/kent/PS/EQUAL.html > If COPY can't be done properly, then neither can EQUAL. And, in fact, that's the case. There is no uniquely determined equality function for complex structures--there are only arbitrary ones. What Steele says about equality is true for Scheme. Everyone has seen the famous "Wat" video of adding "{} + {}" in Ruby or JS. But no one ever mentions Scheme or Lisp: scheme@(guile-user)> (eq? "test" "test") $1 = #t scheme@(guile-user)> (eqv? "test" "test") $2 = #t scheme@(guile-user)> (define x "test") scheme@(guile-user)> (define y "test") scheme@(guile-user)> (eq? x y) $3 = #f scheme@(guile-user)> (eqv? x y) $4 = #f Of course, if you read the RxRS specs then it's all documented and to be expected. But the same is true for JavaScript. As much as I hate typing the "===", there is precedence. > breaks an important mathematical property Even mathematicians get lazy and create new syntax and short cuts to express their ideas. Programming is ultimately a human UI. It's easy to see why automatic type coercion was once popular (and probably will be again, I can almost guarantee this).
- tialaramex 5y ago
  I was surprised that I was OK with that fact that in Rust a vector and an array with the same elements compare equal. It felt completely reasonable, and I definitely didn't feel that way about it in some other languages where that's true.
  - bsder 5y ago
    Erm, no, that doesn't work. I created a quick check in the Rust Playground: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=473a0c6db6ca709a11dd501e38f3f0dc https://play.rust-lang.org/?version=stable&mode=debug&editio... Do you have some more context? I suspect somehow things are getting coerced to slices and then compared.
    - Measter 5y ago
      The implementation isn't symmetric, it'll work if you compare `b == a`. Apparently[0] it's something to do with avoiding code bloat. [0] https://github.com/rust-lang/rust/blob/e4c23daeb461ac02413eb36c8cefcc5530638a05/library/alloc/src/vec/partial_eq.rs#L39 https://github.com/rust-lang/rust/blob/e4c23daeb461ac02413eb...
  - fee1-dead 5y ago
    I suppose the reason is Vec<T> implements `Borrow<[T]>` and [T; N] implements Borrow<[T]> as well. The trait implementation requires these types to have same implementations for all traits including comparisons and hashing. Returning `false` when types don't match doesn't make sense in Rust since Rust is strongly typed (and not interpreted). And say if we don't make them compare equal. then vec![1, 2] != [1, 2] but &vec![1, 2] == &[1, 2], which is just too opaque and confusing. This behavior is no fit for a language like Rust.
- deleted 5y ago
  [deleted]
- filoeleven 5y ago
  This does work in Clojure. Edit: and Clojurescript, which is more relevant. (let [x “test” y “test”] (= x y)) ; returns true with both (let) and individual (def) https://clojure.org/guides/equality https://clojure.org/guides/equality

deckard1 5y ago

The problem with equality and dynamic typing is rather deep and intractable. Kent Pitman (of Lisp fame) has an entire essay about it: https://www.nhplace.com/kent/PS/EQUAL.html https://www.nhplace.com/kent/PS/EQUAL.html > If COPY can't be done properly, then neither can EQUAL. And, in fact, that's the case. There is no uniquely determined equality function for complex structures--there are only arbitrary ones. What Steele says about equality is true for Scheme. Everyone has seen the famous "Wat" video of adding "{} + {}" in Ruby or JS. But no one ever mentions Scheme or Lisp: scheme@(guile-user)> (eq? "test" "test") $1 = #t scheme@(guile-user)> (eqv? "test" "test") $2 = #t scheme@(guile-user)> (define x "test") scheme@(guile-user)> (define y "test") scheme@(guile-user)> (eq? x y) $3 = #f scheme@(guile-user)> (eqv? x y) $4 = #f Of course, if you read the RxRS specs then it's all documented and to be expected. But the same is true for JavaScript. As much as I hate typing the "===", there is precedence. > breaks an important mathematical property Even mathematicians get lazy and create new syntax and short cuts to express their ideas. Programming is ultimately a human UI. It's easy to see why automatic type coercion was once popular (and probably will be again, I can almost guarantee this).

tialaramex 5y ago
I was surprised that I was OK with that fact that in Rust a vector and an array with the same elements compare equal. It felt completely reasonable, and I definitely didn't feel that way about it in some other languages where that's true.
- bsder 5y ago
  Erm, no, that doesn't work. I created a quick check in the Rust Playground: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=473a0c6db6ca709a11dd501e38f3f0dc https://play.rust-lang.org/?version=stable&mode=debug&editio... Do you have some more context? I suspect somehow things are getting coerced to slices and then compared.
  - Measter 5y ago
    The implementation isn't symmetric, it'll work if you compare `b == a`. Apparently[0] it's something to do with avoiding code bloat. [0] https://github.com/rust-lang/rust/blob/e4c23daeb461ac02413eb36c8cefcc5530638a05/library/alloc/src/vec/partial_eq.rs#L39 https://github.com/rust-lang/rust/blob/e4c23daeb461ac02413eb...
- fee1-dead 5y ago
  I suppose the reason is Vec<T> implements `Borrow<[T]>` and [T; N] implements Borrow<[T]> as well. The trait implementation requires these types to have same implementations for all traits including comparisons and hashing. Returning `false` when types don't match doesn't make sense in Rust since Rust is strongly typed (and not interpreted). And say if we don't make them compare equal. then vec![1, 2] != [1, 2] but &vec![1, 2] == &[1, 2], which is just too opaque and confusing. This behavior is no fit for a language like Rust.
deleted 5y ago
[deleted]
filoeleven 5y ago
This does work in Clojure. Edit: and Clojurescript, which is more relevant. (let [x “test” y “test”] (= x y)) ; returns true with both (let) and individual (def) https://clojure.org/guides/equality https://clojure.org/guides/equality