The Future of JavaScript • Hacker News Board

Re: The Future of JavaScript

#21

Post by grannyg00se » Fri, Feb 10, 2012, 7:17 PM UTC

jashkenas wrote: post #6

Lewisham wrote: post #5

Earlier quoted context omitted.

I've only delved into really writing JS for the last couple of weeks, but a number of tutorials basically said that objects are dictionaries and vice versa, you just got some nice syntax and you can plug function in as values. If that was an abuse, what are JavaScript objects supposed to be? What's the difference between them and a dictionary?

It's only an abuse because JavaScript has no distinction between the notion of an object's "meta" properties, and its dictionary-like keys and values. So you'll get along just fine, until someone tries to write this: var dict = {}; dict["hasOwnProperty"] = true; dict["toString"] = "Bob"; dict["valueOf"] = 7; ... then you're in for a rough time.

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.

Re: The Future of JavaScript

#22

Post by grannyg00se » Fri, Feb 10, 2012, 7:22 PM UTC

mbrubeck wrote: post #7

jashkenas wrote: post #6

Earlier quoted context omitted.

It's only an abuse because JavaScript has no distinction between the notion of an object's "meta" properties, and its dictionary-like keys and values. So you'll get along just fine, until someone tries to write this: var dict = {}; dict["hasOwnProperty"] = true; dict["toString"] = "Bob"; dict["valueOf"] = 7; ... then you're in for a rough time.

Another problem with objects-as-dictionaries is that the keys must be strings. If you use a different type as a key, it is implicitly converted to a string, which can lead to some surprising problems for programmers who don't expect it. Maps/Set/WeakMap properly support arbitrary objects as keys.

Again, this is something that is simple to learn and understand. And you would learn this in a beginner tutorial. Why go through trouble to change it and complicate the language even further? I undeerstand weakmap may have some real advantage as far as GC, at least.

Re: The Future of JavaScript

#23

Post by haberman » Fri, Feb 10, 2012, 7:26 PM UTC

> The ECMA committee is working hard on designing

"Committee" and "designing" in the same sentence gives me the shivers.

But the features they're describing actually sound pretty reasonable. Actually a lot of them seem to already exist in Lua ("proxies" sound like what are provided by Lua's metatables, and Lua already has weak tables and lexical scoping).

Re: The Future of JavaScript

#24

Post by haberman » Fri, Feb 10, 2012, 7:27 PM UTC

grannyg00se wrote: post #21

jashkenas wrote: post #6

Earlier quoted context omitted.

It's only an abuse because JavaScript has no distinction between the notion of an object's "meta" properties, and its dictionary-like keys and values. So you'll get along just fine, until someone tries to write this: var dict = {}; dict["hasOwnProperty"] = true; dict["toString"] = "Bob"; dict["valueOf"] = 7; ... then you're in for a rough time.

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".

Re: The Future of JavaScript

#25

Post by grannyg00se » Fri, Feb 10, 2012, 7:29 PM UTC

"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.

Re: The Future of JavaScript

#26

Post by aledalgrande » Fri, Feb 10, 2012, 7:37 PM UTC

As long as this doesn't become another difference between browsers (= headache).

Re: The Future of JavaScript

#27

Post by winteriscomming » Fri, Feb 10, 2012, 7:51 PM UTC

Is it really not out for 2 years? Really? That seems like a long time for not that much changes. Any improvement is welcome, but still. I don't know if this will keep pace with Dart and other options. It seems way too slow.

Re: The Future of JavaScript

#28

Post by rlf » Fri, Feb 10, 2012, 7:53 PM UTC

For the love of God, make it more like Ruby. Learning JavaScript after having worked with Ruby is like driving a horse and buggy after you've driven a Ferrari.

Re: The Future of JavaScript

#29

Post by agscala » Fri, Feb 10, 2012, 7:54 PM UTC

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.

The extra keywords aren't going to reduce the "errors and weird behavior", the fact that they will be block-scoped and not function-scoped is what will eliminate the confusion.

Re: The Future of JavaScript

#30

Post by geuis » Fri, Feb 10, 2012, 7:58 PM UTC

I'm probably alone in saying this, but I hope most of this stuff never sees the light of day.

What makes JS powerful is its simplicity. "var" or no "var" gets you local or global scope. Done. Want a constant? Make a global variable and don't change it. Want to really make sure its unchangeable? Make an accessor function.

Scope in JS is very simple to understand and quite versatile once understood. Adding more layers of complexity does not help.

One of the strengths of js is that every thing is an object(almost). So the bit about "no more need to abuse objects as dictionaries" is a bit odd. Since most things are objects, you get the power to treat functions, types, literals, etc in interesting ways.

One of the strengths of object literals is that you can use them as dictionaries. obj.foo === obj['foo'].

I love getters/setters and some other improvements like strict mode. However I am very much against what seems like an unnecessary cluttering of the language without fixing some of the long standing problems like ==/===. For me, I almost never use == so it should be gotten rid of. Make == === === for example.