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
[email protected]
https://mail.mozilla.org/listinfo/es4-discuss
