I think Claus summarizes nicely what I've been thinking about this thread, and the opposition-for-the-sake-of-opposition that has been spreading through the JavaScript community. Though most of that seems to be based on "JavaScript should be kept simple." I'd argue there doesn't need to be conflicts between expressivity and simplicity. Remember, your concepts of expressivity might not be the same as my concepts of expressivity, just as the way you approach a certain problem might not be the same as the way person B and C approach a certain problem.
And given that the methods to solve a problem doesn't immediately qualify something as "bad" or "wrong", if we can reach a common ground on what group A needs for expressing their ideas, and what group B needs for expressing their ideas, why shouldn't we? It's only a problem if said features clearly reduce the expressivity of the language for a certain group of users considerably (and that's when you should say it does, so people working in the language can do better iterations on the particular feature design), and I don't see it as being the case for const, private or frozen objects, tbh. JavaScript is a huge language, it's used by several people, and used to solve several kinds of problems. Different problems need different features, they need better syntax too -- that's why DSLs are lovely, and why people keep creating them even though you could just as well write everything in C. So, if instead of making a language "one-size-fits-all" that's geared towards solving only a particular problem well, if we can give people different flavours of the language by features that don't conflict, or don't make the language a pain to everyone else, I think that's something worth seeking. Of course, we can't please everyone -- and I'm not saying we should, -- after all, languages are inherently biased. But that doesn't mean we can't give people better tools for solving new problems. Isn't that what programming is all about, anyways? :3 2011/11/3 Claus Reinke <claus.rei...@talk21.com> > I'm not just talking about implementors, either. Some users will want to >>> know d.m isn't going to change. They may not want to know that it's b.m, >>> mind you -- they simply won't want that c.m assignment to be legal, or else >>> if they do support such a thing, they don't want it to affect d's "vtable". >>> >> >> I would argue that developers who rely on these kinds of assurances are >> actually slowing down their own, and others, productivity. Assuming they >> wrote the perfect method and it should never be changed is a grand claim >> for anyone who isn't Donald Knuth. Assuming that the consumer of their code >> is responsible for their own bugs if they introduce them with monkey >> patching class methods seems fair. >> > > Ok, I have to wade in here: if you cannot see why some people > want such features, why are you arguing against these features? > > [the "you" here is not (exclusively) about you, but about a pattern often > exhibited by vocal and repeated opposition to things:-)] > > The Javascript user base is huge, with obviously different views, > and this doesn't seem to be your discussion to have, does it? > > You could try to argue that warnings are better to have than > errors in Javascript, eg, it should be easy to spot if someone is > interfering with your code's base assumptions, but you don't > want that to stop you from running that code anyway, knowing > that doing so might be unsafe. > > Example: the switch from warnings to errors for non-essential > features of JSLint meant that many JS coders can no longer > use JSLint, so the switch actually reduced its effectiveness. > > So, if a proposed feature interferes with your use of the language, > state that interference, and perhaps the proposals can be changed > to accommodate your concerns. That is a discussion based on > technical issues, which can make progress and can achieve targets. > > However, you might consider how your personal perspective > affects your judgement: > > - if you're developing node, you're at the start of the chain, > no-one can interfere with your definitions > - if you're developing node libraries, you have to keep up > with node only, but you have to do that anyway > - if you're using libraries from a single source only, you're > still not likely to be affected, because those libraries are > either consistent or have a bug that needs fixing > > - if you're using libraries from several sources, you're suddenly open > to a lot of trouble, as any library from > source A might interfere with base assumptions made > by any library from source B > > - if you're browsing the web, where many pages include > code from dozens of sources, you're out of luck quickly > if you cannot see what is conflicting with what > - if you're in the business of trying to ensure that web users won't > run into trouble, you want to pin down > what each page widget and ad module is allowed to > do (whitelisting); and if you take that to its conclusion, > you need to base your whitelisting in the language > > I could go on about how types can be a tool, not an obstacle, > if zealotry can be avoided, or about how many (most?) people who are > well-known for doing reflective language features (the stuff "dynamic" fans > like most about JS) have expressed the opinion (later in life, based on > experience with their > systems) that reflective and normal use should be separated > as clearly as possible. > But I really just wanted to say: don't argue against features > you do not need, argue for features (or changes of features) > you do need. > If a feature you do not need interferes with something you do need, that > is a bug in the feature that should be pinned down and addressed > (dismissing the whole feature won't help, unless the problem is unavoidably > tied to the feature). > If a feature you do not care about takes resources you would like to see > spent on something you do care about, that may be a bug in the process that > Just another opinion from another JS coder. > > Btw, some message to es-discuss are still missing, and > es-discuss-owner has not replied. > > Claus > http://clausreinke.github.com/ > http://clausreinke.github.com/**js-tools/<http://clausreinke.github.com/js-tools/> > > > ______________________________**_________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss> >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
