3 ms·

I really wouldn't draw any larger conclusions about Javascript from these examples or from the results of this test. These are edge cases. every language has

I really wouldn't draw any larger conclusions about Javascript from these examples or from the results of this test. These are edge cases. every language has them No sane programmer would put anything like these examples in a normal program, and knowing these edge cases doesn't really help you solve problems or get things done. Because you just won't encounter them in real life.

sek 13y ago
I wouldn't say that. The really nasty bugs come exactly from examples like these. This can save you hours at some point, I had to find some of them the hard way.
- TheZenPsycho 13y ago
  typeof is broken. instanceOf is broken. precision arithmetic on floats is broken var hoisting and function scope is a misfeature It's more useful to know those facts than to know the exact result of them in individual contexts well enough to answer a multiple choice question. It's more useful, if you see these examples in real life, to just rewrite them from scratch to not use the broken parts of javascript. Javascript has pitfalls and ugly parts. they can be avoided. this test gives you no great insight into them, or how to avoid them.
  - rnnr 13y ago
    Yeap but the most probable way to learn about them is to lose several hours debugging each of them. I don't think there is other language that comes close to javascript. Ok it's everywhere now, you make a lot of money with it, that's what we have now, but you and others defending it make my ears bleed.
  - sek 13y ago
    Well even if something is "broken" you have to use it once in a while, how can you avoid function scope and typeof? Also sometimes you have to maintain code, so it's not a choice. There are always explanations that are helpful. You have to know about the pitfalls to be able to avoid them. The questions just make you study the examples and also it's more fun this way.
    - TheZenPsycho 13y ago
      I actually totally agree with you. But if this is your only exposure to these things then I can't expect you'd gain that much insight.
  - hk__2 13y ago
    how is function scope a misfeature?
    - TheZenPsycho 13y ago
      it should have been block scope.
  - al2o3cr 13y ago
    "typeof is broken. instanceOf is broken. precision arithmetic on floats is broken var hoisting and function scope is a misfeature" Sounds like one hell of a PR pitch. :) I got 15/37, in no small part by guessing "what's the most bizarre and inconsistent thing that could happen here"? Apparently my imagination is less vivid than JS's.
    - TheZenPsycho 13y ago
      I'm not saying Javascript is perfect. just that you can't draw many useful conclusions from a document that sets out to find specifically its weirdest (mis)features. And actually you could avoid using "typeof" by using polyfills/builtins for the new "is[Type]" range of functions in ecmascript5. or a similar one from a library.
lmkg 13y ago
I disagree, several of these issues can come in up innocent programs written by less-seasoned practitioners. For example, [] not ==ing [] seems like it would be an incredibly common noob mistake. Some of the auto-conversion rules make certain classes of true bugs difficult to find. And I could see someone from a more 'traditional' OOP background getting bitten by "string" != new String("string") != String("string). I will give you that many of these test cases are simply looking for trouble, especially the examples explicitly monkeying around with, especially anything involving direct manipulation of prototypes. I am also personally not bothered by most numeric wonkyness because that's floats in general, not JavaScript in particular (though I wish it had true Ints).
- whocares111 13y ago
  No.
- leeoniya 13y ago
  when you realize that "[]" is the same as "new Array()", it's not at all confusing. however, typeof NaN == "number" is a major wtf.
overgard 13y ago
Every language has /some/ edge cases. Javascript is one big broken edge case.
- TheZenPsycho 13y ago
  I hear that kind of sentiment a lot here on hacker news. It doesn't make sense to me in the context of also giving C, C++ and PHP a pass. Javascript is a paragon of design genius compared to those languages. Especially PHP, which nobody is even forced to use. You could use any language on the server!
jimmaswell 13y ago
Yes, but what other common language besides PHP has so many ridiculous edge cases? None I use.
- Pacabel 13y ago
  Perl would likely be the next closest, but even it's nowhere near as bad as PHP and JavaScript are.
- TheZenPsycho 13y ago
  Ruby has about as many. So does C, and C++, which each have much more, with the extra twist that C and C++'s edge cases are wildly different depending on which compiler you use and which platform, and this is labelled a "feature". and Python. And Perl of course. Bash. I bet you could make a similar quiz for Java too.
  - jimmaswell 13y ago
    If anything varies between compilers in C/C++ then you're using undefined behavior. Not the language's fault. The edge cases of these languages are less jarring then Javascript's and make more sense.
Kerrick 13y ago
To be honest, I spent half an hour today debugging some JavaScript I'd written recently that looked something like this: var array = ["a", "b"]; var otherArray = ["c", "d"]; otherArray.forEach(array.push, array); console.log(array); I expected array to become ["a", "b", "c", "d"], but it actually becomes ["a", "b", "c", 0, <Array>, "d", 1, <Array>]. This is because Array#push accepts 1 through n arguments, not just 1 argument. (I couldn't use Array#concat for reasons that don't show up in this simplified example.)
- TheZenPsycho 13y ago
  push was designed and made about a decade before "forEach". Your code sample is not surprising or obscure to someone who has skimmed documentation on "push" and "forEach"

sek 13y ago

I wouldn't say that. The really nasty bugs come exactly from examples like these. This can save you hours at some point, I had to find some of them the hard way.

TheZenPsycho 13y ago
typeof is broken. instanceOf is broken. precision arithmetic on floats is broken var hoisting and function scope is a misfeature It's more useful to know those facts than to know the exact result of them in individual contexts well enough to answer a multiple choice question. It's more useful, if you see these examples in real life, to just rewrite them from scratch to not use the broken parts of javascript. Javascript has pitfalls and ugly parts. they can be avoided. this test gives you no great insight into them, or how to avoid them.
- rnnr 13y ago
  Yeap but the most probable way to learn about them is to lose several hours debugging each of them. I don't think there is other language that comes close to javascript. Ok it's everywhere now, you make a lot of money with it, that's what we have now, but you and others defending it make my ears bleed.
- sek 13y ago
  Well even if something is "broken" you have to use it once in a while, how can you avoid function scope and typeof? Also sometimes you have to maintain code, so it's not a choice. There are always explanations that are helpful. You have to know about the pitfalls to be able to avoid them. The questions just make you study the examples and also it's more fun this way.
  - TheZenPsycho 13y ago
    I actually totally agree with you. But if this is your only exposure to these things then I can't expect you'd gain that much insight.
- hk__2 13y ago
  how is function scope a misfeature?
  - TheZenPsycho 13y ago
    it should have been block scope.
- al2o3cr 13y ago
  "typeof is broken. instanceOf is broken. precision arithmetic on floats is broken var hoisting and function scope is a misfeature" Sounds like one hell of a PR pitch. :) I got 15/37, in no small part by guessing "what's the most bizarre and inconsistent thing that could happen here"? Apparently my imagination is less vivid than JS's.
  - TheZenPsycho 13y ago
    I'm not saying Javascript is perfect. just that you can't draw many useful conclusions from a document that sets out to find specifically its weirdest (mis)features. And actually you could avoid using "typeof" by using polyfills/builtins for the new "is[Type]" range of functions in ecmascript5. or a similar one from a library.

lmkg 13y ago

I disagree, several of these issues can come in up innocent programs written by less-seasoned practitioners. For example, [] not ==ing [] seems like it would be an incredibly common noob mistake. Some of the auto-conversion rules make certain classes of true bugs difficult to find. And I could see someone from a more 'traditional' OOP background getting bitten by "string" != new String("string") != String("string). I will give you that many of these test cases are simply looking for trouble, especially the examples explicitly monkeying around with, especially anything involving direct manipulation of prototypes. I am also personally not bothered by most numeric wonkyness because that's floats in general, not JavaScript in particular (though I wish it had true Ints).

whocares111 13y ago
No.
leeoniya 13y ago
when you realize that "[]" is the same as "new Array()", it's not at all confusing. however, typeof NaN == "number" is a major wtf.

overgard 13y ago

Every language has /some/ edge cases. Javascript is one big broken edge case.

TheZenPsycho 13y ago
I hear that kind of sentiment a lot here on hacker news. It doesn't make sense to me in the context of also giving C, C++ and PHP a pass. Javascript is a paragon of design genius compared to those languages. Especially PHP, which nobody is even forced to use. You could use any language on the server!

jimmaswell 13y ago

Yes, but what other common language besides PHP has so many ridiculous edge cases? None I use.

Pacabel 13y ago
Perl would likely be the next closest, but even it's nowhere near as bad as PHP and JavaScript are.
TheZenPsycho 13y ago
Ruby has about as many. So does C, and C++, which each have much more, with the extra twist that C and C++'s edge cases are wildly different depending on which compiler you use and which platform, and this is labelled a "feature". and Python. And Perl of course. Bash. I bet you could make a similar quiz for Java too.
- jimmaswell 13y ago
  If anything varies between compilers in C/C++ then you're using undefined behavior. Not the language's fault. The edge cases of these languages are less jarring then Javascript's and make more sense.

Kerrick 13y ago

To be honest, I spent half an hour today debugging some JavaScript I'd written recently that looked something like this: var array = ["a", "b"]; var otherArray = ["c", "d"]; otherArray.forEach(array.push, array); console.log(array); I expected array to become ["a", "b", "c", "d"], but it actually becomes ["a", "b", "c", 0, <Array>, "d", 1, <Array>]. This is because Array#push accepts 1 through n arguments, not just 1 argument. (I couldn't use Array#concat for reasons that don't show up in this simplified example.)

TheZenPsycho 13y ago
push was designed and made about a decade before "forEach". Your code sample is not surprising or obscure to someone who has skimmed documentation on "push" and "forEach"