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

Alexander Jones alex at weej.com
Fri Jun 19 18:23:31 UTC 2015


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 <rossberg at google.com> wrote:

> On 19 June 2015 at 10:06, Alexander Jones <alex at weej.com
> <javascript:_e(%7B%7D,'cvml','alex at weej.com');>> 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 <allen at wirfs-brock.com
>> <javascript:_e(%7B%7D,'cvml','allen at wirfs-brock.com');>> wrote:
>>
>>>
>>> On Jun 18, 2015, at 12:18 PM, Andreas Rossberg wrote:
>>>
>>> On 18 June 2015 at 19:26, Benjamin Gruenbaum <benjamingr at gmail.com>
>>> 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
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150619/063ad337/attachment.html>


More information about the es-discuss mailing list