Hacker News new | ask | show | jobs
by mst 779 days ago
Block scoping has been -huge- for me.

ES6 'let' has very similar semantics to perl's 'my' and the absence of an equivalent elsewhere has always made me feel like I was missing a limb.

There's currently a proposal (which I think looks likely to succeed) to add a 'do BLOCK' syntax to ES6 as well, which is (now I get sane scoping) the top perl feature I miss All The Time when writing JS, and I can't wait.

(in the cases of both ruby and python the function scoping seems to be a deliberate choice rather than an omission and I just Do Not Understand how it doesn't bother people more)
1 comments
jonbeebe 779 days ago
I didn't know about the do BLOCK syntax that's (possibly) coming, that's interesting, thanks for bringing that up.

Regarding your last comment about Ruby and Python. I've been thinking about this for a while and I think a lot of the hate people have towards JavaScript is due to the fact that (being the only "official" web language) lots of people were forced to use it without any other choice, which adds a lot of resentment.

On the other hand, Ruby and Python are deliberate choices of which there are many options. People who choose to use it love it, and people who don't can move onto something else. It's not the same with JavaScript. If you want (or need) to do frontend development, you had to use JavaScript.

I observed this with Lua community in the past. I hardly ever see anything negative about it, but it has its own oddities (such as 1-based indexing, global by default variables) and is in a lot of ways similar to JavaScript being a prototype-based language (the only other one that I know of actually).

link
mst 778 days ago
I am honestly drooling for it,

    my $thing = do {
      my $intermediate_1 = foo(...);
      my $intermediate_2 = bar($intermediate_1, ...);
      baz($intermediate_2);
    };
type code is something I use quite a lot to be able to name the intermediates while keeping them from escaping into the containing scope. So

    let thing = do {
      let intermediate_1 = foo(...);
      let intermediate_2 = bar(intermediate_1, ...);
      baz(intermediate_2);
    };
is going to make me a very happy camper.

My other major irritation these days is that 'let' is a statement in JS, whereas 'my' is an expression in perl, and I'm very used to writing

    if (my $token = $user->admin_token) {
      ...
    }
and similar constructs. In JS currently I have to write

    let token;
    if (token = user.admin_token()) {
      ...
    }
(and wrap that entire construct in its own block if I don't want the 'token' variable to continue to exist afterwards, which generally I don't)

The javascript-viable version of that is probably to have a special cased 'if let' just like 'for let' was added already.

I'm unaware of a proposal for that - yet.

Though the 'match' proposal currently in flight IIRC assumes 'do BLOCK' is available, and that will probably give me something sufficient to stop grumbling about that one.

(learning lisp, then applying the same "lexically scope as tight as possible" aesthetic I developed there to my perl code, then trying to use ... pretty much anything else ... has been an irritating experience on occasion ;)

link