The Tragedy of the Common Lisp, or, Why Large Languages Explode (was: revive let blocks)

C. Scott Ananian ecmascript at
Fri Jun 19 15:03:20 UTC 2015

An interesting wrinkle in language design has been the rise of
sophisticated linting and style tools like `jscs`.  If you wish to
deprecate `var` for instance, it is straightforward to write a jscs module
to enforce that.  Further, several large communities (node, wikipedia, etc)
have published jscs "presets" that effectively define the subset of the
language they use.

So in a meaningful way we are getting the tools to voluntarily deprecate
features in a community-driven way.  Certain quirks may always exist in the
spec (although perhaps more and more they will migrate to compatibility
appendixes), but can be effectively ignored for communities opting in to
jscs presets.

I note that certain ES6 features have also been written specifically to
allow opt-in to sane behavior.  For example, a `SaneArray` subclass of
Array is often discussed here.  Use of SaneArray instead of stock Array
could also be enforced by jscs-like tools.  (Although this means giving up
Array literal syntax?  So there's still a bit of awkwardness.  And API
boundaries are tricky.  Future work!)

Anyway, I look forward to a continued process of community-driven feature
deprecation, and hope that we will continue to look for ways in ES7 to
allow further opt-in fixes to our warts. (I also look forward to continued
development of interesting rule sets and analyses in jscs and similar tools
to shave off warts.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list