Insurrection (was: ES4 draft: Object)

Mark Miller erights at gmail.com
Mon Mar 10 21:54:45 PDT 2008


On Mon, Mar 10, 2008 at 8:11 PM, Jeff Dyer <jodyer at adobe.com> wrote:
>  On 3/10/08 5:40 PM, Waldemar Horwat wrote:
>  > I'm dealing with a serious insurrection of folks who believe that the ES4
>  > working group has a bad attitude, based on Brendan's public comments and
>  > responses to issues like this one.  They're quite visible.
>
>  No doubt the WG has attitude. There are strong personalities involved and we
>  have had our share of knocks. Sometimes that shows. You of all people should
>  understand why. But please do share more about the insurrection you are
>  dealing with. Maybe then we can be more sensitive.

I hope Waldemar is not counting me as a member of that insurrection.
My problem with the ES4 proposal has nothing to do with the attitude
and personality of the ES4 WG members. Quite the opposite. I have come
to like and respect those of you I have come to know. Since Brendan is
mentioned explicitly above, I'll mention the high regard I've come to
have for Brendan in particular. I have also enjoyed every encounter I
have had with the group as a whole.

"A vague disclaimer is nobody's friend."
               --Willow Rosenberg, Buffy episode: The Initiative

"True friends stab you in the front."
              --Oscar Wilde

I do not wish to offend anyone. I know I am speaking harshly about
work that many here have invested in heavily. But in the interests of
clarity, I will speak plainly below. I hope the discussion will
continue from here with its customary civility.

I have serious problems with the proposed ES4 *design* -- to the point
that I have a hard time taking it seriously. I hope and expect that it
will be crushed by its own weight. I fear that it might become widely
adopted, and we will instead be crushed by it. In any case, I have
decided that my energies as a new EcmaScript committee member are
better spent on the ES3.1 WG, as the other members of that WG seem
similarly inclined to look for the *smallest* reasonable language that
meets our goals
<http://wiki.ecmascript.org/doku.php?id=es3.1:es3.1_goals>.

The current fad in language design is expressive static type systems.
As a result, several recent type systems have grown eat their
language. Java 1.5 is a particularly nasty example. Simple bits of
Java code become so overwhelmed by complex type declarations as to
obscure the logic of the code itself. Proposed ES4 suffers from the
same disease, though it has not (yet) come down with as bad a case as
Java.

I applaud Jeff's and Lars' recent document of proposed deferrals from
proposed ES4. After reading this document carefully, I was then able
to reread the proposed ES4 overview document and imagine the smaller
language they are suggesting. This language I still believe to be too
large, but at least it would now be small enough to be worth
criticizing.

ES3 has several abstraction mechanisms:
* lambda abstraction, which it gets approximately as right as Scheme!
* objects as a generalization of records, which has some pros and cons
* prototype-based sharing of common behavior, which is used almost
exclusively by JavaScript programmers to express only class-like
patterns.

Altogether, ES3 has many virtues and many problems. One of its great
virtues is its almost perfect support for lexical nesting. Virtually
any thisless construct that could appear at top level can also appear
within a nested lexical context with the same meaning. ES3 also avoids
the CommonLisp trap of multiple namespaces, instead siding with
Scheme's single namespace approach.

Even ignoring ES4's type system, ES4 adds all the following
abstraction mechanisms to those in ES3:
* classes
* packages
* units
* namespaces

I have not heard anyone explain any of these as syntactic sugar that
could be expanded away into remaining language elements, so I fear all
of these would be fundamental. Worse, several of these constructs can
only appear at top level, and so destroy the almost perfect lexical
nestability enjoyed by ES3.

If instead classes, for example, were defined purely by syntactic
expansion to the constructs in ES3.1, then classes would inherit the
lexical nestability of the constructs they expand into. Even Java's
classes are lexically nestable!

The namespace mechanism seems motivated by a failure to appreciate the
power available by modest extensions of simple lambda abstraction. ES3
already provides some of the features for supporting such modest
extensions: Several libraries (such as YUI) already use naming paths
such as foo.bar.baz. This is supported by ES3's lexical scoping
combined with its extensible records and its property lookup notation.
Why should we prefer foo::bar::baz?
ES3 already suffers from having two bottom values -- null and
undefined -- with no general consensus of when one should use which.
How are we to regard mixed naming paths such as foo.bar::baz? When
should one use a record as a naming container vs a namespace? What is
gained by having two mechanisms?


I could go on and on about ES4's types gone wild, and I will if
there's interest. But for now I think one example will suffice:

When I first read the overview, I was puzzled by the lack of
uniformity between the types [int] and [int, String]. IIUC, the first
represents the type of all arrays *all* of whose elements are ints.
The second represents all 2+ length arrays whose first two elements
are an int and a String. I was puzzled: How does one represent the
type of all arrays whose first element is an int? I now understand
that this is considered an anti-pattern that the language purposely
makes inexpressible. I have read but do not understand why this is
considered an anti-pattern. No matter. Let's suppose it is an
anti-pattern. I would agree that one job of a language design is to
gently lead programmers away from bad patterns and toward good ones.

However, this particular syntactic choice is a programmer-hostile way
to go about it. It is a trap for the unwary, who will be repeatedly
burned by misreading [int]. If I were to agree about what abstract
types should be and not be expressible, I would choose surface
syntaxes that would make their differences obvious. Perhaps something
like [int*] and [int, String, *]. Then, if a naive programmer did wish
to express the mysteriously verboten concept of, for example, the type
of arrays representing a pair of an int and a String, they might
foolishly write [int, String] and the compiler could catch their silly
mistake, giving them an error message that would enlighten them about
why this concept should be inexpressible.

Btw, call me foolish, but why should the concepts of "array of exactly
one int" and "array of exactly one int followed by one String" be
inexpressible? I have read a justification of the first, but I failed
to understand it.

-- 
Text by me above is hereby placed in the public domain

    Cheers,
    --MarkM



More information about the Es4-discuss mailing list