Preach it, brother! I'd like to jump on the bandwagon of Mark's concern about the death-of-a-thousand-cuts phenomenon.
It is far too easy to make a bunch of small additions, each of which is individually worthy and justifiable, that collectively add up to a sum total that is not so worthy or justifiable. It's particularly easy when we have a process which considers each proposed change or addition in isolation, considering it individually on its own merits as if it was all that we were doing. There's lots of good stuff in ES6, but the overall mass and complexity of the thing still makes me a little queasy. I've been observing the TC39 process for about six months now, without plunging into the discussion very deeply yet (still getting the lay of the land, as it were). One thing I find striking is the number of proposals being floated that seem to be based on "this could be useful" or "some other language I like does this" or "I think it's cool" or "I wish I could code like this instead of like that". In contrast, I see relatively few people responding to these proposals with questions like "do developers really *need* this?" or "what actual problem does this solve?". I see relatively few advocates for minimalism as a virtue per se, minimalism being a corrective to the kinds of bloat that arises from a horde of wafer thin changes. Chip On Jun 18, 2015, at 7:37 AM, Mark S. Miller <[email protected]<mailto:[email protected]>> wrote: On Wed, Jun 17, 2015 at 7:27 PM, Kyle Simpson <[email protected]<mailto:[email protected]>> wrote: I'd like to ask if there's anyone on TC39 that would be willing to champion a proposal to add the let-block (let-statement) syntax? I am not. Further, if anyone were, I would work to kill it. Here's why. The Algol, Smalltalk, Pascal, and early Scheme languages were prized for being small and beautiful. The early C and JavaScript languages were justifiably criticized for many things, and rarely mistaken for a language that was generally beautiful. But they were small, and this aspect was properly and widely appreciated. When a language is small, our appreciation of it is often driven by the sense "I can learn the whole thing, and then I will have a mastery of it", and later "I know the whole thing. I love the fact that there are no corners I don't know." For C and JavaScript, few who thought they knew the whole thing actually did -- the details were actually fiendishly complex. Nevertheless, this sense drove much of the satisfaction with everyday usage. The esthetic of smallness of JS lasted through ES5. I participated heavily in both ES5 and ES6 and in both cases I am proud of my contributions. ES6 is much larger, but nevertheless it is a much better language. Given where we started, we could not have achieved these gains in the utility of JS without such an increase in size. I do not regret most of the additions that grew ES5 to ES6. For many of these, had we the ES6 standards process to do over again, I would likely make similar additions. But each of the additions that grew ES5 into ES6 had to pass a very high bar. Psychologically, this made sense to all of us because we were starting from a language, ES5, whose smallness we could still appreciate. When a language is small, every additional feature is viscerally felt as a significant percentage increase in the size of the language. The specific benefits of a feature are always visible to its advocates. But for a small language, a new feature's general costs in added complexity are also still visible to everyone. Once a language gets beyond a certain complexity --- say LaTeX, Common Lisp, C++, PL/1, modern Java --- the experience of programming in it is more like carving out a subset of features for one's personal use out of what seems like an infinite sea of features, most of which we become resigned to never learning. Once a language feels infinite, the specific benefits of a new feature are still apparent. But the general costs in added complexity are no longer apparent. They are no longer *felt* by those discussing the new feature. Infinity + 1 === Infinity. Even aLargeNumber + 1 === approximatelyAsLargeANumber. This is the death of a thousand cuts that causes these monstrosities to grow without bound. So please, I beg all of you, when considering a new feature, please apply a higher bar than "Wouldn't it be nice if we could also write it this way?". I believe that ES6 is in that middle territory where unrestrained growth is not yet inevitable, but only if we all restrain each other with high standards for any proposed new feature. As a community, we need more of a shared sense of panic about the size that ES6 has already grown to. Ideally, that panic should increase, not decrease, with further growth from here as our size approaches the point of no return. -- Cheers, --MarkM _______________________________________________ es-discuss mailing list [email protected]<mailto:[email protected]> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
