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. Etc. 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. Right. > 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. /be _______________________________________________ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss