Brendan Eich brendan at mozilla.org
Thu Aug 14 00:33:09 PDT 2008

On Aug 13, 2008, at 11:37 PM, Peter Michaux wrote:

>> How large are the JS programs you write? What other programming  
>> languages do you use, and at what scale?
> I'm not sure if these two questions are rhetorical or not but  
> anyway...

No, I was curious. It's helpful to get "scale data" samples from  
different folks in the community.

> Just out of curiosity, are there many folks on the committee that
> write JavaScript applications? I ask that question with zero snark
> factor. I have the impression the majority of members are language
> implementers and that may be a completely unfounded impression.

That's fair, and Doug made the point at the first meeting he  
attended. We have included folks like Alex Russell and now Kris Zyp  
from Dojo; also Adam Peller of IBM, a Dojo committer.

The committee members are not just language implementors or experts,  
but representatives for their organizations. Apple is all about web  
as platform. The Mozilla community's JS hackers let me know what they  
think and set me straight often. Opera has a web apps / widgets team.  

But like many other programming language standards bodies, selection  
for language implementors is inevitable. I've also invited experts  
from academia, specifically Dave Herman and Cormac Flanagan, to help  
with specification and provide balance. Without growing too large, I  
favor a mix from several disciplines on the committee.

Majority rules is not the committee's way, rather consensus (general  
agreement). The majority of JS hackers may not agree on much, from  
what I can tell.

I'll say this: I've seen an effect with some JS hackers, possibly a  
Stockholm Syndrome variant, where because the language was frozen for  
nine years, and because one has to struggle to get things to work  
cross-browser, necessity becomes a virtue, and change is viewed as a  
threat. "Don't turn it into Java" or "I like billing hours working  
around current deficiencies" are two kinds of comments (paraphrased  
slightly, or somewhat pointedly in the second case) that I hear.

This effect seems entirely malign to me. I'm not talking about you  
here, note well! My point is that the current JS users have been  
abused: stuck with something that didn't grow at all after a  
premature standardization cycle in the '90s. Many are worth hearing  
from, via this email list, in blogs, at sites like ajaxian.com; but  
some (sore abused and loving it ;-) are not the best guide on how to  
get "unstuck".

> I often wonder if it is necessary that ECMAScript is a language which
> "covers all bases" and it good at all scales. We have plenty of
> languages that already try to do that (and don't.)

No language should try to be everything.

My position is that JS needs to evolve to meet users' needs, not be  
frozen or stunted, or have its users reeducated (in camps? that won't  
work) to use it as is, or in subset form. If one has only Fortran,  
then a subset if not a pre-processor (Ratfor!) may be a win. But if  
JS can evolve in an open-standards fashion, then it should, and we  
can put away some of the hand-tools and braces.

Hand-tools as a metaphor should not be taken to disrespect doing  
things by hand or using simple tools where possible. Students should  
definitely do that, and JS users do it well when prototyping or even  
deploying small-ish codebases. Some do it well at large large scale.  
But it's not for everyone and all programs.

> I'm not arguing against type annotations with this comment but I don't
> see much difference in terms of remembering to have type checks
> between writing
> function(a) {isInt(a); ...
> and
> function(a:int) { ...

There are big differences. With the first, a might be reassigned  
later in the function and isInt wouldn't know. Also, for a mutable  
object type, 'a' might remain the same *reference*, but the object it  
refers to might mutate to violate the type constraint. Mutation is  
not your friend.

You're thinking more of 'like', and indeed, we proposed

function (a) { if (!(a like T)) throw new TypeError; ... }

But that's obviously too much boilerplate, so the short-hand

function (a like T) { ... }

has been proposed too, in ES4 and (by me, to some favorable comment  
depending on how T is defined -- specifically that it can be a value  
expression, an object or array containing types for example -- no  
distinct type expression grammar, binding rules, or evaluation model)  
in Oslo.

> I believe that a:int actually is intended to assign a type to the
> variable a and the isInt only checks the contents of a at the moment.


> I'd rather the second be sugar for the former and the variable is not
> typed at all.

That's not a good meaning to assign to an 'a:int' annotation, based  
on precedent in many languages. It's also not the right "minimal  
syntax" default meaning when mutable objects types are in play.

Another difference is the ability for some system (not necessarily  
part of the standard) to do ahead-of-time type checking. You can't do  
that efficiently or at all without the "always" and "monotonic"  
meanings of type annotations and subtype relations, as compared to  
'like' annotations (which are sugar for shape tests, more like your  
isInt call on function entry).

Another difference, for the future but worth future-proofing against:  
having the syntax gives us further hooks for contacts, with their  
accurate blame arrows when runtime tests fail. This is separate from  
the static checkability of a:int due to the always/monotic meaning.

> Your points 1-4 above and the differences of opinion and preferences
> seem to be a big obstacle to overcome in a committee by consensus.

We shall see. The committee now has the chance to reason together, to  
understand one anothers' positions and state them fairly. This  
happened in Oslo more than in any past meeting, IMHO. This is grounds  
for greater hope than I had before Harmony.

It's possible we'll get just (1) and (2), but we discussed legitimate  
use-cases for all of (1-4) in Oslo. Time preference for a successor  
spec will help defer the less useful ideas, if we work together well.  
Implementation before standardization, and user-testing, will help.

There's no silver bullet, but what's the alternative? Rejectionist  
clinging to ES3-till-2018? Again the main thing for me is to let the  
language grow in principled fashion to address pressing use-cases and  
usability problems -- not to grow artificially to any particular  
large size, but to grow beyond the artificial last-written-standard  
state, plus or minus de-facto standards/bugs, that it has been stuck at.


More information about the Es-discuss mailing list