A re-introduction to JavaScript • Hacker News Board

Re: A re-introduction to JavaScript

#71

Post by pluma » Sat, May 09, 2015, 7:08 PM UTC

serve_yay wrote: post #23

kremlin wrote: post #18

The article mentions an idiom for iterating over an array. It says 'an even nicer idiom is...' and then it shows it. I just wanted to say that the behaviour of this 'nicer' idiom may not be what's expected - it stops iterating once it hits the first falsy value. I was quite excited actually when I first saw them idiom, until I quickly realized its limitations

Oh jeez, I just saw that the section you're referring to repeats the old canard about caching the length of an array when iterating over it. Come on, that can't still be good advice. It always struck me as ridiculous to begin with, but almost certainly now it's optimized away. Not to mention the suggestion you're talking about, which I bet would bite programmers for the reason you mention. Seems like a bad idiom, I'v…

I think nearly every JS engine now optimizes `for (...;i In fact, even `for` is likely an over-optimization. In nearly all JS code you can get away with just using `forEach` (or its friends).

Re: A re-introduction to JavaScript

#72

Post by pluma » Sat, May 09, 2015, 7:13 PM UTC

csandreasen wrote: post #9

sergiotapia wrote: post #5

Earlier quoted context omitted.

I think 99% of the problems people have with Javascript are not actually types, but `this`. It's the most confusing part about Javascript. This context, var foo scope, what? Why is this value not updating? undefined? What???

I actually found the Javascript 'this' keyword more understandable after working with Python. >>> class foo(): ... def test(this, x): ... print this, x ... >>> x = foo() >>> x >>> x.test(1) 1 >>> y = foo.test >>> y(1) Traceback (most recent call last): File " ", line 1, in TypeError: unbound method test() must be called with foo instance as first argument (got int instance instead) >>> y(x,1) 1 In Python, the referen…

I came (back) to JS after doing a lot of Python and I think that may have helped understanding `this` in JS.

Note that the behaviour of `this` defaulting to `window` (or `global`) is only the legacy behaviour. You should be using strict mode (there's really no justification not to -- except for extremely rare edge cases, e.g. having to delete global variables without having a reliable reference to the global object other than `this`).

In strict mode, `this` would be undefined. As expected, if you consider `x.y()` syntactic sugar for `x.y.call(x)` (and therefore `z()` syntactic sugar for `z.call(undefined)`).

Under the hood, invoking a function translates to a call of the functions `[[Call]]` method, which takes an explicit `this` just like `Function.prototype.call` does.

Re: A re-introduction to JavaScript

#73

Post by jaredsohn » Sat, May 09, 2015, 7:24 PM UTC

serve_yay wrote: post #23

kremlin wrote: post #18

The article mentions an idiom for iterating over an array. It says 'an even nicer idiom is...' and then it shows it. I just wanted to say that the behaviour of this 'nicer' idiom may not be what's expected - it stops iterating once it hits the first falsy value. I was quite excited actually when I first saw them idiom, until I quickly realized its limitations

Oh jeez, I just saw that the section you're referring to repeats the old canard about caching the length of an array when iterating over it. Come on, that can't still be good advice. It always struck me as ridiculous to begin with, but almost certainly now it's optimized away. Not to mention the suggestion you're talking about, which I bet would bite programmers for the reason you mention. Seems like a bad idiom, I'v…

>old canard about caching the length of an array when iterating over it

I think there are still places where you need to do this (please correct me if wrong, or mention some other cases):

- when iterating over DOM nodelists in JS (why doesn't the browser cache this as well?)

- if using strlen in C/C++ (for the latter, you should use string.length() instead).

Re: A re-introduction to JavaScript

#74

Post by CrystalGamma » Sat, May 09, 2015, 7:50 PM UTC

Touche wrote: post #45

xtrumanx wrote: post #43

Earlier quoted context omitted.

Can you expand on what you said about the `delete` keyword implications with the GC? I've never heard of that issue.

I haven't either, only that delete will cause code to be de-optimized.

Its main purpose is deleting a property from an object, which is a pretty slow operation on modern JS engines. Unless some code tests for the existence of a property, setting it to null is a better idea.

Re: A re-introduction to JavaScript

#75

Post by [deleted] » Sat, May 09, 2015, 7:54 PM UTC

z3t4 wrote: post #60

I think it's much easier to forget about "types" and think of objects instead. Trying to divide JavaScript objects into "types" will surely get you frustrated. If you absolutely want to check what "type" an object is, for example a sanity check for arguments passed to a function, you should make your own isMyType(obj) function and not rely on typeof or toString.

[deleted]

Re: A re-introduction to JavaScript

#76

Post by magicalist » Sat, May 09, 2015, 8:14 PM UTC

bionsuba wrote: post #49

ahoge wrote: post #26

Earlier quoted context omitted.

That's from IEEE 754 (a standard for floating-point arithmetic). `NaN` and -0 exist for the same reason.

To be fair, just because something is a standard doesn't mean it isn't a dumb implementation. Just by testing the programming languages on my computer, I can tell you that Python, C, and D all throw errors rather than allow it, which is the smart thing to do.

> I can tell you that Python, C, and D all throw errors rather than allow it

Python throws an error, but numpy.divide(1., 0) will work just fine (and return inf).

I'm not sure why you're saying C throws an error. The behavior of dividing by 0 is undefined by default, but on most machines these days the hardware implements IEE-754 and the C implementation will advertise as implementing IEC 60559, so 1. / 0 will give you inf as well.

Re: A re-introduction to JavaScript

#77

Post by [deleted] » Sat, May 09, 2015, 8:15 PM UTC

bionsuba wrote: post #49

ahoge wrote: post #26

Earlier quoted context omitted.

That's from IEEE 754 (a standard for floating-point arithmetic). `NaN` and -0 exist for the same reason.

To be fair, just because something is a standard doesn't mean it isn't a dumb implementation. Just by testing the programming languages on my computer, I can tell you that Python, C, and D all throw errors rather than allow it, which is the smart thing to do.

[deleted]

Re: A re-introduction to JavaScript

#78

Post by lewisl9029 » Sat, May 09, 2015, 8:18 PM UTC

sergiotapia wrote: post #5

serve_yay wrote: post #4

Very nice to see it starts off with a (correct) discussion of JS types! JS devs mostly don't know the actual types in JS, which is pretty crazy if you think about it.

I think 99% of the problems people have with Javascript are not actually types, but `this`. It's the most confusing part about Javascript. This context, var foo scope, what? Why is this value not updating? undefined? What???

Using jspm, SystemJS and Babel for my latest project, and simply using let universally over var and arrow functions over anonymous functions has made this aspect of JavaScript behave like any sane language would.

I simply don't ever need to think about it anymore.

Re: A re-introduction to JavaScript

#79

Post by ougawouga » Sat, May 09, 2015, 8:37 PM UTC

eddyb wrote: post #39

bluesnowmonkey wrote: post #35

Earlier quoted context omitted.

Another way to cast to a Number is the bitwise-or operator. It has the useful property of always yielding a number. '42' | 0; // 42 NaN | 0; // 0 null | 0; // 0 undefined | 0; // 0 false | 0; // 0 true | 0; // 1

Bitwise operations don't produce Numbers (f64), but signed integers (i32).

> produce...signed integers

Well, except for right logical shifts.

Re: A re-introduction to JavaScript

#80

Post by chris_wot » Sat, May 09, 2015, 8:52 PM UTC

chris_wot wrote: post #57

sergiotapia wrote: post #29

Earlier quoted context omitted.

Looking at you Ember. Ugh! var controller = this; Every time!

They have to. There's a bug in the JavaScript spec that makes you do this :-) they are perfectly correct in doing what they are doing, if they didn't then funny thing would start to happen. Sad, but true.

Uh, what's the reason for the downvote?