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

William Edney bedney at technicalpursuit.com
Fri Jun 19 18:50:33 UTC 2015


Indeed Mark.

It took some of us longer to unwind those features out of our codebase than
others.

One of my biggest concerns in switching to the "yearly" numbering system is
the same as Allen & Kevin: there will be pressure to ship new features
every year (as if we're a software company that wants to get our users on
the upgrade treadmill).

Insofar as breaking changes, "use strict" in E5 was basically hitting the
low-hanging fruit. Now things get much more tricky. As has been endlessly
stated, you can't break the web. Therefore, I would anticipate future
versions of this spec to continue to be what they have been in the past:
mostly additive, except where clarifications are required. Anything else is
incredibly disruptive - much more so than the switch from IPv4 to IPv6 and
we see how long that has taken - and only under the threat of running out
of addresses. JS faces no such threat.

Cheers,

- Bill

On Fri, Jun 19, 2015 at 1:32 PM, Mark S. Miller <erights at google.com> wrote:

> "use strict" was only a breaking change regarding ES3 code that
> coincidentally happened to use exactly this literal string as a do-nothing
> expression statement in exactly this position. In all of the web, we have
> not run across a single incident of this happening accidentally.
>
>
> For the record, not only have we successfully deprecated one feature, we
> have even wounded it sufficiently that I expect most of us will outlive it:
>
>     function.caller, function.arguments, arguments.caller,
> arguments.callee.
>
> But note the effort it took to wound it and the time it is taking to die.
>
>
>
>
> On Fri, Jun 19, 2015 at 11:23 AM, Alexander Jones <alex at weej.com> wrote:
>
>> 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> 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>
>>>> 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
>>>>>
>>>>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
> --
>     Cheers,
>     --MarkM
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150619/d7ceb5e2/attachment.html>


More information about the es-discuss mailing list