In all of the examples I mentioned there are other, more predictable alternatives already in the language. Do we really expect JavaScript programmers in 2025 to remember to use Number.isNaN instead of isNaN? I really don't understand why people think "use strict" was OK to pull off, but further breaking-change evolutions of the language are not.
On Friday, June 19, 2015, Andreas Rossberg <[email protected]> wrote: > On 19 June 2015 at 10:06, Alexander Jones <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > >> If people are unable to internalize the whole language, then surely we >> need a way to remove cruft and idiosyncracies in it, lest the language >> stagnate beyond repair. >> >> Removing var, typeof, exotic objects, function declarations, IsNaN, ==, >> enumerable properties, are just a few examples of things we should not be >> frightened to talk about. >> >> While I don't personally see a need for the proposed let syntax, I think >> that concerns about the language growing uncontrollably should be directed >> at its apparent lack of deprecation strategy, rather than shutting down >> discussion of new ideas that might help us write better programs. >> > > While I agree that the impossibility of deprecating features is a problem > (without a solution in JS), it's also fair to say that deprecation doesn't > really work or help. Take C++ as the obvious example. They do deprecate > occasionally, with difficulties. Yet the language had already blown > complexity out of any sane proportion 25 years ago. Let alone today. Not a > chance that there is a single person who _even remotely_ understands the > full language, and there probably hasn't been one for 3 decades at least. > > Deprecation doesn't solve the problem because new cruft typically gets > added orders of magnitude faster than old cruft can ever be removed. That > is true for almost all production languages. Because it's so much easier to > add stuff. > > Thus, the only way to keep a language small (if at all) is being extra > careful about adding features. Just about any terrible feature can be > justified by "use cases", but that's insufficient reason to add it. > Especially "convenience" features are a slippery slope. (I could make a > list of ES6 additions that already violate this principle.) > > The art in language design isn't what to add, but what to leave out. > > /Andreas > > > > >> On Thursday, June 18, 2015, Allen Wirfs-Brock <[email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: >> >>> >>> On Jun 18, 2015, at 12:18 PM, Andreas Rossberg wrote: >>> >>> On 18 June 2015 at 19:26, Benjamin Gruenbaum <[email protected]> >>> wrote: >>> >>>> This is a mailing list comprised of people who typically have a much >>>> better understanding of the language and its corners than most (even >>>> professional) developers have (and dare I say, are interested in or care >>>> about having). With ES6 the language already got a *lot* bigger and I'd >>>> argue that it's now harder to learn the whole. The tradeoffs were >>>> worthwhile but it's definitely an issue. >>>> >>> >>> I dare say that at this point Allen probably is the only person in the >>> world who actually fully knows and understands the complete language. I >>> won't hesitate to admit that I don't. ;) >>> >>> >>> And I occasionally have to go and look up details. >>> >>> Allen >>> >>>
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
