Earlier quoted context omitted.
I got it right the second time!
I got it wrong both times. Ouch.
I did too.
Do you really know JavaScript?
41–50 of 73 posts
Re: Do you really know JavaScript?
#42Can we please stop pretending JavaScript is some esoteric language?
I don't think that anyone really considers it "esoteric". There's not really any secret to it. Once one accepts that it's just a very poorly designed language, it makes perfect sense why it's so heavily broken in so many critical ways.
Re: Do you really know JavaScript?
#43Earlier quoted context omitted.
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.
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…
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.
Re: Do you really know JavaScript?
#44Earlier quoted context omitted.
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.
What exactly do you mean by "fully fledged JS apps on a big scale"?
When it comes to more traditional languages like C, C++ and Java, "fully fledged" and "big scale" are descriptors usually reserved for multi-million line systems consistently worked on by 50+ full-time developers at a time.
I'm very suspicious of such terminology being applied to JavaScript applications. We generally see a much, much smaller scale when it comes to those. The "high end" cases are usually topping out at 100,000 to 200,000 lines of code at most, and perhaps 10 or 20 developers. They're a far cry from the C, C++, Java and C# examples.
Is any of this code you've worked on publicly available?
Re: Do you really know JavaScript?
#45Earlier quoted context omitted.
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.
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?
Re: Do you really know JavaScript?
#46"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.
> 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.
Yeah, that one bothered me as well, though to be fair, it is a hard condition to phrase. You also gave a definition that isn't quite right, as 2^53 + 2 is an integer value that can be represented exactly with a 64-bit float without truncation :) Perhaps you meant "exactly" in a somewhat more nuanced way.
You'd have to phrase it as something like every positive integer less than or equal to 2^53 can be exactly represented with a double precision float. Of course, there are more positive integers above 2^53 that can be exactly represented by a double than there are below, they're just spread farther and farther apart, as you said.
Re: Do you really know JavaScript?
#47Earlier quoted context omitted.
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.
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.
Re: Do you really know JavaScript?
#48Earlier quoted context omitted.
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.
What benefits do JS apps have over a server-side language such as Java, C# or Ruby? Especially in an enterprise environment.
In most of my limited experience JS has been harder to work with than almost anything I have encountered. My personal experience using JS client side apps has left me feeling sour. Every time I visit a webpage and immediately hit a JS loading screen I cringe. Gmail is about the only I dont completely dislike that I know is written in JS.
Re: Do you really know JavaScript?
#49I 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…
when you realize that "[]" is the same as "new Array()", it's not at all confusing.
however, typeof NaN == "number" is a major wtf.
Re: Do you really know JavaScript?
#50This 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…
And one that has the right answer but explains it incorrectly:
> What is the result of this expression? (or multiple ones)
[1 True and false are greater than any number? What? This is not only not correct, it is contradicted by the answer. The real explanation is that 1 < 2 is true, which converts to 1, and thus less than 3; meanwhile, 3 < 2 is false, which converts to 0, and thus less than 1. This is actually the same result you would get in C.