complexity tax

Brendan Eich brendan at
Wed Mar 26 15:48:02 PDT 2008

On Mar 26, 2008, at 10:01 AM, Ric Johnson wrote:

> Let us take action instead of throwing opinions around:
> Brendan: What new features that can not be implemented via code
> constructs now?

This is reductionism, therefore between silly and wrong, but I will  
list a few things:

* you can't make read-only properties in ES3;

*you can't make don't-delete properties of plain old objects (only  
vars in closures);

* you can't make objects that cannot be extended;

* you can't make don't-enum properties in plain old objects;

* you can't yield from a function to its caller, saving state  
automatically in local variables, and send a value back to the  
suspended activation of that function.

The last is generators, but let's suppose that we add those. I'm  
intentionally leaving out things that are hard to do, but can be  
done, with closures (e.g., guaranteeing that |this| binds to a  
particular object when a method is called; or guaranteeing that a  
particular method *will be* called by a given name on an object).

Suppose further that you chose the absolute minimal set of additions  
to support some semblance of a solution for the first four bullets.

My response is that adding a few meta-methods to flip property  
attributes is not thereby "enough", since it is still incredibly  
verbose, error-prone, inefficient, and subject to "in the middle of  
construction" integrity attacks to build up "classes" or other ES4  
features using objects with const/permanent/non-enumerable additions.  
Almost no one will write such "classes" out by hand.

I noted years ago to Doug (after a talk at Yahoo! I gave) how a macro  
system would help programmers use some primitives better without  
adding more surface syntax. He wondered whether we shouldn't do  
macros first. Problem is macros are not theoretically worked out yet  
-- and that's in the context of Scheme. So rather than starve the  
patient further, I argue we should be willing to add syntactic  
conveniences as well as syntax for new substance. Macros may come,  
and much can be recast in terms of them, and the ecosystem can take  
over the business of syntactic extension, to a great extent.

Anyway, I don't think my answer here helps decide what to do.  
Opinions and tastes vary about things like syntax, dynamic meta- 
programming using fewer primitives vs. declarative new forms that can  
be (optionally) statically checked, etc. Some people will always  
prefer to use fewer primitives. It seems better to me to grow  
JavaScript based on existing "design patterns" used (at some cost) on  
top of ES3, and based on solutions from "nearby" languages such as  
Python and ActionScript 3 (to take just two examples).

Even this does not mean anything particular about complexity budgets.  
I will say this: ES4 has overspent its complexity budget in order to  
explore a large design space. It is now shrinking to meet practical  
budgets involving Ecma member consensus, prime mover commitments,  
fatigue effects, community expectations, and the like. No one working  
on ES4 wants it to be like Perl 6. We aim to finish this year. So  
you'll see proposals like multimethods getting deferred.


More information about the Es4-discuss mailing list