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

21–30 of 73 posts

Re: Do you really know JavaScript?

#21

Post by Zarel »

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 comments, not only are these edge cases, many are edge cases that are known and that strict mode tries to solve.

I also object to []==[] being false as evidence that == is the spawn of Satan. == may be weird, but this is a case where === does the same thing. You just have to understand that [] and {} (and regex literals) construct new objects, and objects are compared by reference, not by value.

Re: Do you really know JavaScript?

#22

Post by lennel »

wil421 wrote: post #12
steven777400 wrote: post #2

This is a good way to distinguish between someone who knows JavaScript the language from someone who can apply JavaScript to perform DOM manipulation and data requests. Not that there's anything inherently wrong with the latter. I fall firmly in that latter camp; I do all my algorithmic work and heavy lifting in C# and just use JS to get data onto the client and display it. But it's easy for someone like to me to sta…

Agreed, I use Java for my heavy lifting. Use JS to display the data, provide some client side validation on forms, switch some classes around or manipulate something in the DOM using JQuery or the like. I cant create a full fledged client side JS app but I dont really need to if I have a larger language helping on the server side.

I create fully fledged JS apps on a big scale, the difference from this test to reality is startling. The difference is I enforce the use of the closure compiler in our team so 99% of these issues are caught by the compiler. end of story. this test is bullshit.

Re: Do you really know JavaScript?

#24

Post by johnbm »

"it goes into an infinite loop, 2^53 is the highest possible number in javascript, and 2^53+1 gives 2^53, so i can never become larger than that."

This is wrong. 2^53 is the highest integer value you can represent exactly with a 64-bit float without truncation, but much larger numbers are available, spaced more than 1 unit apart.

So 2^53 == 2^53 + 1 != 2^53 + 2 != 2^53 + 3 == 2^53 + 4 == 2^53 + 5 != 2^53 + 6.

Re: Do you really know JavaScript?

#26

Post by flebron »

I may be alone in this camp, but I'd actually recommend people read the ES5 spec if they want to be confident in their JS. It's one of the most readable and understandable specifications I've read, and (compared to behemoths like C++) is fairly short. There's even an internally-hyperlinked version at http://es5.github.io .

Re: Do you really know JavaScript?

#28

Post by grannyg00se »

I got two out of two and then stopped. This is another "look how many weird results we can get out of javascript" exercise.

Gary Bernhardt covered this humorously here: https://www.destroyallsoftware.com/talks/wat

And Crockford covers some issues more formally in his talks.

The takeaway is that if you do something that can possibly be interpreted in a strange way, javascript is mostly likely going to interpret it in a way that you didn't expect. You could say it sucks because of that and/or you can look at the ecmascript standard and try to reason about it. But either way, it's best not to do anything even slightly ambiguous. Stick to the good parts.

Re: Do you really know JavaScript?

#30

Post by lmkg »

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.

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

Post reply on HN