HAHA! You'll pry JavaScript from my cold dead hands!
-Mikeal On Nov 2, 2011, at November 2, 201110:49 AM, Brendan Eich wrote: > On Nov 2, 2011, at 9:46 AM, Mikeal Rogers wrote: > >> I agree with every sentence in this post. >> >> +1K :) > > Switching to CoffeeScript? :-P > > /be > >> >> -Mikeal >> >> On Nov 2, 2011, at November 2, 20119:05 AM, Jeremy Ashkenas wrote: >> >>> On Wed, Nov 2, 2011 at 11:01 AM, David Bruant <bruan...@gmail.com> wrote: >>> Could you elaborate on this point? >>> All object-lockdown I can think (non-configurability, non-writability, >>> non-enumerability, private names, const variables, const classes) of is >>> optional. Why are you against them? >>> >>> I was about to say "if you're unsatisfied, create a language which doesn't >>> provide features you don't like, like Coffeescript", but... humm... >>> So, why being against the introduction of features in the language? >>> >>> I'd be glad to elaborate -- but since it's off topic for minimal classes, >>> changing the Subject here. >>> >>> What draws people to dynamic languages is freedom. >>> >>> And JavaScript is one of the *most* dynamic of the mainstream programming >>> languages. Not only can you can pass any object to any function, but you >>> can call a method with any number of arguments, easily modify the >>> prototypes of other objects, introspect on any object's properties with a >>> simple loop, replace any member function with a wrapped version, attach new >>> properties to any object ... the list goes on. >>> >>> If I had my druthers, JS.next would generally embrace the spirit of >>> JavaScript's dynamism (and freedom), and try to push those aspects further >>> -- with better introspection and more flexibility -- instead of >>> compromising with more restrictive static languages and adding lock-down >>> keywords so that some programmers might "feel safer". >>> >>> Let's set arguments about security and constraint guarantees aside for a >>> moment (although I'd be glad to have those as well), and talk about these >>> keywords as pure features: >>> >>> "private" does not add anything new to a property. If you don't want the >>> property to be used outside of the class ... don't use the property outside >>> of the class. >>> >>> "const" does not add anything new to a variable. If you don't want to >>> change the value of a variable ... don't change the value of the variable. >>> >>> "freeze" does not add anything new to an object. If you don't want to >>> change the shape of an object ... don't change the shape of the object. >>> >>> Note that Ruby, another very dynamic language, has "private" and constants. >>> And yet private methods can be called from the outside, with "send", and >>> contants can be explicitly overwritten with new values. They are simply red >>> tape, not concrete walls. For better or for worse, I have very rarely seen >>> a large-scale Ruby project that does *not* call a private method >>> externally, or overwrite a constant during configuration. >>> >>> The recent JavaScript renaissance that we're all enjoying owes debts to >>> JavaScript's foresight as a "free", dynamic language. If all of the >>> JavaScript core object had been frozen, locked down with private methods, >>> and set as const properties on the global object, libraries like >>> Prototype.js never would have happened. Libraries like jQuery would have >>> been much more difficult to imagine. We might not have the new Array#map, >>> #reduce, #every, or #filter methods at all. >>> >>> Can a free, dynamic language be abused? Certainly. Is Prototype.js >>> dangerous? For some websites, it can be (including NYTimes.com, where I >>> work). >>> >>> The freedom of having every object and every property be configurable, >>> settable, introspectable, readable and writable, at least at the language >>> level, is worth the trade off. If we add const, private, and other >>> lock-down syntax, or make class properties private by default (shudder), I >>> guarantee you that many potential innovative libraries that otherwise might >>> spring up will never even be conceived, and frustrating situations that >>> could have otherwise been solved by a quick patch will instead require >>> convoluted work-arounds. >>> >>> JavaScript should be about making it easier to write the right thing, and >>> not so much about making it harder to do the wrong thing. After all, the >>> former is purely positive, and the latter assumes that you know better than >>> the engineer who comes after you. In the real world, you often don't. >>> >>> Cheers, >>> Jeremy >>> >>> _______________________________________________ >>> es-discuss mailing list >>> es-discuss@mozilla.org >>> https://mail.mozilla.org/listinfo/es-discuss >> >> _______________________________________________ >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
