On Oct 30, 2007, at 5:03 PM, Douglas Crockford wrote:
Brenden is also correct: If the working group voted and
the current
proposal won - it is better to have a stronger, more secure
language.
Sure they can argue it is bloated, but SO WHAT?
The proposal is not a more secure language. It does nothing to
address ECMAScript's biggest design flaw: the insecurity caused
its dependence on a global object.
Yes, ES4 is backward-compatible, so it still has a mutable global
object. Mutable prototypes are a hazard too, but required by backward
compatibility.
Breaking the global object's mutability without opt-in from new code
would break the web, so I'm surprised you are complaining about it.
We've seen each other in TG1 meetings since July 2006, but no one
including you has come up with a proposal to solve this problem
compatibly, except by doing exactly what we have done: adding
features in ES4 that developers can use to control visibility and
mutation. The very features you oppose.
ES4 provides const, fixed typename bindings, lexical scope (let),
program units, and optional static type checking -- all of which *do*
make ES4 code easier to analyze and instrument to enforce security
properties.
XSS attacks are a direct consequence of this flaw. By making the
language more complex, this problem becomes even harder to reason
about and fix.
No, ES4 with const, fixed typename bindings, lexical scope, program
units, etc. is easier to reason about than ES3, not harder.
ES4 is easier to reason about automatically. It's ironic that you
invoke reason. Reasoning about code should not be done by humans
only. Reason => logic => proof => proof system <=> type system, as I
wrote at ajaxian.com in a comment recently.
Your own words invoke the Curry-Howard correspondence, which requires
a type system that supports static analysis, as well as unambiguous
name binding. ES4 directly supports type checking and unambiguous
name binding. Yet you seem to oppose all of ES4, especially the type
system. That seems contradictory.
I have been bringing this up since my first day in the working
group. This is not a concern that is being sprung at the last minute.
I remember the 2006 July meeting well, and the minutes are posted here:
http://wiki.ecmascript.org/doku.php?id=meetings:minutes_jul_27_2006
I don't think you suggested anything not recorded in some way there.
If you mean that the item under "Yahoo!s position" about security
promises motivating Yahoo! to entertain a new and incompatible
language, that claim led nowhere. Mainly because unlike Yahoo!,
browser vendors and web developers in general will not tolerate
incompatibilities for "Security" -- but also (more important) because
no one has a convincing solution for capital-S Security, other than
adding features to ES3 that users can choose to control mutability
and more conveniently and efficiently hide names.
The eval discussion recorded in those minutes did lead to a decision
by the group not to support a sandbox optional argument to eval. It
also apparently led to that es3.1 String.prototype.eval idea, which
you have not proposed for ES4. Too bad, but perhaps we'll be able to
include it in anyway.
The working group hasn't voted. The proposal has not won. We have
agreed to disagree, developing two competing proposals in the same
working group. I am pursuing with Microsoft a counter proposal for
a simpler, reliable remedy to real problems. My position isn't that
JavaScript doesn't need fixing. I think we need to be more
selective in how we fix it. Bloat, in my view, is not good design.
Who could argue with that?
Since backward compatibility matters a lot to us, both to conserve
working code so some of it can be gradually migrated to ES4, and to
minimize code footprint for a common ES3/ES4 implementation on small
devices (you've heard both of these points since the July 2006
meeting), we have indeed made some additive changes -- 'let' in
addition to 'var', for example. We've even prototyped some of these
in Firefox, to prove they didn't break anything (with opt-in
keywords) and did not exact a big code footprint cost (they did not).
This approach shows serious concern for compatibility, but in spite
of it, we still get "break the web" FUD. Yet our "compatibility
through opt-in additions" approach also makes it all too easy for
someone arguing casually to accuse ES4 of being bloated. Catch-22.
Taking the high road here does nothing but pat yourself on the back,
and for work not visible to anyone except you and Microsoft (and some
Ajax developers who got advance copies? That "ES4 will break the web"
covert blog-spin campaign leaked, BTW). What good does it do to
posture against bloat when your alternative proposal is hidden? I'm
assuming there is an alternative proposal beyond some JScript documents.
Look, I can take a different high road and mimic your arguing style:
"Everyone familiar with the uses of closures in JS (for information
hiding), something you've championed, who has run into closure-
induced leaks and the larger object population costs of too many
closures, will say your proposal is the opposite of bloated: stunted,
insufficient, inefficient."
Doesn't feel very good to be on the receiving end, does it? I didn't
have to do any work to demonstrate my claims. I didn't even have to
state problems precisely.
It would be great if you could start, after over a year of
involvement in TG1, and a while in es4-discuss, to communicate
better. I'm glad to have as many words as you've sent today, even
with the bloat remark, given how few specific and actionable words
you've uttered to TG1. But the bloat accusations and superior-
sounding claims to be selective need to stop. Everyone working on TG1
has been selective by some criteria. No one wants bloat. For us to
get anywhere and avoid a fork, this kind of rhetoric has to stop.
/be
_______________________________________________
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
