Hacker News Reader

Comment by seubert | Hacker News Reader

It's even tagged "bad-theory." I think it's pretty clearly a joke! A really good one!

"And we can’t forget our favorite JavaScript interview question of all time: If you only had twenty-four hours to implement arrays in JavaScript, how would you do it?"

I'm not really versed on JavaScript. I presume this is a joke about the lack of a proper array structure in JavaScript? How would one answer this question anyway?

This is probably intended to be a joke about how Javascript was originally developed over about 10 days, which has been the root of many of JS's problems.

http://www.computer.org/csdl/mags/co/2012/02/mco2012020007.p...

But this heritage produced, years later, a great presentation about the evolution of JavaScript... that was best viewed without JavaScript.

While it's probably joke, JavaScript's Array is fine (although it's more like a 'vector'). JavaScript VMs implement it as a real array (in fact, plain objects are often optimized into arrays too).

Aren't they just objects that have integer properties; that's why you can

    for (k in ['a', 'b']) {
      console.log(k);
    }

and get back 0, 1? However:

    var a = {0:'a', 1:'b'};
    for (k in a) {
      console.log(k);
    }

also outputs 0, 1.

Edit: turns out, you can even have doubles, too:

    var weird = {3.14:'hello', 6.28:'world'};
    // for loop above emits: 3.14, 6.28
    console.log(weird[3.14]); // emits 'hello'

JavaScript objects can only have string keys (this may have changed in ES2015 with Symbols). If you pass a non-string value in an object literal or inside a []-accessor, that value is converted to a string.

> Edit: turns out, you can even have doubles, too:

That's because Javascript doesn't actually have integers, it just has "Number":

> The Number type has exactly 18437736874454810627 (that is, 264−253+3) values, representing the double-precision 64-bit format IEEE 754 values as specified in the IEEE Standard for Binary Floating-Point Arithmetic

http://www.ecma-international.org/ecma-262/5.1/#sec-8.5

I think I came around to that realization when he starts comparing Postgres to HTML tables.

sounds reasonable. normalization vs denormalization

ok, the last paragraphs kind of give it away... but there are good points in terms of keeping the data flat

Reply on news.ycombinator.com