Hi Brendan, There are many individual aspects of the the ES4 proposal that I like, many things I don't. All of which I hope to enumerate for this list over time. But overall my main distress is still the size of the language.
At http://weblogs.mozillazine.org/roadmap/archives/2007/11/es4_news_and_opinion.html you state: # [...] the proposed ECMAScript 4th edition (ES4) grammar is a bit more than twice # as big as ES3's, counting several ways [...] # This is not out of line given the eight years since ES3, which came less than # three years after ES1. It is one thing to sigh with despair at other people's tendencies to add features to languages over time. It is another to see this as a virtue. Perhaps EcmaScript 15, eighty years from now, will be 10 times as large as ES4. I would agree that this may happen, as it seems to be happening to Java. But should we look forward to this as a good thing? Please don't dismiss such "mood of the language" issues. The "fuzzy" points you made in your previous reply to me were quite valuable, even though they are at least as non-objectively "mood of the language"-like as many of the arguments you've dismissed on these grounds. Language size has a real cost. The "brainprint" you refer to, at least for my brain, goes up more than linearly in the size of language. Fortunately, later in that same paragraph, you say: # And we're being generous with syntactic conveniences, # which desugar to a smaller core language. >From my perspective, this may be very good news! Is this smaller core language documented anywhere? E, Scheme, Mozart/Oz, and many languages I like are organized as small core/kernel language + syntactic sugar. Bottom-up learners like myself can more easily understand such languages by first absorbing the core language, and then understanding the rest in terms of their expansion to the constructs they've already understood. >From a security perspective, a small core/kernel language is especially important. Secure computing is best understood as a multi-player game. In order to plan one's moves, one must understand not only what one is able to do, one must also understand the limits on what the other players are able to do. Such arguments, whether formal or informal, are effectively inductions over all the operations available to the other players. Fortunately, with the core + sugar approach, such arguments only need to enumerate the elements of the core. -- Text by me above is hereby placed in the public domain Cheers, --MarkM _______________________________________________ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
