3 ms·

I honestly have no idea what's so confusing. I've been working with javascript for over a decade and have NONE of this memorized, and I never look it up or che

by qwer 13y ago

I honestly have no idea what's so confusing. I've been working with javascript for over a decade and have NONE of this memorized, and I never look it up or check it in the repl. It's simply not an issue if you're using jshint and unit testing your code. If you come from a static language background and you keep expecting a type-checker will save you from doing silly things like adding arrays to strings, you're always going to hate Javascript. It's a dynamically typed language, and so you have to learn the quality-control tools and practices for dynamically typed languages.

epidemian 13y ago
> It's a dynamically typed language [...] I don't think being a dynamically typed language has anything to do with having weird type coercion rules for the most basic operations. Nor with allowing seemingly invalid operations (e.g. adding arrays and strings) and returning a value instead of raising an error on those cases. > I honestly have no idea what's so confusing. Really? Comparing JS's == and + operators to other languages' (dynamically typed or not), wouldn't you say that JS's semantics are more complicated/confusing than what they should be?
- TheZenPsycho 13y ago
  You're not supposed to use ==. It's there only for backwards compatibility.
  - epidemian 13y ago
    Replace == by some other comparison operator like < or > if you prefer. The weird coercion rules still apply. >>> '5' < [6] true
    - TheZenPsycho 13y ago
      Why are you comparing a string to an array with a less than operator? when would that ever happen legitimately? Why would you expect any language to do something that made sense doing that?
      - epidemian 13y ago
        > when would that ever happen legitimately? Never. Aka, on buggy code. Instead of asking when that happens legitimately, why don't you ask why does it evaluate to a legitimate value? > Why would you expect any language to do something that made sense doing that? Because raising an error in those cases would: 1. Make the language simpler and easier to understand (and to implement). No coercion rules, not guessing what some other developer meant when they wrote `a == 0` (are they asking for numeric equality, or could `a` be a string or a boolean value too?). 2. Make it easier to identify the bug in case it should happen. Let me ask you, do you also think syntax errors are unnecessary too? Because, why would anyone write a program with invalid syntax? Why would one expect any language to do something that made sense, like not compiling/running the code, in those cases? Wouldn't it be better if, for example, in case a line contains a syntactic error, the interpreter would just discard that like and run the program anyway?
        TheZenPsycho 13y ago
        You can't make history something it's not. You might or might not remember visiting the web soon after javascript was released. It involved a lot of broken code, and a lot of error pop ups. Javascript was, historically, a dumb easy scripting language for simple interactive effects on the web. When we're talking about a script that is downloaded from a server, and runs in a browser, that is a much different kind of situation than a programming language usually encounters. It is in the browser maker's interest to be liberal about what it accepts. this is the core reason for the success of html, and the failure of xhtml. as much as the makers of javascript would like to remove certain problematic features, they cannot without breaking old existing content. Now if you want a strict language in the browser that disallows that sort of nonsense, it's easy. Just run JSLINT on your code before deploying it. JSLint considers as an error, pretty much all of your complaints here. If you don't like some aspect of javascript, you can simply not use it. If there's something jslint doesn't catch, I suppose you could always add stuff to jslint. JSLINT is your static compiler. There are solutions to your pain and suffering. you don't have to endure it.
gargantuan 13y ago
> If you come from a static language background and you keep expecting a type-checker will save you from doing silly things like adding arrays to strings, you're always going to hate Javascript. Hmm funny I come from a dynamic language background and never had a problem with the language telling me adding an empty list to an empty list should somehow be empty string. That is batshit crazy. Those are not silly things those are basic 101 strong type system checks that very dynamics languages like Ruby and Python can do.
- qwer 13y ago
  "Strong-typing vs weak-typing" is actually irrelevant. It's still an error at run-time, and unless your quality control tools and practices actually run the code (like unit tests do), you're not going to know about them. As you move beyond native types, duck-typing (like in python) completely subverts the strong type-checks anyway.
lifthrasiir 13y ago
Dynamic typing (a type belongs to the value, not the variable or "slot") is not same as weak typing (a type may get silently messed up). Python is a good example of dynamically but yet strongly typed language. There exists a good argument against the whole notion of "strong"/"weak" distinction (mainly because it is not a bipartite property, and well-defined type coercion can be regarded as safe) but the main idea holds.

by qwer 13y ago

epidemian 13y ago

> It's a dynamically typed language [...] I don't think being a dynamically typed language has anything to do with having weird type coercion rules for the most basic operations. Nor with allowing seemingly invalid operations (e.g. adding arrays and strings) and returning a value instead of raising an error on those cases. > I honestly have no idea what's so confusing. Really? Comparing JS's == and + operators to other languages' (dynamically typed or not), wouldn't you say that JS's semantics are more complicated/confusing than what they should be?

TheZenPsycho 13y ago
You're not supposed to use ==. It's there only for backwards compatibility.
- epidemian 13y ago
  Replace == by some other comparison operator like < or > if you prefer. The weird coercion rules still apply. >>> '5' < [6] true
  - TheZenPsycho 13y ago
    Why are you comparing a string to an array with a less than operator? when would that ever happen legitimately? Why would you expect any language to do something that made sense doing that?
    - epidemian 13y ago
      > when would that ever happen legitimately? Never. Aka, on buggy code. Instead of asking when that happens legitimately, why don't you ask why does it evaluate to a legitimate value? > Why would you expect any language to do something that made sense doing that? Because raising an error in those cases would: 1. Make the language simpler and easier to understand (and to implement). No coercion rules, not guessing what some other developer meant when they wrote `a == 0` (are they asking for numeric equality, or could `a` be a string or a boolean value too?). 2. Make it easier to identify the bug in case it should happen. Let me ask you, do you also think syntax errors are unnecessary too? Because, why would anyone write a program with invalid syntax? Why would one expect any language to do something that made sense, like not compiling/running the code, in those cases? Wouldn't it be better if, for example, in case a line contains a syntactic error, the interpreter would just discard that like and run the program anyway?
      - TheZenPsycho 13y ago
        You can't make history something it's not. You might or might not remember visiting the web soon after javascript was released. It involved a lot of broken code, and a lot of error pop ups. Javascript was, historically, a dumb easy scripting language for simple interactive effects on the web. When we're talking about a script that is downloaded from a server, and runs in a browser, that is a much different kind of situation than a programming language usually encounters. It is in the browser maker's interest to be liberal about what it accepts. this is the core reason for the success of html, and the failure of xhtml. as much as the makers of javascript would like to remove certain problematic features, they cannot without breaking old existing content. Now if you want a strict language in the browser that disallows that sort of nonsense, it's easy. Just run JSLINT on your code before deploying it. JSLint considers as an error, pretty much all of your complaints here. If you don't like some aspect of javascript, you can simply not use it. If there's something jslint doesn't catch, I suppose you could always add stuff to jslint. JSLINT is your static compiler. There are solutions to your pain and suffering. you don't have to endure it.

gargantuan 13y ago

> If you come from a static language background and you keep expecting a type-checker will save you from doing silly things like adding arrays to strings, you're always going to hate Javascript. Hmm funny I come from a dynamic language background and never had a problem with the language telling me adding an empty list to an empty list should somehow be empty string. That is batshit crazy. Those are not silly things those are basic 101 strong type system checks that very dynamics languages like Ruby and Python can do.

qwer 13y ago
"Strong-typing vs weak-typing" is actually irrelevant. It's still an error at run-time, and unless your quality control tools and practices actually run the code (like unit tests do), you're not going to know about them. As you move beyond native types, duck-typing (like in python) completely subverts the strong type-checks anyway.

lifthrasiir 13y ago

Dynamic typing (a type belongs to the value, not the variable or "slot") is not same as weak typing (a type may get silently messed up). Python is a good example of dynamically but yet strongly typed language. There exists a good argument against the whole notion of "strong"/"weak" distinction (mainly because it is not a bipartite property, and well-defined type coercion can be regarded as safe) but the main idea holds.