Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Making the Most of the JavaScript Language (2016)

thenorthcode.net

Post reply on HN
Print view View original

41–47 of 47 posts

Re: Making the Most of the JavaScript Language (2016)

#41

Post by geoelectric »

erikpukinskis wrote: post #23
geoelectric wrote: post #22

Earlier quoted context omitted.

The big deal of an arrow function, brevity aside, is that it inherits the value of 'this' from the scope that creates it. Regular functions do not, so to use them as first-class functions you often have to bind before passing, pass around thisObjs for rebinding, do a 'that = this' type trick, etc. Same goes for 'arguments', though that comes up less. Basically, they're much more representative of a simple lambda than…

What's wrong with explicitly binding the scope? I really like that in JavaScript you have to be explicit about that kind of thing.

I actually find it much more clear for this to be set at the place you see the function defined in code--assuming you know what this is in the wrapping scope, you know exactly what it will be in this scope. Technically a bind is more explicit but in practice the bind tends not to happen where the function is defined so you have to go fishing around the code path for it.

And honestly, the sugar often speaks to readability as well. Compare myArray.every(function (x) { return x; }); with myArray.every(x => x).

Re: Making the Most of the JavaScript Language (2016)

#42

Post by erikpukinskis »

geoelectric wrote: post #41
erikpukinskis wrote: post #23

Earlier quoted context omitted.

What's wrong with explicitly binding the scope? I really like that in JavaScript you have to be explicit about that kind of thing.

I actually find it much more clear for this to be set at the place you see the function defined in code--assuming you know what this is in the wrapping scope, you know exactly what it will be in this scope. Technically a bind is more explicit but in practice the bind tends not to happen where the function is defined so you have to go fishing around the code path for it. And honestly, the sugar often speaks to readabi…

The first is more readable. It uses more common tokens, and is therefore more easily recognizable. You're confusing brevity for readability.

I don't understand your scope preference. These seem the same to me:

  family.findEldestFirst(person => this.isRoyal() && person.name == "Kate")
vs

  family.findEldestFirst(isPrincess.bind(family))

  function isPrincess(person) {
    return this.isRoyal() && person.name == "Kate"
  }
11 tokens vs 16, same order of magnitude. Second one has an explicit return, which is good for readability. Shorter lines, to which is better for readability. Also relies on fewer control structures, which is good for readability. No need to understand the =>/-> distinction, which is very subtle and beginners won't know about it. To me I'd rather just learn functions and closures and be done with it.

... And frankly I think using "this" that way in either case is not a win. I'd rather make family its own argument to isPrincess:

  family.findEldestFirst(isPrincess.bind(null, family))

  function isPrincess(family, person) {
    return family.isRoyal() && person.name == "Kate"
  }
Mm. Dat explicitness. Anyway... I think I'm not understanding you. How is this forcing your hand in terms of where you bind the scope?

Franky, my sense is that the people who like ES6 and promises are people who are just allergic to writing named functions. Named functions make callback hell go away, and they solve all the problems these arrow functions do. Somehow people think it's bad form to define lots of functions. But defining functions is my job. :) It doesn't bother me.

My sense is it's just Rubyists who miss Ruby and think "more Rubyish" is better. I sympathize because my path was BASIC -> PHP -> C# -> Ruby -> JavaScript. But I think it is a mistake to try to bring your old idioms to a new language.

... and if I wanted to reduce character count above all else, I'd just go use PERL.

Re: Making the Most of the JavaScript Language (2016)

#43

Post by kazinator »

WorldMaker wrote: post #40
aaron-lebo wrote: post #15

Earlier quoted context omitted.

It's an incredibly verbose way to do what you'd prefer to be the default. val or con would have been better.

Going way back to ancient Lisps `let` has been the const declaration in a lot of programming languages. It's too bad ES2015 decided to use `let` for `var`/`val`, because `let` should have been const. That said, I've come to terms with const, even if I find I accidentally use let sometimes from time spent in Lisp and F#.

let is not a "const declaration" in most major dialects of Lisp, current and historic. In Scheme, Common Lisp, ISLisp, Emacs Lisp and others, it introduces mutable bindings.

Re: Making the Most of the JavaScript Language (2016)

#44

Post by kazinator »

simonbw wrote: post #18
aaron-lebo wrote: post #15

Earlier quoted context omitted.

It's an incredibly verbose way to do what you'd prefer to be the default. val or con would have been better.

Is there really much of a difference between "const" and "con"? I get that one is 66% longer than the other, but does it actually affect the readability of the code or the amount of time it takes to write it?

Can't we compromise half way? How about cons!

/whistle .../

Re: Making the Most of the JavaScript Language (2016)

#45

Post by Guthur »

mercer wrote: post #33
Guthur wrote: post #30

Earlier quoted context omitted.

The true source of your problems there are mutation, which in my opinion is the primary source of issues. Immutable data structures being the most benefit. I also believe dynamic language tooling has regressed.

> I also believe dynamic language tooling has regressed. I'd truthfully love to hear more about that. Care to elaborate?

I've worked with common lisp, clojure, python and javascript, and common lisp debuggers are just hands down better in everyway. Check this series for what should be a basic debugging experience by now http://malisper.me/debugging-lisp-part-1-recompilation/

Re: Making the Most of the JavaScript Language (2016)

#46

Post by whatever_dude »

goatlover wrote: post #8
whatever_dude wrote: post #3

What I can't recommend enough (and hinted at in the article) is for someone to use a transpiler like Babel (and core-js, babel-preset-env, and etc). There's no reason not to use many of the new features and new functions of ES2015+, and you can do that right now even if you're targeting old browsers with transpilation and a bit of automatic shimming.

How does debugging in the browser console work when you use that approach?

Like everyone said it works perfectly well with source maps. You get proper debug errors, break points, etc.

That said, it is another thing you need to maintaining and depending on the number of transformations your code has to go through, you introduce more points where the source map can break.

Re: Making the Most of the JavaScript Language (2016)

#47

Post by WorldMaker »

kazinator wrote: post #43
WorldMaker wrote: post #40

Earlier quoted context omitted.

Going way back to ancient Lisps `let` has been the const declaration in a lot of programming languages. It's too bad ES2015 decided to use `let` for `var`/`val`, because `let` should have been const. That said, I've come to terms with const, even if I find I accidentally use let sometimes from time spent in Lisp and F#.

let is not a "const declaration" in most major dialects of Lisp, current and historic. In Scheme, Common Lisp, ISLisp, Emacs Lisp and others, it introduces mutable bindings.

Apologies, my Common Lisp is getting rusty.
Post reply on HN