I don't know why the second-top one has so many votes, it's completely wrong.

   var x = 1;
   var y = 3;
   var list = [0,1,2];
   x in list; //true
   y in list; //false
   1 in list; //true
   y in [3,4,5]; //true

That last expression is false. This is because the "in" operator does not check for values in the list; it checks for keys. Try this:

   javascript:alert(3 in [3,4,5])

The only things that will be true for "X in [3,4,5]" are 0, 1, and 2 for X (since these are the natural keys for the terms in the array). More specifically, "in" in general checks for members associated with objects (e.g., keys in an array, methods of a class, etc.):

   javascript:alert("The setFlag method " + ("setFlag" in {setFlag:function(){}} ? "exists" : "does not exist"))

EDIT: This makes the keyword considerably less useful (since indexOf doesn't work for the Array object in IE--although jQuery has a way around this), although it can be used to replace the less elegant

   if (typeof object.method == "undefined")

Oh whoa! I never realized I could just type "javascript:..." into the status bar in Firefox and have it run it. That's awesome. (In retrospect, I realize I should've realized it, because I've always known that the javascript links are "javascript:functionCall()" or some such.)

Other fun 'in' trivia: It looks through the object's entire prototype chain: http://yuiblog.com/blog/2006/09/26/for-in-intrigue/

Go post a comment on that answer to clarify it.

This is really scary. Hidden features??

Was this posted to show just how much misinformation and dumbing down there is at stackoverflow?

As if we need more misinformation about javascript on the net.

You know, it's kind of sad. Before reading the article, I was going to post a reply to your comment like "but omg, javascript has functions that are values!!1". Then I read the article, and found that that's the first "hidden feature".

I guess "hidden feature" means "something that's not in PHP".

I also like how people use terms like "null coalescing operator" when everyone else calls it "short circuiting". They are so smart!!11!

The "Hidden features of PHP" section is pretty damn funny actually, but not in a good way. I can summarise it for you if you're lazy:

  "ZOMG - PHP has arrays! Arrays are like, super cool!"

short circuiting is only half of why this example works. The other half is that boolean operators in javascript don't implicitly cast the result as a boolean type.

What's sad is that the Mozilla wiki has all the info on the features of JavaScript from version 1.5 to 1.8 (which Rhino doesn't support but Firefox3 does? something like that). Oh and there's also the possibility of, you know, reading the language spec. /me sighs

I hang out a bit in #javascript on freenode and it's always surprising how many people come in with a "guesswork" attitude to programming.

They just think up how they expect something should work, or what they think something should be called, and try it. Then come in and ask why it's not working. They often exchange misinformation with each other without either party realizing it's false.

Then if you suggest to them they read up on the API for what they're trying to do, they won't... they'll just keep trying random things, trying to get someone to feed them the answer.

I think javascript is particularly bad for this, even though there are some really good books and references out there now.

Is this the usual way of figuring something out in other contexts? It sounds like the "trying to get my WiFi to work" crowd is doing Javascript. Those folks wouldn't know what to do with a language spec, nor have ever entertained the concept of a universe that works like that. ("You mean there's something that explains precisely what everything in Javascript does?")

I think that a lot of people from other walks of life somehow end up working on HTML projects learn that in order to make their mouseover menus work they need something called JavaScript, so they search for cut and paste something that someone says is what they want and then start hunting for someone to get them over the hump to make it work.

This is not meant to disparage people like web designers who come at things from an artistic angle, but a lot of people who write Javascript are doing it in a tertiary role -- in support of HTML in support of producing a visual design that they envision. That these people don't have a solid foundation in programming shouldn't be alarming or disconcerting.

Ten years ago Javascript had a reputation of being a crap/toy language, largely for this reason. It really wasn't until GMail, IMO, when people started saying "Look, a JS app that doesn't suck!" and things kind of went forward from there.

I think that you might be confusing the attitude with the usual crowd. I personally apply the "guesswork" attitude whenever learning anything programming related - snipe a few packages which look right from the Ubuntu repositories, play around in the REPL, write a few toy programs. Then maybe after a few days, go read a few tutorials online and sometime later browse through the manual, but that is only later, after the initial 'guesswork'.

Either you're talking about something different, or I don't understand what's wrong with such an approach... Although maybe 'experimental' is a better title?

...correction: On rereading your post a few more times, I realize it's just a misconception of terminology.

To paraphrase Greenspun:

Any expert website is an ad hoc, ugly, slow implementation of Usenet featuring inferior comments.

FWIW, Usenet is a collection of posts answering the same questions again and again and again and again. Maybe tagging will help people find existing answers more quickly.

The good thing about Usenet is the barrier to entry. Stack Overflow has already shown that it's wayyyy too easy to get and account and start incorrectly answering questions.

To be fair, what is it you think the phrase "hidden feature" could possibly mean other than "frequently misunderstood" or "available, but often unused by beginners"?

Surely you weren't expecting "hidden" features in any literal sense?

> Surely you weren't expecting "hidden" features in any literal sense?

Personally, I expected something more hidden than core features of the language.

You know what's great about StackOverflow though...you can go fix it if you want. Go post a better answer, get upvoted, misinformation is minimized.

You assume the people there would be able to recognize a "better answer".

Just saying...

There are A LOT of really smart people there. They're outnumbered by the idiots, but they're there. More importantly though, a well thought out answer with explanations and references can be very convincing to even the biggest idiot.

> They're outnumbered by the idiots

So if your aim is to get upvoted, that's your target market. Better to sound right than to be right in that environment.

If you want to learn something new about JavaScript, just skim through Douglas Crockford's articles. As long as I've been doing JavaScript, I learn something new or rediscover something every single time: http://javascript.crockford.com/

Wow, the top answer really doesn't understand first class functions at all.

Yeah, that's a pretty bad example!

That may not be a particularly interesting example, but I don't think it's bad.

  var a = 5;
  var a = function() {
    alert('hello world');
  };
  var a = 2;

It's not a closure (which is what I assume you were hoping for), but it definitely reveals something pretty unexpected about the language for someone who has no experience with first class functions.

Yeah, that's also pretty bad. It doesn't show what you can do with the function.

Then go post a comment on that answer or post a better answer. If you prove his answer wrong, it can be edited. It's a wiki as much as it is a Q&A site.

I almost was inspired to, but it said something like comments require 50 points.

I also don't know what I'd write. As a programmer, I feel crippled without first-class functions, but I'm not sure I know how to distill them into a few choice lines. My first instinct was to use something like map, but I don't think JS has such functions built-in.

I found the whole "you can't do this, or that, or this other thing without points" kind of annoying.

I too found it annoying, but it still might be a good idea. Maintaining quality of content is a big deal. Obviously you'll lose some good posts, but in the end it might be worth it.

"answers" don't require 50 points. In fact I don't think answers even require login.

I have enough rep on the site to edit any question or answer. If you find something that's factually incorrect, post a comment on it, link it here and I'll edit it. Get off your high horses and help some people out.

High horse? I feel no impetus to participate in that community.

What I do find interesting is how it seems very much an extrapolation of Jeff Atwood's blog - much as HN, I suppose, is largely populated by people who are attracted to Paul Graham's essays. On the one hand, this is perfectly natural; on the other hand I find it fascinating.

Edit: I'm not saying that the people in these communities necessarily agree with the opinions of their founders.

I can understand covering the site itself, but posting links to the content? Did we run out of real Hacker News?

You could always try to find interesting content and post it: https://qht.co/submitted?id=kylec

This is a matter of taste, of course, as we don't have a good study of programming code comprehension yet, but I think the coolest part of JS are cond statements using the trinary operator:

    var foo = predicate  ? "one" :
              predicate2 ? "two" :
                           "default";

And short-circuit and/or:

    var foo = uncheckedFoo || "default";
    var wiz = (bar && bar(foo)) || "default";

Truthy values get in the way sometimes (especially 0), but it sure as hell beats a ton of if...else crud.

Worst part of JS, while we're at it:

    true == "0" == 0 == false

Here's another neat example of short-circuit or:

    function getFoo(f) {
        if (f) {
            if (foos[f]) {
                return foos[f];
            } else {
                return f;
            }
        } else {
            return "error";
        }
    }

Is (almost) the same as...

    function getFoo(f) {
        return foos[f] || f || "error";
    }

The difference in behavior being if foos[undefined] is set...

     true == "0" == 0 == false 

This is untrue.

    > true == "0"
    false
    > "0" == 0
    true
    > 0 == false
    true
    > true == "0" == 0 == false
    false

I think he meant something like this:

    true == !0 == "0" == false

Which still isn't that interesting, since it is much the same as:

    true == (false == false)

More interesting, something like:

    > ! 0 ==   "0"
    false
    >   0 == ! "0"
    true

Since "!" acts as if false === 0.