4 ms·

> But they had to dislike it in a productive, nuanced manner. No, they fundamentally rejected JavaScript, enough to build a whole new language and set of tools

> But they had to dislike it in a productive, nuanced manner. No, they fundamentally rejected JavaScript, enough to build a whole new language and set of tools. This was not a subtle dislike of a few aspects of it. Personally JavaScript absolutely terrifies me, it's a semantic mess, the equality table is one such example: https://dorey.github.io/JavaScript-Equality-Table/ https://dorey.github.io/JavaScript-Equality-Table/

ComputerGuru 6y ago
I’m not a fan of loosely-typed languages in general, but isn’t that chart pretty typical for dynamically typed interpreted languages? I know PHP’s is a mess and I’ve seen comparison/equality horror stories posted to HN regarding even the venerable Python.
- Athas 6y ago
  No, many dynamically typed languages do not perform implicit conversions: Lisp and Python are languages that do it better. They still have some subtleties (Lisp has the EQ/EQL distinction, not to mention a huge number of other quality operators in Common Lisp), but I see implicit conversions as a singularly bad idea in a dynamically typed language.
  - kazinator 6y ago
    Lisp certainly performs some implicit conversions in numeric computing. > (+ 1 1/10 3.0) 4.1 In this example, since + is a function, it's part of its semantics. There would be a lot of verbiage if arguments had to be coerced to all be of the same type. In addition to numeric examples, there are situations where Lisp is forgiving/flexible. For instance in most cases, a symbol can be used in place of a function object. The symbol is resolved to a function through its function binding. That can be regarded as an implicit conversion, or alternatively as polymorphism. Yet another example is that Common Lisp allows some string operations on symbols. (string= 'abc "ABC") -> T No conversion ever takes place in the evaluation, as far as I know, or the passage of a value (e.g. from a function argument expression into the argument). All these kinds of things happen inside specific functions according to their respective rules.
- deleted 6y ago
  [deleted]
goto11 6y ago
It is trivially easy to avoid though, just use === instead of ==. Most of the JavaScript wtf's are people getting confused by the implicit type conversions (like [] == ![]). If you ask for it, JavaScript will readily convert a string to a number or an object to a boolean. But if you don't like that, just don't rely on implicit conversions.
- willtim 6y ago
  The average developer spends most of her time reading other peoples code, so avoiding having to understand == is a luxury most will not have.
namelosw 6y ago
First, it's easy to fix by just using ===. Second, It's more of a blub programmer thing. From multiversal equality's perspective, almost every mainstream statically typed language is also a semantic mess - you can even compare int to a boolean with == in a statically typed language without having any type errors, despite the comparisons always return false and 99 out of 100 that's not what people meant.
- deleted 6y ago
  [deleted]
- willtim 6y ago
  Most mainstream statically typed languages use subtyping, that is why they permit equality comparisons of different (sub) types. But they should and do obey all the usual mathematical laws, associativity, transitivity etc.
- nyanpasu64 6y ago
  In C++, you cannot compare unrelated types unless there's an implicit conversion or explicit equality operator (or something like that). In Rust, you cannot compare same or different types unless you implement PartialEq, and you can't compare an int with a bool. In Java, you can't use == to compare an int and a bool (both primitives).
untog 6y ago
Literally the next tab on that page shows you the results with the === operator, which is what everyone uses. That you don’t know this shows me that you don’t actually understand JS very well. That’s fine! But don’t make and broadcast a judgement without doing the research.
- willtim 6y ago
  > That you don’t know this shows me that you don’t actually understand JS very well. I know about the === operator, but the original one still exists, as does all the code that was (and still is) written using it that needs to be reasoned about. That you think adding a non-obvious alternative to the language magically makes the problem go away, suggests to me that you are the one lacking understanding, not me. It was also just one example of many well documented issues with the language. > the === operator, which is what everyone uses Since you accused me of "broadcasting without research", I'd like to see the evidence for this claim. I just looked at the HackerNews JS and there's plenty of double equals in there.

ComputerGuru 6y ago

I’m not a fan of loosely-typed languages in general, but isn’t that chart pretty typical for dynamically typed interpreted languages? I know PHP’s is a mess and I’ve seen comparison/equality horror stories posted to HN regarding even the venerable Python.

Athas 6y ago
No, many dynamically typed languages do not perform implicit conversions: Lisp and Python are languages that do it better. They still have some subtleties (Lisp has the EQ/EQL distinction, not to mention a huge number of other quality operators in Common Lisp), but I see implicit conversions as a singularly bad idea in a dynamically typed language.
- kazinator 6y ago
  Lisp certainly performs some implicit conversions in numeric computing. > (+ 1 1/10 3.0) 4.1 In this example, since + is a function, it's part of its semantics. There would be a lot of verbiage if arguments had to be coerced to all be of the same type. In addition to numeric examples, there are situations where Lisp is forgiving/flexible. For instance in most cases, a symbol can be used in place of a function object. The symbol is resolved to a function through its function binding. That can be regarded as an implicit conversion, or alternatively as polymorphism. Yet another example is that Common Lisp allows some string operations on symbols. (string= 'abc "ABC") -> T No conversion ever takes place in the evaluation, as far as I know, or the passage of a value (e.g. from a function argument expression into the argument). All these kinds of things happen inside specific functions according to their respective rules.
deleted 6y ago
[deleted]

goto11 6y ago

It is trivially easy to avoid though, just use === instead of ==. Most of the JavaScript wtf's are people getting confused by the implicit type conversions (like [] == ![]). If you ask for it, JavaScript will readily convert a string to a number or an object to a boolean. But if you don't like that, just don't rely on implicit conversions.

willtim 6y ago
The average developer spends most of her time reading other peoples code, so avoiding having to understand == is a luxury most will not have.

namelosw 6y ago

First, it's easy to fix by just using ===. Second, It's more of a blub programmer thing. From multiversal equality's perspective, almost every mainstream statically typed language is also a semantic mess - you can even compare int to a boolean with == in a statically typed language without having any type errors, despite the comparisons always return false and 99 out of 100 that's not what people meant.

deleted 6y ago
[deleted]
willtim 6y ago
Most mainstream statically typed languages use subtyping, that is why they permit equality comparisons of different (sub) types. But they should and do obey all the usual mathematical laws, associativity, transitivity etc.
nyanpasu64 6y ago
In C++, you cannot compare unrelated types unless there's an implicit conversion or explicit equality operator (or something like that). In Rust, you cannot compare same or different types unless you implement PartialEq, and you can't compare an int with a bool. In Java, you can't use == to compare an int and a bool (both primitives).

untog 6y ago

Literally the next tab on that page shows you the results with the === operator, which is what everyone uses. That you don’t know this shows me that you don’t actually understand JS very well. That’s fine! But don’t make and broadcast a judgement without doing the research.

willtim 6y ago
> That you don’t know this shows me that you don’t actually understand JS very well. I know about the === operator, but the original one still exists, as does all the code that was (and still is) written using it that needs to be reasoned about. That you think adding a non-obvious alternative to the language magically makes the problem go away, suggests to me that you are the one lacking understanding, not me. It was also just one example of many well documented issues with the language. > the === operator, which is what everyone uses Since you accused me of "broadcasting without research", I'd like to see the evidence for this claim. I just looked at the HackerNews JS and there's plenty of double equals in there.