Open letter to Chris Wilson

24 Replies to “Open letter to Chris Wilson”

1. What I still do not understand is why Microsoft joined the OpenAjax Alliance but still is actively causing these impediments? Is this a case of the right hand does not know what the left is doing: are they different departments that have alternative goals? Or did they just join just to help manage the committee?

2. Hi Ric (OpenDomain ;-),
   Your comment makes me want to say that individuals working for Microsoft have their own motivations and beliefs, which I’m sure are just as sincerely held as anyone else’s. For instance, that “browser profile” wiki page I cited expresses Pratap Lakshman’s general views in favor of smaller languages. It’s very clear Doug Crockford agrees. People in any organization have different reasons, and sometimes multiple layers of reasoning, for taking a group position.
   This does not alter the overriding corporate conflict of interest between the web and alternative platforms.
   Sincere and mixed individual motivations applies to Mozilla and the rest of the TG1 members, of course. We don’t all agree on everything. We are not done yet. We prefer to minimize when doing so does not impose too great a complexity tax (name hiding of various kinds, generators, etc.), or leave developers without any tools at all (mutation controls for integrity). But the majority in TG1 does agree that JS should grow, because its legitimate use-cases on the web exceed what it was designed to do easily — or at all.
   /be

3. Brendon,
   While I understand your arguments regarding ES3’s short-comings for programming in the large, what I have never seen addressed is why it was decided that it is worth transforming it into a language that does.
   In your discussion here (https://wiki.ecmascript.org/doku.php?id=discussion:browser_profile)
   with Pratap, I think he does have it right by saying the ES4 is a new language compared ES3. And as a long time Java developer who has only recently come to JS programming, 12 months ago I too would have been one of those cheering for you to make ES4 more Java-like.
   But having been shown the elegance of ES3 (in large part by Douglas Crokfords writings) I do find myself now thinking you are ruining a nice small elegant language by introducing all these new features. Really if you want all these “professional” programmers who are now jumping onto the browser webapp bandwagon to have something less scary then ES3, just add support for [script] language=”Java/C#/C++” [/script]
   and be done with it. Because believe me, they/I won’t be happy until you’ve added every bit of the kitchen skink thats already in their language of choice.
   I also think that in that wiki discussion you incorrectly put up examples like GWT and Script# as being the alternative to the new features of ES4. But as I said – Java/C#’ers use these to-JS compilers because they are too lazy/busy to bother with learning JS and I don’t see that changing with ES4. It will still be different enough to their language of choice for them to bother learning.
   Also I think the whole view point of ES4 has been skewed way to far by “professional” programmers. The last time I checked, they weren’t exactly in the majority of ES3 userbase. I guess they are in the ES3 library writing segment but really building ES4 just to make their life easier really is throwing out the baby with the bathwater. I’ve had first hand experience teaching programming (Java and recently ES3) to new comers from a wide variety of backgrounds (accountants, biologists, graphic designers) and I think you can guess which is easier to explain to them.
   In the end, whats happening with the whole Tamarin and *Monkey initiatives? – you are putting a new VM into every browser that you want to support a new language: ES4. Its just a shame that no one seems to have learnt the lesson from the marketing stunt that saw years of confusion about JAVAScript being somehow related to Java, your new ES4 will be the same – there are so many big changes its no longer the same language and just because you are keeping backwards compatibility wont make it so.

4. maks, regarding “why it was decided that it is worth transforming it into a language that does [address programming in the large]” — this has been addressed in several places, including in that same browser profile page:
   “Losing backward compatibility both hurts migration and bloats browsers with two engines.”
   I wrote in es4-discuss recently:
   “Browsers not bundled with operating systems, therefore downloaded voluntarily by users, cannot afford two engines. Even more to the point: browsers targeting phones and other small devices cannot afford two engines. And there is no need for two engines, since ES4 is a superset of ES3.”
   Searching for “footprint” at https://wiki.ecmascript.org/ leads to the https://wiki.ecmascript.org/doku.php?id=es3.1:discussion&s=footprint page, which also makes this argument.
   Apple, Mozilla, Opera, and Adobe for FlashLite and any future Flash on mobile, cannot afford two engines. At least Mozilla and Opera can’t afford two engines for desktop browsers either.
   What’s more, as I’ve pointed out at arstechnica.com and lambda-the-ultimate.org, two engines for incompatible languages, one addressing programming in the large, entail more than just the unacceptable code footprint hit — you have to unify memory management or implement a super-GC to deal with cyclic references among the several heaps, or cycles create permanent memory leaks.
   Since you understand the arguments for programming in the large, I hope the one-engine requirement is clear enough now for you to see why we are evolving (yes, evolving — not replacing or adding another language) ES3 into ES4.
   Assertions that ES4 is a new language compared to ES3 are either obviously true (it’s new, it has more in it), or false (ES4 is a superset, as ES3 was a superset of ES2 before it, and so on back to ES1). What do you mean, exactly? If you mean “new and completely different”, that’s false. If you don’t like the “mood” or “feel” of some ES4 features, then don’t use them.
   As for “ruining” a nice small language, you and Doug are certainly entitled to your opinions, but ES4 is not done yet, and I don’t think you know it well enough to judge it. What’s more important, without ES4, the much worse ruin that I foresee (Doug predicts this too) is the open web standards including JS being replaced by C# in Silverlight, AS3 in Flash, and the like. And one big reason this is a threat is that JS1 does not scale in time, space, and human factors (programming in the large).
   It’s possible to make an idol of smallness in programming language design. Yukihiro Matsumoto, Ruby creator (in Beautiful Code):
   “Simplicity is one of the most misunderstood concepts in programming. People who design languages frequently want to keep those languages simple and clean. While the sentiment is noble, doing this can make programs written in that language more complex.”
   Guy Steele had an OOPSLA talk along the same lines (“Growing a Language”, see https://video.google.com/videoplay?docid=-8860158196198824415).
   The over-minimized design of JS has led not only to confusion about things like the meaning of |this| due to too few special forms (unbound methods, constructor functions called without operator new), it also imposed a long-term complexity tax on JS programmers and libraries. Everyone invents an OOP framework, some standard packaging discipline, and a latent type system. Why should not the core language address these obvious requirements?
   Why should Ajax developers have to learn, compare, and download dozens to hundreds of kilobytes of code to make up (only partly) for deficiencies in the core language?
   Your assertions do not answer this question or justify anything by appealing to “elegance”. Nothing is elegant in a language pushed beyond its design scale and performance limits.
   And I haven’t even mentioned the mutability and name ambiguity controls in ES4, without which it is impossible to secure ES3 against many kinds of security threats.
   Regarding Java (or C#, etc.), see above about competitive browsers and similar runtimes not being able to afford more than one engine in their default and especially mobile configurations. Java in the browser is nearly dead, and it will not make a comeback (certainly not in IE).
   On your final Monkey question, you seem to be parroting Chris Wilson, who in a blog recently reversed the logic of ScreamingMonkey to try to “prove” that ES4 requires a new VM.
   On the contrary, well designed VMs such as Opera’s latest can and will be extended from ES3 to ES4. Chris had it backward: ScreamingMonkey is a new VM for IE only to handle the case where Microsoft rejects ES4 — which appears to be happening.
   To prove this, I’ll make a promise: if Microsoft truly embraces ES4 and ships it in an IE beta, I’ll put ScreamingMonkey on hiatus.
   Bootstrapping your arguments against ES4 based on Microsoft’s recalcitrance is perverse. Do you see this now?
   /be

5. [off-topic]FYI, There’s a JavaScript error in IE on this page: a link tag inside of a script tag. It completely prevents IE users to comment on this post (I had to do it from Firefox). I do realize you probably didn’t write this. Just letting you know so you can report it to whoever did. But it does err on the funny side seeing this is a description about js…[/off-topic]

6. https://channel9.msdn.com/ShowPost.aspx?PostID=353237
   This was posted on the official Microsoft blog – will be interesting to follow the comments

7. All Microsoft FUD aside, you are doing a phenomenal job refining a first rate programming language.
   Keep up the good work.

8. The only feature I really wish would be added to Javascript is built-in support for behaviors. It’s really handy to be able to assign Javascript to DOM elements and events in CSS-style.
   The ability to work with sound and video more directly from Javascript would be nice too. I really don’t like using Flash or Java just to use a little multimedia. That’s probably more of a (X)HTML feature but I’d use it a lot with Javascript.
   Probably more of an implementation issue than language design but it’d also be nice if Javascript was faster. It has noticable speed issues on every browser I’ve tested when trying to do heavy UI or multimedia stuff.
   While asking for Javascript-related features that aren’t actually part of the language – It’d be really useful if Javascript could be forced to load from a script and only from the HEAD part of an HTML document. We could avoid a lot of XSS issues that way. If developers and users each had the ability to force Javascript to behave that when when we desired it’d solve a lot of problems.
   Maybe somebody out there could make these things happen. Other than that I just have to say that if there becomes a conflict between the Javascript standard and IE support I’ll choose to use the standard on all my websites.

9. mak: also, note that ES4 is not just designed to meet the needs of Java/C# programmers who find themselves working in JavaScript, it’s also designed to meet the needs of JavaScript programmers who find themselves writing larger and more complex programs and struggling with the limitations of ES3.
   And those programmers have no Java/C# bias (if there actually is such a thing) that would make them unhappy with any language less complex than those, they just want some extra language facilities that help them accomplish their programming tasks without overcomplicated, poorly-performing, risky workarounds.
   This is quite a typical evolutionary step forward for a scripting language.

10. Look, folks, normally when someone from Microsoft says something the first thing I do is to assume they’re trying to put something over me. But they’re right, ES4 isn’t a new version of ES3, its a completely different language that’s been dunked in a tub of Javascript long enough to make it smell familiar.

11. Leechman: you haven’t read anything about ES4, or tested the reference implementation (RI, from https://www.ecmascript.org/), have you? Here, I’ll do it for you:
    >> function Base(a,b) { this.a = a; this.b = b }
    >> Base.prototype.toString = function () { return “Base(” + this.a + “,” + this.b + “)” }
    [function Function]
    >> b = new Base(3,7)
    Base(3,7)
    >> function Derived(a,b,c) { this.constructor(a,b); this.c = c }
    >> Derived.prototype = new Base
    Base(undefined,undefined)
    >> d = new Derived(11,21,42)
    Base(11,21)
    >> d.c
    42
    I know, don’t feed the trolls. But there, the RI already runs familiar JS code. If you don’t like the compatible extensions added in ES4 to ES3, then don’t use them (and take a bath yourself! you reek of eau-de-troll :-)).
    /be

12. I’ve spent some time both reviewing the most recent ES4 proposal and playing with the test implementation (though I’d really like to see the Linux version up and running). What I’ve seen in both is that ES4 is moving consistently toward the same Haskell-like functional programming concepts that also inform Microsoft’s LINQ, and that to be honest has been the bedrock for most of the more sophisticated JavaScript that has appeared as part of the AJAX movement.
    In my experience, such functional programming is somewhat different than what many programmers (especially those who are still strongly influenced by the Algol family paradigm) may have been trained to, but it is not all that much different from what people working with Ruby, Python, Haskell, and dare I say, AJAX, are producing on a daily basis.
    The argument that both Chris Wilson and Douglas Crockford are making – of encouraging simplicity in the language – is certainly valid, but simplicity is not the same as stasis. Coming from the XML side, I have to deal with namespaces every day, and as much as they can be a pain in the butt, they are nonetheless a reasonably elegant solution to the problem of dealing with name collisions when you have the advent of multiple potential frameworks and libraries.
    The package architecture that ES4 proposes is recognition that we have left the domain where linear namespaces are adequate for software development, and is long overdue. That such exists in nearly all contemporary languages EXCEPT JavaScript should indicate how bogus the simplicity/stasis argument is.
    I see most of the other features that ES4 incorporates falling into this category as well – not so much a complete refactoring of JavaScript as the introduction of structures which currently exist in an ad hoc fashion now that reasonably should be standardized in order to insure the widest degree of adoption.
    Brendan, keep in mind as well that Microsoft has never formally adopted JavaScript as a preferred strategy, as you well know. JScript was introduced because VBScript was losing market-share, the innovations that Microsoft introduced that HAVE been readily adopted by the rest of the community (most notably XMLHttpRequest) have generally been ActiveX components that were never intended to be a part of JScript, and the more conciliatory stance that Microsoft has pushed (such as seeking OpenAJAX membership) have generally been tempered by a rather arrogant assumption that they are in fact in a position where they can dictate the direction of that movement – despite the fact that increasingly AJAX solutions are arriving first for Firefox and only after an increasing delay are being rewritten (when even possible) for IE.
    I can only wish you the best of luck with this, and a vote of confidence in your efforts with ES4. Microsoft can either choose to participate actively or not as they so wish, but my suspicion is that they are involved with these efforts only to have the opportunity from a marketing standpoint to wave the AJAX flag without any intent of actually playing nicely in this space. In the long run, the community will judge whether this approach has merit or not.

13. i couldn’t agree more with Kurt Cagle. after looking at the spec, it really seems to be a huge step in the right direction.
    and all those who have concerns regarding speed: it’s definitely better to have all those features in the runtime than to implement them dozens of times in each library.
    reading the negative statements from ms, i guess they fear two things:
    first: no one would need their silverlight anymore.
    second: their current jscript interpreter is so badly designed (not to say a mess), that it would be impossible to use it for ES4.
    seen in this light (long shot) it makes sense to undercut the ES4 efforts, and to get away with a bugfixed ES3 implementation called ES3.1.
    for me as a webdevolper it’s really sad to see, how microsoft is trying to prevent all progression of the open web.
    i don’t want to count all the hours i spent fixing weird ie memory leaks and performance problems without any serious debugging and profiling tools, thank you MS.
    so i think you chose the right strategy when writing this:
    “To prove this, I’ll make a promise: if Microsoft truly embraces ES4 and ships it in an IE beta, I’ll put ScreamingMonkey on hiatus.”
    i’ll bet my money on ScreamingMonkey.
    keep up the good work!

14. in answering to maks you addressed whether it’s better to evolve ES or add support for other languages (c#,java, etc..). However you didn’t address the issue of whether we need that “programming in the large” approach at all, which if you’d asked me, I’d answer we don’t.
    In my opinion the notion that we need to add features so that ajax programming would be easier is plain wrong. ajax is a hack and also the notion of a webapp is a hack. the web was created in a document centric view. All w3c standards are also based on the same document notion. The heart of the web, the HTTP protocol is designed to support a web of documents and as such is stateless.
    the proper solution, IMO, is not to evolve ES for the benefit of ajax and webapps, but rather generalize the notion of a document browser that connects to a web of documents to a general purpose client engine that connects to a network of internet applications.
    thus the current web (document) browser just becomes one such internet application.
    in order to achieve this we need a new stateful protocol (on top of TCP) and a general client engine which provides a framework that makes it easy to create a networked application using whatever programming language the programmer prefers.
    something like adobe AIR only not proprietary. You can also check out a similar approach at http://www.newio.org.
    in essence we need an open source standardized set of APIs that could be used with any programming language, to connect to the server side of the application, download the latest client side of the application if needed and run that in a sandbox.
    it would give me the power of current webapps without the need to create the interface in a proprietary framework (flex/flash) and without trying to make a document out of my application (using html and js). after all, trying to create an application with HTML is like trying to fit a square peg into a round hole.
    for example, g-mail could be said to be the one of the best webapps around yet as a user i hate using it, and i prefer the comfort of thunderbird.
    no matter how ES4 will be better and allow for google to improve the interface it’ll never reach that of TB as HTML simply cannot and should not be used for application interfaces. also the web browser is wrong for that kind of thing (why do i need a back button in my gmail application anyway??)

15. Brendan, thanks for responding to my comments (I do actually really appreciate having the chance to correspond with the author of the language I use everyday!).
    You’ve made me think that perhaps I havn’t yet left my Java preconceptions behind and I should have prefaced my remarks by saying that a lot of the JS coding I do is server-side using rhino as the JS engine (ie.
    Helma).
    So it maybe that I do still see JS as the scripting glue to Java libs rather then a full implementation language in its own right though I know my views have changed a fair bit already since the time I wrote my blog entry about it last time (https://manichord.com/blog/2006/06/fight-future.html).
    And thats the prespective I used in suggesting that another language be used for programming-in-the-large in browsers but I do completely agree with your answer – there is No place for 2 VMs in a browser (even though thats pretty much the case at the moment with Flash – but maybe Adobe is trying to fix that with Tamarin) so ES4 does need to step up to that challenge.
    To be honest I think whats made me react so strongly to the ES4 spec was seeing concepts like Class, Interface and generics from the ‘classic’ OOP world. To me introducing a large number of these in ES4 all at the same time is what seems to make it so much more complex a language. But I’m not against improving and extending ES3 – as you say its had several version iterations already, its just this time it does seem revolutionary as opposed to evolutionary, incremental changs that showed up in JS 1.6 and 1.7
    So it makes me wonder if the language could have been expanded/improved without so many big new features. For instance couldn’t we have had property attributes (I’m very happy to have DontDelete, DontEnum, ReadOnly) without the concept of classes? And doesnt JS 1.5 already have virtual properties via getters/setters (https://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Guide:Creating_New_Objects:Defining_Getters_and_Setters) ?
    And why add parameterized types at the same time?
    To be honest ES3->ES4 looks very much like C->C++ rather then the previous iterations of ES.
    Anyways I say all of the above in the past tense because I know that my comments are far too late on the scene to really have any impact on the proposed ES4 spec. I guess I’d better just download the ref impl and figure out the subset of ES4 that I prefer to use.

16. Kurt, digital.alterego: thanks.
    Yigal: the web turned from documents to apps a while ago, and there’s no turning back. Nothing about this evolution is “ideal”, but no one has a simple-enough and secure-able design for a “web app runner” (hey, that sounds familiar…). Evolution will find a way, but it won’t be all at once or from a clean slate.
    maks: a lot of people think type parameters (“generics”) are from the classical OOP world. It’s not true. Higher order type systems have a long history, worth studying. The ES4 reference implementation is written in SML, which can have type terms as parameters.
    What you say about JS1.6 and 1.7 being smaller steps is true, but those reflect the fact of we in TG1 being busy designing ES4, so having good reason not to jump the gun on shipping too much of it. Rather, we implemented the parts that seemed trickier, and important to prove in the real world; examples include yield/generators and new keywords in context. Meanwhile, AS3 and JScript.NET implemented variations or precursors of the nominal type system.
    If you look at the tools in ES4, they include classes and interfaces (for expressing DOM and builtin types in the language, and in general for making high-integrity abstractions that can’t be extended or mutated without permission); structural types (formalized “duck types”, see also JSON data), type parameters for both (and for functions), since container data structures without type parameters are too weak; and multimethods (generic functions, after Dylan and Cecil), for the + and other operators.
    As the above dissection should make clear. all of these features were latent in ES1-3, hiding inside magic (and sort of broken, or at least alien) “native” and “host” objects, or hardcoded into the operators in the language.
    Exposing clean, compositional primitives for these use-cases to all ES4 authors not only helps us bootstrap (good for the language and modern implementations), it gives authors equal powers to Ecma TC39-TG1 and the browser implementors. These facilities are obviously useful, since the core language, the DOM, and other browser or embedding native objects have hogged them until now.
    Combined with namespaces, meta-programming (mostly reflection), and programming-in-the-large features (like, wrap — these relate directly to the structural and nominal types), they make ES4 capable enough that we believe it will hold its own for many years. The open web has grown from the days when I designed JS in a huge rush. It deserves more than ES3.1.
    /be

17. Urgh, can’t you just grow up and learn this thing called compromise? The rest of us, who actually end up using the stuff you both come up with, don’t care a rats ass if you call it Javascript, JScript, Ecmascript or AwesomeLanguage2.0
    Just…. please… agree. True, it’d be a complete break with tradition in web development, and perhaps you’d *both* have to settle for not getting your way 100%. Perhaps you’d *gasp* have to settle for only agreeing with 98.5% of the standard. So f’ing what?
    At least you’d stop breaking the internet for the rest of us.
    I’d like to experience in my lifetime an internet that doesn’t suck. And that requires a break with the tradition of half-assed implementations of half-assed standards that people only half-heartedly intend to follow.
    I don’t think very highly of Microsoft’s ability to make “standards”, but if the alternative is an ECMA standard? Well, that’s a bit of a joke too… So in the end, who cares? If you can just come up with something that all major browsers are going to implement (and actually try to get right)

18. Side comment. I’m not sure it’s easy to promise anything about putting ScreamingMonkey on hiatus. There may be other parties interested in moving it forward anyway, and open source allows that. But I at least take your promise as that _you_ wouldn’t be involved in it if MS supported it themselves. Another side comment, I know there are other issues to be addressed, but it’s interesting that I’ve been able to test incomplete ES4 and Tamarin in IE (due to ScreamingMonkey) but not in Firefox. Plugins do have their advantages.

19. grumpy: if you could read what’s in the meeting minutes and the es3.1 proposals, you’d see that the compromise is not 98.5% of ES4, or even 50%. More like 1%. That’s not compromise, it’s minority-dictated stagnation.
    The majority group in TG1 (formerly the entire group) compromises often, in an engineering tradition that calls out trade-offs and makes choices. It’s not as if someone (me? hardly) is demanding 100% and rejecting 98.5%.
    But please, read https://wiki.ecmascript.org/'s meeting minutes and judge for yourself. Here’s a pointer to a recent exchange:
    https://wiki.ecmascript.org/doku.php?id=meetings:minutes_sep_27_2007#unresolved_proposals
    and
    https://wiki.ecmascript.org/doku.php?id=meetings:minutes_sep_27_2007#unresolved_proposalsthe_sequel
    From the last section:
    “PL [Pratap Lakshman, Microsoft]: We do not support or agree to the current ES4 proposal, either in whole or in part. We intend to continue to work with interested TG members to develop a proposal for a more incremental revision of the current specification.”
    Given “in whole or in part”, who is unwilling to compromise? I’ve kept the ES3.1 work a supported activity in TG1 so it does not create an incompatible fork of ES3, but it seems to be off on its own now, with no public or group-visible proposals since April.
    So give me a break from your inaccurate chiding about “compromise”, and wake up and open your eyes.
    Tom: noted; I’m not able to stop anything, but I can start things, and Mark Hammond is doing a great job!
    /be

20. I’m overall positive about ES4, but I have some concerns. I’m toying with the ES4 reference implementation right now, and here are some things I’ve tried:
    >> class ClassA { }
    >> ClassA
    [class Class]
    >> ClassA.prototype.x = 1
    1
    >> a = new ClassA()
    [object ClassA]
    >> a.x
    1
    This is great, and is exactly what I want! But I thought classes were supposed to be somehow sealed from mutations?
    >> a.y = 1
    [error]
    Ah, ok, this is what’s meant. 🙁
    >> ClassA = 1
    1
    >> ClassA
    [class Class]
    I don’t like this at all, but if it’s going to be like this, shouldn’t the attempted assignment throw an error?
    >> ClassA.y = 1
    [error]
    >> class ClassA { var y = 1; }
    [error]
    🙁 Python lets you do class ClassA(ClassA): …, and ClassA = 1 for that matter
    >> Date
    [class Class]
    >> Date.prototype.getYear = function() { return this.getFullYear()+” / USE getFullYear!”; }
    [function Function]
    >> d = new Date()
    Thu, 08 Nov 2007 11:42:28 GMT+0000
    >> d.getYear()
    2007 / USE getFullYear!
    😀 This is why I fell in love with Javascript in the first place.
    >> delete ClassA
    false
    >> delete global[‘ClassA’]
    false
    >> ClassA
    [class Class]
    How are you supposed to run this interactively? What if you make a mistake with a class definition and want to remove or redefine it? (A problem I’ve already run into several times now — it’s utterly frustrating.)
    >> dynamic class MyPointClass2 { }
    >> dynamic class MyPointClass2 { var x = 0; var y = 0; }
    [error; FixtureError]
    🙁 So I can’t even remove/redefine my own classes, which will always be dynamic (why would I want them to be otherwise?) This seems an enormous step backwards. What happens if I have a page which is open 24/7 and that needs to load in javascript from somewhere else dynamically?
    Moving on to types:
    >> function fun1(i: int): int { return i*i; }
    >> fun1(3)
    9
    >> fun1(“3”)
    [error incompatible types]
    🙁 But not a total disaster (I’d even argue it’s the right behaviour here).
    >> function fun2(d: Date) { return d.getFullYear(); }
    >> fun2(d)
    2007
    >>fun2({MYCUSTOMOBJECT:0,getFullYear:function(){return 2008;}})
    [error incompatible types]
    🙁 Nooooooo! Now when I use other people’s typed libraries, I have to conform to their Official Class Hierarchy Style (which is often idiosyncratic or bitrotted, etc.). e.g.:
    >> class ProprietaryPointClass { private var x = 0; private var y = 0; function
    set(x, y) { this.x = x; this.y = y; } function get() { return [x,y]; } }
    >> tempPoint = new ProprietaryPointClass()
    [object ProprietaryPointClass]
    >> tempPoint.x = 1
    [error; attempting to add property to non-dynamic object]
    >> tempPoint.set(1,0)
    >> tempPoint.z = 1
    [error; attempting to add property to non-dynamic object]
    >> function fun3(p: ProprietaryPointClass) { var [x,y] = p.get(); return Math.sqrt(x*x+y*y); }
    >> fun3(tempPoint)
    1
    >> fun3({x:1,y:2,get:function(){return [this.x,this.y]}})
    [error; incompatible types w/o conversion]
    >> function fun4(p) { return p.x*p.y; }
    >> fun4(tempPoint)
    [error; non-existent]
    Ok, that was obvious. But the error is ‘non-existent’ rather than ‘privacy violation’, so I can’t even tell that the class actually has x and y as (private) properties.
    >> function fun5() { class ClassB { var x = 1; }; b = new ClassB(); return b; }
    [error; ParseError]
    So no quick class definitions allowed? It looks like I can’t use classes for almost anything I do. (95% of my code would be, by conscious choice, duck-typed and 5% traditional classes.)
    >> // This is the MyPointClass, which we can imagine I use extensively in my own code
    >> class MyPointClass { var x = 0; var y = 0; function get(){return [this.x,this.y]} }
    >> fun3(new MyPointClass())
    [error; incompatible types w/o conversion]
    >> myTempPoint = new MyPointClass()
    [object MyPointClass]
    >> myTempPoint.x = 1
    1
    >> myTempPoint wrap ProprietaryPointClass
    [error; expecting semicolon before identifier(wrap)]
    >> fun3(new MyPointClass() wrap ProprietaryPointClass)
    [error; ParseError]
    I’m hoping these are bugs or that I’ve misunderstood the syntax for the wrap operator. Still, because I haven’t implemented the ‘set’ function in MyPointClass, I’m guessing it won’t work anyway, even though it ‘quacks like a duck’ for this particular function.
    >> interface InterfaceA { function a() }
    >> InterfaceA.a
    [error]
    >> InterfaceA.prototype.a
    [error]
    I don’t like interfaces because they’re usually over-specified and overly onerous. (Ironically, they’re usually over-specified because it’s too difficult to create interfaces for all the valid member combinations.)
    Like I said, I have concerns, but I like ES4 overall (obviously, I haven’t discussed any of the things I like here). I’ll adapt to the changes, but while Javascript has been my clear favourite language for 10 years now (compared with Python, Perl, PHP, Lisp, ML, C/C++, Pascal and VB; I’ve only toyed with Ruby so far), that will change with ES4. A language is more than just the syntax one programmer chooses to use — it is what the community chooses to use. If I encounter too many people using classes, interfaces and types in ways that I have to deal with, then ES4 is not, in practice, at all like the ES3 I love.
    All the restrictions on mutations, etc. also seem to be the antithesis to the idea of an open web. Isn’t much of the current javascript + AJAX + JSON revolution due to end-developers being able to rewrite almost everything themselves?
    (Please excuse the long post.)

21. “[Demo of ReadOnly behavior] I don’t like this at all, but if it’s going to be like this, shouldn’t the attempted assignment throw an error?”
    That’s backward compatible — even ES1 and JS in 1995 had a ReadOnly attribute, but because ES1 had no exception handling, instead of a deadly error (as was in Netscape 2’s implementation, IIRC), ECMA settled on silent failure to update. Yeah, it’s wrong. We’ll revisit it in a compatible way, if I can get the group to consider a pragma to enable throwing a new error (ReadOnlyError?).
    But again, we have to be backward-compatible. This is a real issue, because the built-in classes (Date, etc.) are bound to ReadOnly properties of the global object in ES4.
    “:( Python lets you do class ClassA(ClassA): …, and ClassA = 1 for that matter”
    Python does not have an optional type checker. Also, remember the JSON issues that Joe Walker brought to light, where Object and Array can be hijacked?
    “How are you supposed to run this interactively? What if you make a mistake with a class…”
    This is a REPL (Read/Eval/Print-Loop). You start over, issue the ‘:reboot’ command, or use a new name.
    Scripts loaded in web browser are a different matter, so type bindings can’t be replaced. You can use namespaces to share common short names, however.
    “:( So I can’t even remove/redefine my own classes, which will always be dynamic (why would I want them to be otherwise?) This seems an enormous step backwards. What happens if I have a page which is open 24/7 and that needs to load in javascript from somewhere else dynamically”
    You can’t have it both ways. Either you want your type names to have meaning, so that runtime judgments can be consistent (never mind the optional strict mode); or you don’t. Taking strict mode into account, it would be wrong to have runtime semantics differ between standard and strict mode (say, by letting standard mode rebind type names, in opposition to strict mode assuming they are fixed and setting a flag in each compilation unit that makes them fixed).
    Also, you may like rebinding type names, but it’s a genuine integrity problem, which is a security property we care enough about to provide new tools such as classes.
    Finally, if you really want a different binding for the new class, use a new name, which can be done using namespace prefixing so that the class’s simple name is the same.
    “:( But not a total disaster (I’d even argue it’s the right behaviour here).”
    Gee, thanks! We actually had this too loose at first.
    “:( Nooooooo! Now when I use other people’s typed libraries, I have to conform to their Official Class Hierarchy Style (which is often idiosyncratic or bitrotted, etc.). e.g.:”
    Then use ‘like’ and structural types, they stand ready:
    type DateLike = like {getFullYear:function():double}
    function fun2(d: DateLike) { return d.getFullYear(); }
    fun2(new Date)
    fun2({MYCUSTOMOBJECT:0,getFullYear:function(){return 2008;}})
    The reference implementation is behind the overview here, but you get the idea.
    “Ok, that was obvious. But the error is ‘non-existent’ rather than ‘privacy violation’, so I can’t even tell that the class actually has x and y as (private) properties.”
    That’s right — no information leak.
    “So no quick class definitions allowed? It looks like I can’t use classes for almost anything I do. (95% of my code would be, by conscious choice, duck-typed and 5% traditional classes.)”
    This may be an RI bug — let me get back to you here.
    “I’m hoping these are bugs or that I’ve misunderstood the syntax for the wrap operator.”
    Yeah, the RI will catch up — stay tuned.
    “Still, because I haven’t implemented the ‘set’ function in MyPointClass, I’m guessing it won’t work anyway, even though it ‘quacks like a duck’ for this particular function.”
    You’re making informal statements about ducks that are not consistent. Look, your MyPointClass has a bill (get) but no webbed feet (set) — no feet at all! It’s a mutant impostor! 😉
    You want structural types that spell out exactly the degree of duckness you are counting on, and nominal types to implement them efficiently. Anything else is unsound. Sure, *you* know what you are doing (for now, maybe, in the small). Optional typing does not mean optional discipline or consistency, however.
    Anyway, check out the structural type system and ‘like’ as well as ‘wrap’. Structural types for APIs, using ‘like’ and ‘wrap’ as necessary, with plain old dynamic objects mixed with fast nominal type instances as the actual parameters, give you the best of all worlds: rapid prototype and untyped code forever if you prefer; assertions about “shape” or “duck-ness” at API boundaries, and possibly deeper (‘wrap’); and inviolable and efficient high-integrity abstractions where you need them.
    “If I encounter too many people using classes, interfaces and types in ways that I have to deal with, then ES4 is not, in practice, at all like the ES3 I love.”
    You have this problem today with unmixable JS styles and Ajax libraries (which are getting better about using objects as namespaces and not stepping on each other’s idea of $(…), but still have issues in general).
    The web is too big for one true way, but the cream will float to the top. If you see some Java-1 like class hierarchy nightmare, just don’t use it. That is not “ES4” or “JS2”, it’s freedom.
    “All the restrictions on mutations, etc. also seem to be the antithesis to the idea of an open web.”
    Sorry, open web, like open mind and open mouth, has to close some times. Even now, gmail and every other web app can be broken (or tricked out, granted) by rebinding key “type” names. This is an integrity => security problem at the limit. Secure mashups won’t come all at once via one true way to connect general modules, but by evolution that adds integrity among other properties. Including to JS.
    /be

22. Since the last time the standards body has agreed to something has been 1999, I think delay is simply stupid. Please keep moving forward.
    I use JavaScript as a full-time profession and must agree that there are things that need improvement. The issues with Javasscript are completely obvious to anyone who uses it every day. Simply put, it has stagnated and needs improvements. The web pages we were doing in 1999 are nothing like what we are doing now! So, it stands to reason that we need to improve the language.
    You must change or die!
    As far as incompatibility – I think you need to address this with specific test cases. You must put together a massive automated set of Javascript tests to validate compatibility. I suspect that the complaints revolve around what are really Microsoft bugs – which, obviously require a bug fix from Microsoft, but not necessarily a change in the standard!
    As far as the language getting too large, that’s really best determined by the number of lines of C++ code it takes to implement, the memory footprint, the execution speed. So, I would suggest that the reference implementations better darn well demonstrate that these language changes are wise. After all, these standards will go into mobile phones!
    As far as the language getting too complicated for people just trying to hack some code – this seems a spurious argument as long as the language is backwards compatible. So, just make sure it stays backwards incompatible.
    I urge you to do the best job you can. My long-term livelihood depends upon you.
    Scott.

23. “But again, we have to be backward-compatible. This is a real issue, because the built-in classes (Date, etc.) are bound to ReadOnly properties of the global object in ES4.”
    I guess it depends on why an end-developer has overwritten the built-in class. If it’s to supply an ‘enhanced’ definition, then silent failure might work (with warnings on stderr or in an error console). But if it’s to (un)intentionally implement something *conceptually* different to the built-in class, then exceptions are best, since the code would be completely broken anyway (potentially in dangerous ways).
    Still, wouldn’t it be a nicer upgrade experience (from ES3 -> ES4 -> ES5 and beyond), if the code simply overwrote new built-ins like ‘int’, ‘decimal’, ‘double’, ‘Vector’, etc.?
    “Python does not have an optional type checker. Also, remember the JSON issues that Joe Walker brought to light, where Object and Array can be hijacked?”
    Yes, but that’s a CSRF problem, not a Javascript language problem. Cookies shouldn’t be submitted to Javascript files (or any files, for that matter) when loaded across servers (whether using GET, POST or whatever), unless using something like the access control proposal for cookies that’s at the w3 site (modified for cookies, of course).
    (Wouldn’t access controls for cookies also make it possible to allow *any* cross-site scripting without any security concerns except for DDOS, since the data available would then be the same as that available from server side (PHP,etc.) requests?)
    In any event, Object.prototype can still be extended. Isn’t this still a security issue when combined with the cookie problem? e.g. I can type this into Firebug:
    >> Object.prototype.__defineSetter__(‘knownProperty’, function (v) { window.capturedProperty = v; } )
    >> a = {knownProperty: 3}
    >> window.capturedProperty
    3
    “This is a REPL (Read/Eval/Print-Loop). You start over, issue the ‘:reboot’ command, or use a new name.”
    ‘:reboot’ doesn’t seem to work in the RI (e.g. my ClassA is still defined).
    “Finally, if you really want a different binding for the new class, use a new name, which can be done using namespace prefixing so that the class’s simple name is the same.”
    Let me try giving a real example of what my concerns are here. I have been playing with the idea recently of creating a javascript/html/etc. shell, similar to the old xmlterm, but with a pure js command line interface. If I’m in a shell session and I want to extend the capabilities of the shell, I can just (dynamically) pull in js files. Here’s an example of how it might work:
    jssystemshell> sys.load(‘plotfuncs.js’)
    Plotting library loaded.
    jssystemshell> plot(‘sin(x)’)
    [in-place generated svg graph of sin(x)]
    Of course, this is possible in both ES3 (with XHR or script elements) and ES4. But if I then want to unload the extensions or pull in an updated version of the extensions, I’d have to either reload the whole shell, or write backend code (e.g. in C++) that would allow the rebinding and deletion. I can’t simply do:
    jssystemshell> quit()
    Plotting library unloaded.
    (For an appropriate implementation of load/quit.) Perhaps there are ways around it with namespaces, but if the code in ‘plotfuncs.js’ lives in (say) the ‘plotfuncs’ namespace, then I’ll have to use a new namespace for each change in ‘plotfuncs.js’. I can’t tell how this would work right now, as packages don’t seem to work in the RI:
    >> package mine { var x = 1; }
    >> import mine
    >> mine.x
    [error; ReferenceError]
    >> import mine.*
    >> x
    [error; ReferenceError]
    From the spec, it looks like package structures can be extended, but not unloaded (especially from the global namespace) and I can’t tell if they can be re-imported. i.e. I don’t know what this would do:
    >> package mine { var x = 1; }
    >> import mine
    >> package mine { var y = 1; }
    >> import mine
    Ok, so cases like the js shell would account for less than 1% of all cases, but often the most revolutionary ideas lie at the edges (which is arguably what’s happening now with Javascript).
    “Then use ‘like’ and structural types, they stand ready:
    type DateLike = like {getFullYear:function():double}
    function fun2(d: DateLike) { return d.getFullYear(); }
    fun2(new Date)
    fun2({MYCUSTOMOBJECT:0,getFullYear:function(){return 2008;}})
    The reference implementation is behind the overview here, but you get the idea.”
    Yep, that is what I would try to write. Problem is, sometimes it’s just more convenient (for me or others) to use an already written class (like Date) in the type specification, rather then thinking about exactly which methods (or method signatures) and properties your function’s arguments should accept. With the availability of types, it’s tempting to write ‘function fun2(d:Date)’ instead of ‘function fun2(d)’, but not very tempting at all to write ‘function fun2(d:DateLike) + DateLike spec’. This problem is mitigated somewhat by the fact that ES4 still allows you to rewrite function definitions. Also, if your dealing with your own code, there’s no problems as you can just rewrite the original definition with the more general type when you realise you need to.
    “It’s a mutant impostor! 😉 . . . Structural types for APIs, using ‘like’ and ‘wrap’ as necessary, with plain old dynamic objects mixed with fast nominal type instances as the actual parameters, give you the best of all worlds: rapid prototype and untyped code forever if you prefer; assertions about “shape” or “duck-ness” at API boundaries, and possibly deeper (‘wrap’); and inviolable and efficient high-integrity abstractions where you need them.”
    ‘like’ and ‘wrap’ are certainly very attractive (they’re one of the things I like about ES4). To my mind, the closest thing to ‘correctly’ written variable/argument types (ignoring performance) would be like types *everywhere*. (All that matters is that an object does what’s requested — it doesn’t matter if it actually is a duck, so long as it quacks like one. If you’re cooking catches fire, you just need someone who knows how to put out the fire, you don’t specifically need a fireperson.) Still, even with like types, the function signature may be wrong, and hence you’ll need a mutant imposter. In an ideal world type annotations would be correct, in the real world — well, I don’t know yet, obviously 🙂 — but if past experiences with libraries are anything to go by, there’ll be lots of ‘wrong’ cases even in well-written libraries.
    “The web is too big for one true way, but the cream will float to the top. If you see some Java-1 like class hierarchy nightmare, just don’t use it. That is not “ES4” or “JS2″, it’s freedom.”
    Indeed, that’s why I’m still enthusiastic about ES4 despite some (perhaps unfounded) concerns.
    “”All the restrictions on mutations, etc. also seem to be the antithesis to the idea of an open web.””
    “Sorry, open web, like open mind and open mouth, has to close some times. Even now, gmail and every other web app can be broken (or tricked out, granted) by rebinding key “type” names. This is an integrity => security problem at the limit. Secure mashups won’t come all at once via one true way to connect general modules, but by evolution that adds integrity among other properties. Including to JS.”
    I reiterate my belief (and, to admit a bias, my hope) that security is an environment-level concern, not a language-level concern. (Despite the existence of terrorism, we still speak English, not NewSpeak. Ok, so that’s slightly too loose an analogy… 🙂 ) And in the case of cookies, I think it can be handled with something like the access control proposal at the w3.

24. Voracity, thanks for the long comment. Let me first note, without rancor but with some urgency, that my blog comment UI and output suck for holding this conversation. Could you please join es4-discuss@mozilla.org and restart the critical issues there, one message per issue? That would be the most productive thing to do.
    Here, and only once, I hope to deal with the type binding immutability issue so you shouldn’t have to re-raise that as such, but I think your point about a development environment that supports reloading or “redoing” is important, and needs more attention than it will get here in my blog!
    V> “I guess it depends on why an end-developer has overwritten the built-in class. If it’s to supply an ‘enhanced’ definition, then silent failure might work (with warnings on stderr or in an error console). But if it’s to (un)intentionally implement something *conceptually* different to the built-in class, then exceptions are best, since the code would be completely broken anyway (potentially in dangerous ways).”
    Danger is not an issue because browsers already disagree on whether one can override the ES3 built-in constructor functions, and ES3 itself is schizo on whether overrides are consulted. We spidered the Alexa top 1000, four levels deep, and found only an obsolete MSN .js file that tries to override Error for no good reason. This whole area, thanks to ES3 and variations in the field, is a poisoned well for AOP. AOP happens on the prototype chain, for sure, but we aren’t breaking that.
    V> “Still, wouldn’t it be a nicer upgrade experience (from ES3 -> ES4 -> ES5 and beyond), if the code simply overwrote new built-ins like ‘int’, ‘decimal’, ‘double’, ‘Vector’, etc.?”
    Old code can use new names when served under the existing or older MIME type (or language attribute value, or as default JS). That’s not the issue. For ES4 or ES5, it’s imperative that once the content has “opted into” the new type, the new invariants hold.
    V> “B> “Python does not have an optional type checker. Also, remember the JSON issues that Joe Walker brought to light, where Object and Array can be hijacked?”
    Yes, but that’s a CSRF problem, not a Javascript language problem. Cookies shouldn’t be submitted to Javascript files (or any files, for that matter) when loaded across servers (whether using GET, POST or whatever), unless using something like the access control proposal for cookies that’s at the w3 site (modified for cookies, of course).”
    It’s a CSRF problem but defense in depth requires each subsystem to do its part, to the extent it can. Since we have strong reasons to make type bindings immutable, the defense-in-depth value is a secondary but real impetus that cements the deal.
    V> “(Wouldn’t access controls for cookies also make it possible to allow *any* cross-site scripting without any security concerns except for DDOS, since the data available would then be the same as that available from server side (PHP,etc.) requests?)”
    Cookies are only one asset to protect. If we had complete information flow tracking, we could allow arbitrary mashups, and enforce policies at the network and filesystem boundaries. We may yet get to that promised land. But in the mean time, defense-in-depth + type checking mean immutable type bindings.
    V> “In any event, Object.prototype can still be extended. Isn’t this still a security issue when combined with the cookie problem? e.g. I can type this into Firebug: …”
    That’s one good reason __defineSetter__ has not been standardized, and it is not being standardized in ES4. Whether we take it out of SpiderMonkey remains to be seen.
    V> “‘:reboot’ doesn’t seem to work in the RI (e.g. my ClassA is still defined).”
    Could you please file a bug at https://bugs.ecmascript.org/ ? Thanks.
    V> “Perhaps there are ways around it with namespaces, but if the code in ‘plotfuncs.js’ lives in (say) the ‘plotfuncs’ namespace, then I’ll have to use a new namespace for each change in ‘plotfuncs.js’.”
    Please raise this issue on es4-discuss@mozilla.org.
    V> “I can’t tell how this would work right now, as packages don’t seem to work in the RI:”
    More bug fodder, and I don’t see a ticket already on file at https://bugs.ecmascript.org/ so please feel free to file.
    V> “Problem is, sometimes it’s just more convenient (for me or others) to use an already written class (like Date) in the type specification, rather then thinking about exactly which methods (or method signatures) and properties your function’s arguments should accept. With the availability of types, it’s tempting to write ‘function fun2(d:Date)’ instead of ‘function fun2(d)’, but not very tempting at all to write ‘function fun2(d:DateLike) + DateLike spec’. This problem is mitigated somewhat by the fact that ES4 still allows you to rewrite function definitions. Also, if your dealing with your own code, there’s no problems as you can just rewrite the original definition with the more general type when you realise you need to.”
    You should see the tutorial on evolutionary programming now up at ecmascript.org:
    https://www.ecmascript.org/es4/spec/evolutionary-programming-tutorial.pdf
    You really don’t need to annotate the d parameter at all, of course. If you do say d:Date, then by gum, you must mean to say that Date and only Date (or a subclass, Date is not final) instances are allowed. If you want something looser than Date but stricter than *, you have to say what you mean.
    We can’t impute a structural type to Date the class. That breaks classes as capabilities and other high-integrity use-cases. Classes are nominal types, period.
    Having written this, I must say that your comments hit on important points covered in the evolutionary programming tutorial, so I’ll just note that union types and generic functions could be helpful for your “date-like” sketch (maybe — hard to tell without more detail).
    V> “‘like’ and ‘wrap’ are certainly very attractive (they’re one of the things I like about ES4). To my mind, the closest thing to ‘correctly’ written variable/argument types (ignoring performance) would be like types *everywhere*. (All that matters is that an object does what’s requested — it doesn’t matter if it actually is a duck, so long as it quacks like one. If you’re cooking catches fire, you just need someone who knows how to put out the fire, you don’t specifically need a fireperson.)”
    Don’t overrate ‘like’, it is an assertion, a spot-check. Mutation hazards exist after the parameter is passed. See the tutorial.
    V> “I reiterate my belief (and, to admit a bias, my hope) that security is an environment-level concern, not a language-level concern. (Despite the existence of terrorism, we still speak English, not NewSpeak. Ok, so that’s slightly too loose an analogy… 🙂 ) And in the case of cookies, I think it can be handled with something like the access control proposal at the w3.”
    Security can be defined usefully only as a set of properties, e.g., the Parkerian Hexad, which are end-to-end properties of a system, which must be enforced at almost all levels of abstraction. Not just properties of the language (there’s no “secure language” that ensures secure systems built using the language, because the system must involve other components, including the world via i/o). Not just of the environment.
    Metaphors matter, but I argue that bogus WoT propaganda has degraded English toward Newspeak, and that this degradation makes it harder, not easier, to talk usefully about actual threats, causes and effects. But now I’m verging on politics, and you do not want that!
    /be

Comments are closed.