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

The Future of JavaScript

blog.chromium.org

Post reply on HN
Print view View original

51–60 of 115 posts

Re: The Future of JavaScript

#51

Post by btilly »

haberman wrote: post #24
grannyg00se wrote: post #21

Earlier quoted context omitted.

Byt anyone with even a basic tutorial understanding of the language wouldn't do that. Is it really necessary to try and make it absolutely impossible to get unexpected results? The downside is even more complexity and uncertainty. Now you have to know the old way, the new way, and the idiosynchracies of both.

You might not write: dict["valueOf"] since that's obviously a bad idea, but you might write: dict[user_provided_string] Since user_provided_string could be anything, you are susceptible to unexpected behavior if the string ends up being "valueOf".

But instead if you write:

  dict[ "_" + user_provided_string ]
then nothing can ever go wrong. This does have an annoyance around the leading underscores. But you can get around that by adding simple accessor methods. And now you have a real dictionary.

But native dictionaries have the ability to store complex objects as keys. This is kind of nice. However they are likely to create traps like making these 2 different:

   my_dict[5], my_dict['5']

Re: The Future of JavaScript

#52

Post by chc »

thaumaturgy wrote: post #44
ireadzalot wrote: post #34

Earlier quoted context omitted.

In my experience, the charm of simplicity of JS starts fading away when you start moving away from DOM manipulation and start writing complex objects. Just last week I ran into the lexical scoping issue ( I was not aware of it before) that had me scratching my head for hours. Scoping in JS becomes less fun the deeper you start digging. I am glad that they are aware of it and are actively trying to address it.

I agree with geuis, and I've written a personal-use JS framework that's in the same ballpark as jquery. I've run into the lexical scoping issue, but not for a long time. Straightforward naming conventions and Firebug can track down scoping problems really quickly. I'm not really opposed to the changes to JS that are mentioned on the Chromium blog, but mostly because I don't have to use them. I don't really see the po…

I very rarely have problems with JavaScript scoping or any of those obvious gotchas, but I still don't agree that they are good. We've just become acclimated to the language's eccentricities, the same way people living in Arizona for a long time think California summers are chilly.

It is true that JavaScript's scoping rules are pretty simple, but less is not always more. Once you have learned all the patterns and gotchas, JavaScript's scoping is quite usable. But the fact that you have to use patterns where you wouldn't in another language means JavaScript is making work for you. If JavaScript had Lispy macros or some other way of altering the language, I might be more inclined to agree that the fundamental simplicity is a good thing, but without that power, the simplicity means that when you're doing complex things, the complexity missing from the language has to be written out explicitly in your code. Right now a lot of JavaScript code is a mix of function pasta and things that should be function pasta but the coder couldn't be bothered.

Re: The Future of JavaScript

#53

Post by jashkenas »

herge wrote: post #47
tikhonj wrote: post #38

Earlier quoted context omitted.

There is a foreach that works: .forEach(). And when you're not just iterating over an array but transforming it, you have map(), reduce() and filter().

Is it really too much to ask to have some syntactic sugar. Is for i,v in blah , where i is an index of an array, or a key (not a property!) of a dictionary really too much to ask in 2012? No wonder people are using coffeescript.

CoffeeScript's got you covered. Here's forEach ...

    for item, index in list
... here's the same over an object ...

    for key, value of object
... here's the map() ...

    mapped = for item in list
... here's the filter() ...

    filtered = for item in list when item.isActive
... and so on.

Re: The Future of JavaScript

#54

Post by grannyg00se »

elehack wrote: post #46
grannyg00se wrote: post #25

"Now "let" is the new "var" – traditional "var" declarations are complemented with "let" and "const". Both are properly block-scoped bindings, eliminating a common source of errors and weird behaviour." Somehow going from one keyword for variable declaration to three doesn't seem like a good way to reduce errors.

JavaScript's 'var' behavior is a bug codified in specification. It is counter to pretty much any other C-style language; the difference is particularly acute because it breaks closures. So while other languages (e.g. C) could optimize their variable implementation to be like JavaScript's and still make sense, the fact that JS has closures means this breakage becomes visible on a routine basis. However, they cannot ch…

If var is counter to other C-style languages, that doesn't make it a bug. It just makes it unique. Is there some other reason you're saying it is a bug? How does it break closures? Javascript works with var today and closures are used all the time. Breakage free.

"what do you mean, braces don't actually delimit scope?" I would answer, they don't. Because this is not . This is javascript. Nobody should have ever told you that braces delimit scope here.

It's not like this is some extremely rare issue that you aren't going to find documentation for. A quick run through a basic tutorial would suffice.

So how is it that 'let' works the way variables should? It works differently, that's all. So now you have to know how let is different from var, why it was introduced, when to use let, when to use var, etc.

Then when you see code using let, you're going to have to determine whether the person used it because they know what they are doing, or because someone just told them "let is the new var" and they use it all the time. Same for var. There is an added level of uncertainty when reading code. And and added level of complexity in explaining the language. You haven't gotten away from explaining how var works. Because you're still going to see tons of code using it.

Wouldn't it be easier to just learn how to use var properly?

Re: The Future of JavaScript

#55

Post by grannyg00se »

wingo wrote: post #50
ams6110 wrote: post #32

Earlier quoted context omitted.

I agree with geuis above, JavaScript scope is simple to understand now. There is global scope, and there is function scope. That's it. And there's a certain elegance to that.

There are more scopes than that: free variables versus locals; eval-introduced bindings; "with"; the exception identifier in "catch"; the function name in named function expressions; argument names; etc. And the scoping rules are quite tricky in practice, to real programmers. To take an example from today: https://bugs.webkit.org/show_bug.cgi?id=27226#c4

Looking at that example, I would ask ....where exactly is that function definition getting defined? Why would you put a function definition inside a catch block? Do you think it's getting defined when the catch block is called? Are you programming in Javascript, or are you just writing javascript the way you would write code in some other language?

Re: The Future of JavaScript

#57

Post by ootachi »

btilly wrote: post #51
haberman wrote: post #24

Earlier quoted context omitted.

You might not write: dict["valueOf"] since that's obviously a bad idea, but you might write: dict[user_provided_string] Since user_provided_string could be anything, you are susceptible to unexpected behavior if the string ends up being "valueOf".

But instead if you write: dict[ "_" + user_provided_string ] then nothing can ever go wrong. This does have an annoyance around the leading underscores. But you can get around that by adding simple accessor methods. And now you have a real dictionary. But native dictionaries have the ability to store complex objects as keys. This is kind of nice. However they are likely to create traps like making these 2 different:…

"then nothing can ever go wrong."

What about the key "_proto__" (forming "__proto__") [1]? That will screw up your dictionary badly.

It's not so easy. Which is why you want Harmony Maps and Sets in the first place.

[1]: https://developer.mozilla.org/en/JavaScript/Reference/Global...

Re: The Future of JavaScript

#58

Post by silentOpen »

grannyg00se wrote: post #54
elehack wrote: post #46

Earlier quoted context omitted.

JavaScript's 'var' behavior is a bug codified in specification. It is counter to pretty much any other C-style language; the difference is particularly acute because it breaks closures. So while other languages (e.g. C) could optimize their variable implementation to be like JavaScript's and still make sense, the fact that JS has closures means this breakage becomes visible on a routine basis. However, they cannot ch…

If var is counter to other C-style languages, that doesn't make it a bug. It just makes it unique. Is there some other reason you're saying it is a bug? How does it break closures? Javascript works with var today and closures are used all the time. Breakage free. "what do you mean, braces don't actually delimit scope?" I would answer, they don't. Because this is not . This is javascript. Nobody should have ever told…

I don't want leg braces! Wouldn't it be easier to just learn how to use a wheelchair properly?

Re: The Future of JavaScript

#59

Post by zoips »

wslh wrote: post #37

Futures like in node-fibers? https://github.com/laverdet/node-fibers I think it is the proper way to complement generators and give the alternative to wait for a function value.

I don't think there's a reason to bake futures/promises into the language. Once you've got coroutines (generators here), people can build the abstractions around them that they like.

Re: The Future of JavaScript

#60

Post by btilly »

ootachi wrote: post #57
btilly wrote: post #51

Earlier quoted context omitted.

But instead if you write: dict[ "_" + user_provided_string ] then nothing can ever go wrong. This does have an annoyance around the leading underscores. But you can get around that by adding simple accessor methods. And now you have a real dictionary. But native dictionaries have the ability to store complex objects as keys. This is kind of nice. However they are likely to create traps like making these 2 different:…

"then nothing can ever go wrong." What about the key "_proto__" (forming "__proto__") [1]? That will screw up your dictionary badly. It's not so easy. Which is why you want Harmony Maps and Sets in the first place. [1]: https://developer.mozilla.org/en/JavaScript/Reference/Global...

Good point. I shouldn't have tossed that off of the top of my head, particularly since I'm not a JavaScript programmer. But the principle is right, you just need a different starting key than "_" to avoid conflict. Something like, "dict_" should work. And hide the details behind accessors. So if that breaks in a future version of JavaScript, it is easy to change it again.
Post reply on HN