« Python for XUL scripting | Main | New Roadmaps »
October 27, 2005
Recap and Prelude
Recap
Too much travel and conference fun, too little blogging:
I was invited to present a keynote at ACM ICFP 2005 in Tallinn, Estonia at the end of September. The very kind program comittee was unanimously interested in me as the 'where the rubber meets the road' speaker. I hope I delivered; I still have tire marks on my back from the Netscape 2 days.
It was an honor to speak and attend, and I made some good connections and introductions. Among these was Autrijus Tang, who is a hero in my book for promoting both Perl 6 and Haskell in one fell swoop. Functional programming is on the rise, and I'm glad that JS is playing a small (but very widely distributed) part.
While there, the Skype guys were nice enough to have me out to dinner -- I hope to reciprocate when they're in the bay area.
The old town in Tallinn is delightful, full of charming architecture from various eras going back to the high Middle Ages. I'm planning my move already (half-kidding).
After that came Web 2.0, which was a blur of VCs, old friends, and new companies. Everyone noticed the bubbly atmosphere. Mitchell was in fine form in a kind of interleaved interview titled Can Open Source Stay Open?
Prelude
I have been working more and more with ECMA TG1 on JavaScript standards, at first E4X (which was all but done when Mozilla joined ECMA last year) and now Edition 4. Our goals include:
- Bringing Edition 4 back toward the current language, so that prototype based delegation is not a vestigial compatibility mode, but the dynamic part of an object system that includes classes with fixed members that cannot be overridden or shadowed.
- Allowing implementors to bootstrap the language, expressing all the meta-object protocol magic used by the "native" objects (ECMA-262 Edition 3 section 15), including get/set/call/construct and control over property attributes such as enumerability.
- Adding type annotations without breaking interoperation of existing and new editions, in support of programming in the large -- which is needed more and more in XUL and modern web applications.
- Fixing longstanding problems that bite almost every JS hacker, as I've discussed previously.
At the same time, and while also slaving over a hot Gecko 1.8 / Firefox 1.5 stove, I have been working with Mozilla leaders, especially shaver and other drivers, on roadmap-level plans for the next year to 15 months.
These plans build on bottom-up planning from module-sized projects such as the move to Cairo graphics as Gecko's new graphics substrate, the Python for XUL project, and the XULRunner project. We aim to balance the need to ship Firefox releases that innovate quickly in user-facing ways with the longer cycle time required to uplift the web platform with better graphics features and content languages in Gecko 1.9.
The fruits of all this planning, in the form of a coherent draft overview containing links to project and wiki pages, and a schedule and branching plan for everyone to review, will be pushed out to http://www.mozilla.org/ imminently. The old roadmap page will contain at least links, if it doesn't beome a redirect. Stay tuned.
Posted by brendan at October 27, 2005 12:42 AM
Comments
Nicely condensed transcript of the Q&A after my ICFP keynote, courtesy Olivier Danvy:
Q. Rex Page: How do you keep marketing from naming your language?
A. Threaten to quit.
Q. Rex Page: Does that work.
A. No.
Q. John Launchbury: How did Netscape make money? What was their business
model?
A. People forget that they did sell their browser. The old Netscape license
was free only for non-commercial use. Compaq intended to distribute Netscape
for free, but Microsoft threatened to revoke their Windows license if they
distributed Netscape.
Browsers still take a huge investment. Microsoft has reportedly spent
around one billion dollars on Internet Explorer.
Now they make money via advertising. Every time you buy something from
Amazon through the Mozilla search, we get a few pennies.
Q. Norman Ramsey: At the start, you said that Java was for big things and
JavaScript for the little things. But then you described some very big
things in JavaScript. What happened? Is Java still relevant? What was the
relative scale of the things built with JavaScript and with Java?
A. We believed in JavaScript for small applications. JavaScript has gotten
bigger, and Java is essentially dead on the client. Part of the story was
rewritten by Microsoft. They replaced Java with ActiveX, and Flash has
replaced it everywhere else. The only thing left over is the scripting.
Q. (?, from INRIA): What about compilation targeting JavaScript from other
languages?
A. I don't know about that, but there are some strange uses of JavaScript
out there.
Q. Jonathan Sobel: You choose a few powerful features which have made the
language so widely applicable. The one important Scheme feature you did not
include, which would have provided for syntactic abstraction and
simplification of these complex frameworks, is macros. Is there any plan to
include them in the future?
A. There is a language called Boo, which is based on Python. It is hard to
do macros well in this messy syntax [JS's messy syntax, not Boo's].
I've thought about it. Some users of Boo have created macros for
concurrency management. I'm tempted, but it doesn't seem worth it for the
99% case. The main target audience is still users who know a subset of the
language and are not elite programmers.
Q. Olivier Danvy: Does Boo use phantom types, by any chance?
Q. Simon Peyton Jones: In hindsight, what would you have done differently?
A. One of the big things, which appears as a "bug" repeatedly, is the choice
of IEEE doubles as the only numeric representation. I wish we had replaced
it with decimal.
There are a few bigger things. The type permissiveness went too far. I
would have made stronger declarative forms for constructors.
Languages like Python actually seem better to me now for larger scripts, but
I don't know if that would work well for little inline scripts. Python
would have been a stronger contender than TCL.
Posted by: Brendan Eich ![[TypeKey Profile Page]](http://weblogs.mozillazine.org/roadmap/nav-commenters.gif)
at October 27, 2005 02:14 AM
I don't suppose you could elaborate some more on ECMAScript 4 details? :) It would be nice if there was some publicly available draft (that's not more than 2 years out of date).
Posted by: Bryant Chen at October 27, 2005 04:31 AM
Regarding "Allowing implementors to bootstrap the language": Are you saying that, for example, that any object that has an apply method can then be used as a function?
var f = {};
f.apply = function (obj, args) {
// do something
};
f();
Would construct be its own method or would that use apply where the obj already has the __proto__ setup?
This seems a lot like Python and Python has proven that this concept works pretty well.
Posted by: Erik Arvidsson at October 27, 2005 07:53 PM
Bryant: we are going to publish drafts shortly, within the next few weeks I hope.
Erik: something like that, but it might have to be called __apply__ to avoid name collisions. ;-)
/be
Posted by: Brendan Eich at October 28, 2005 03:40 PM
Please, could you better explain the part related to "the Macromedia folks" and ActionScript 3?
Posted by: Mauro Di Blasi at October 29, 2005 05:45 AM
Mauro: Macromedia is an ECMA member, because ActionScript at some point became ECMA-262 Edition 3, and then evolved along the lines of Waldemar's JS2/ES4 drafts, but with some changes.
Microsoft also implemented something in JScript.NET based on Waldemar's drafts, but again with some (different from Macromedia's) changes.
Now that ECMA TG1 is back in business with weekly meetings, Edition 4 as a standard seems likely to happen. It obviously cannot be compatible with all three of what Waldemar specified, what Macromedia has already implemented, and what MS has shipped. It should be mostly compatible with Edition 3.
I believe that we have a core group with the right motivations to work quickly, avoid overreach, and deliver a new version that adds more than enough value to be worth its costs in time to market and language complexity.
Posted by: Brendan Eich at October 29, 2005 09:32 PM
I red the following at Macromedia's site:
"What is ActionScript 3.0?
ActionScript 3.0 is a new version of the standards-based language used to access the Flash Player APIs and implement client-side logic for Flash and Flex applications. ActionScript 3.0 is compliant with the ECMAScript Edition 3 (ECMA-262) specification and is targeted to be the reference implementation for ECMAScript Edition 4 (ES4). ActionScript 3.0 also supports the core object W3C standard DOM Level 3 event model."
[http://labs.macromedia.com/technologies/flashplayer8_5/ "Product Details" tab]
Posted by: Mauro Di Blasi at October 30, 2005 01:21 AM
Hrm, Macromedia marketing is getting ahead of itself. AS3.0 cannot be a reference implementation without being open source, in my opinion. Nor can AS3.0 claim to be a reference implementation for ECMA-262 Edition 4, since Edition 4 is not done yet, and won't be for a year.
I'll confer with my TG1 colleagues from Macromedia and see whether this can't be restated.
/be
Posted by: Brendan Eich at October 30, 2005 09:39 PM
I'm not sure that an implementation needs to be open source to be a reference implementation, but it is helpful. I do agree however that it is tough to be a reference implementation of a standard that doesn't exist yet. I've been told that the wording on this page will be revised
Jd
Posted by: Jeff Dyer at October 31, 2005 10:03 AM
I think the spec should be the reference, but this is hard. It requires a checkable spec, which is tantamount to a very slow, more easy to write and read, interpreted implementation. http://www.ccs.neu.edu/home/dherman/javascript/ looks like a good start.
A closed source reference implementation has to be black-box-tested into conformance with the spec, and vice versa. This does not scale well without lots of eyes on the source. And in the real world, it's hard to cover all of the cases with hand-written test suites (you might hope to cover the important cases). Generated and broad-community-created tests help, but without access to source code, debugging and diagnosing take longer.
So being able to read the open source lets a larger set of reviewers and testers check the reference against the spec. But if we have a checkable spec, then I argue we don't need a reference implementation.
/be
Posted by: Brendan Eich at November 3, 2005 03:24 PM
I'm really impressed by the vision, scope, and tone you and shaver express in the Roadmap_Scratchpad wiki page (http://wiki.mozilla.org/Roadmap_Scratchpad)!
Posted by: skierpage at November 3, 2005 07:15 PM
skierpage: thanks, you may be interested in the new post at http://weblogs.mozillazine.org/roadmap/archives/009218.html.
/be
Posted by: Brendan Eich at November 3, 2005 11:26 PM
Too much travel, not enough bloggin.. must eb nice! I am doin' too much blog readin to keep up with everything everyone is doing while they are travelling! Think I'd rather be there live.. maybe next year!
Can't get dinner with skype by doing too much blog reading...
Posted by: Steve at November 17, 2005 07:27 PM
Post a comment
Thanks for signing in, . Now you can comment. (sign out)
(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)