gistfile1.txt

proxies?

@visionmedia What makes the language better for your use cases (and aesthetic sense, which I must add I highly respect) isn't the same thing as what makes the language better for the popular and important use cases. You don't have to use getters or proxies if you don't want to, but I'm surprised that you cannot see why some other peoples' code would be improved by using them.

1. If magic get/set is the prevalent library abstraction you use, there's really no possible confusion about assignment semantics. Imagine most property assignments in your code being function calls instead; that's losing a lot of clarity without adding any knowledge. When working in a reactive environment, a magic get and a magic set are the normal behavior of every property assignment
2. That's not some niche use case. People are building stuff like reactive environments and data binding in JavaScript today, taking it to the places it has never been before, and we have no idea what will be popular tomorrow. We want to support that, rather than discourage that.
3. Most importantly, the argument you're making is essentially counter to the idea of writing code in terms of interfaces, not implementations. Sometimes the distinction between .name and .name() is an implementation detail that should be hidden to allow proper duck typing. Should a function called max really care if it's operating on a real array or a reactive array class? While it's possible to over-abstract things, the right amount of abstraction isn't always no abstraction.
4. Then there's an issue of being able to make changes. One day your person.name is just a property, the next day you want it to be reactive, so it has to become person.name(). Using different syntax to access immutable and mutable properties is crazy, you'd have to either always use person.get('name') just in case, or remember if name is mutable or immutable today. I'm all for refactoring and find-and-replace, but this particular trivial change feels like a stupid chore and gets annoying fast.
5. And there's evidence of existing demand and of people applying ugly workarounds. Isn't that the best indication that a language feature is desirable? (Honest question.)