Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Do you really know JavaScript?

javascript-puzzlers.herokuapp.com

Post reply on HN
Print view View original

51–60 of 73 posts

Re: Do you really know JavaScript?

#51

Post by erichurkman »

noir_lord wrote: post #13
clavalle wrote: post #7

I wish there was a 'JavaScript Under the Microscope' like 'Ruby Under the Microscope' by Pat Shaughnessy. I think I would have a much better understanding of JavaScript if I knew how a good javascript engine works.

> I think I would have a much better understanding of JavaScript if I knew how a good javascript engine works. So would the people who write the good javascript engines. I'm joking but only partially as they have to write an engine against both a standard and a convention plus support all the hacks going back years. It's a mess but what I'm slowly and painfully learning is that if you avoid the shoals and hidden wrec…

One easy step in the right direction is a quality build process that includes linting and strong error/warning reporting. Push your code through the Closure compiler and keep JSHint (or your favorite linter) active in your editor and you're already taking a strong step to better JavaScript.

Re: Do you really know JavaScript?

#52

Post by magicalist »

Zarel wrote: post #21

This question is wrong: What is the result of this expression? (or multiple ones) "1 2 3".replace(/d/g, parseInt) It says the correct answer is "1 NaN 3" but the real correct answer is "1 2 3". I assume it's a typo of: "1 2 3".replace(/\d/g, parseInt) In addition, for several questions, such as this: var x = [].reverse; x(); Their 'official' answer is only true outside of strict mode. So to add to TheZenPsycho's comm…

For the

  function f() {}
  var parent = Object.getPrototypeOf(f);
  typeof eval(parent.name)
one, this is also wrong. I can't find anywhere in the spec that a name is required for Function.prototype[1], and 15.3.4.2 actually says that Function.prototype.toString() can return "An implementation-dependent representation of the function". Spidermonkey assigns it no name, so

  typeof eval(parent.name)
just returns 'undefined', it doesn't throw an error. There's certainly no requirement that it be invocable by name, and, indeed, if v8 had left a function named 'Empty' in the global scope, that would have been bad.

[1] http://es5.github.io/#x15.3.4

Re: Do you really know JavaScript?

#53

Post by magicalist »

magicalist wrote: post #52
Zarel wrote: post #21

This question is wrong: What is the result of this expression? (or multiple ones) "1 2 3".replace(/d/g, parseInt) It says the correct answer is "1 NaN 3" but the real correct answer is "1 2 3". I assume it's a typo of: "1 2 3".replace(/\d/g, parseInt) In addition, for several questions, such as this: var x = [].reverse; x(); Their 'official' answer is only true outside of strict mode. So to add to TheZenPsycho's comm…

For the function f() {} var parent = Object.getPrototypeOf(f); typeof eval(parent.name) one, this is also wrong. I can't find anywhere in the spec that a name is required for Function.prototype[1], and 15.3.4.2 actually says that Function.prototype.toString() can return "An implementation-dependent representation of the function". Spidermonkey assigns it no name, so typeof eval(parent.name) just returns 'undefined',…

Also, using 'class' as an IdentifierName is incorrectly explained in the answer for

  var a = {class: "Animal", name: 'Fido'};
  a.class
as this will correctly return "Animal" in most browsers. It may be true that it's buggy in IE, but that's a bug, not part of the language. 'class' is a reserved word, but only as an Identifier, not an IdentifierName.

That might seem like a confusing splitting of hairs, but that's just due to the fact this is from a spec, not an explanation. In practice it basically means that you can't declare a variable with a reserved word name, but something like a property name (like a.class, or used when initializing a variable via an object literal) is fine using a reserved word.

In fact, the difference between an Identifier and an IdentifierName has allowed more than a few of the changes coming in ECMAScript 6 to be backwards compatible.

Even when not excusing browser bugs, there's a lot of sloppiness in this quiz.

Re: Do you really know JavaScript?

#54

Post by anaphor »

gcommer wrote: post #19
clavalle wrote: post #7

I wish there was a 'JavaScript Under the Microscope' like 'Ruby Under the Microscope' by Pat Shaughnessy. I think I would have a much better understanding of JavaScript if I knew how a good javascript engine works.

The author of this quiz could have made this a great learning opportunity by linking to the appropriate sections in ECMA-262[0]. For example, question 15 makes a lot more sense when you read "ToBoolean" (Sec 9.2) which shows that all objects (including arrays) are always considered truthy values, however when compared with ==, "The Abstract Equality Comparison Algorithm" (11.9.3) is used, which gives this behavior: >…

So it's like Scheme's "eq?", except less useful?

Re: Do you really know JavaScript?

#55

Post by nfm »

trevorhartman wrote: post #27

Yes, but I don't know the answers to these questions because I know to avoid code like this.

Sure, some of these examples are pretty academic (eg ` Array.isArray( Array.prototype )`). But can you truthfully say you never get bitten by basic JS arithmetic fails, given how many ways it's possible to accidentally coerce numbers to strings?

Re: Do you really know JavaScript?

#56

Post by Zarel »

magicalist wrote: post #53
magicalist wrote: post #52

Earlier quoted context omitted.

For the function f() {} var parent = Object.getPrototypeOf(f); typeof eval(parent.name) one, this is also wrong. I can't find anywhere in the spec that a name is required for Function.prototype[1], and 15.3.4.2 actually says that Function.prototype.toString() can return "An implementation-dependent representation of the function". Spidermonkey assigns it no name, so typeof eval(parent.name) just returns 'undefined',…

Also, using 'class' as an IdentifierName is incorrectly explained in the answer for var a = {class: "Animal", name: 'Fido'}; a.class as this will correctly return "Animal" in most browsers. It may be true that it's buggy in IE, but that's a bug, not part of the language. 'class' is a reserved word, but only as an Identifier, not an IdentifierName. That might seem like a confusing splitting of hairs, but that's just d…

`a.class` is explicitly legal in ES5, which is the spec that explicitly allows trailing commas in the `[,,,].join(", ")` question, so it's at least a bit confused about which version of JavaScript it's quizzing.

Re: Do you really know JavaScript?

#57

Post by TheZenPsycho »

hk__2 wrote: post #45
TheZenPsycho wrote: post #20

Earlier quoted context omitted.

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. Javascri…

how is function scope a misfeature?

it should have been block scope.

Re: Do you really know JavaScript?

#58

Post by ycmike »

SonicSoul wrote: post #40
ycmike wrote: post #15

Earlier quoted context omitted.

Agreed. I don't want to ever show my score.

Agreed. I already made arrangements to have my things shipped to Alaska where i will live out the rest of my days .. this "programming" thing didn't pan out.

That is rich.

Re: Do you really know JavaScript?

#59

Post by TheZenPsycho »

overgard wrote: post #32
TheZenPsycho wrote: post #14

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.

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

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!

Re: Do you really know JavaScript?

#60

Post by TheZenPsycho »

al2o3cr wrote: post #47
TheZenPsycho wrote: post #20

Earlier quoted context omitted.

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. Javascri…

"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.

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.

Post reply on HN