Friday, November 30th, 2007

Brendan Eich: JavaScript 2 evolution and the myth busting Tracing JIT

Category: Presentation

<>p>

I love watching Brendan Eich speak. You know that before long you will be deep into a topic, and if you slip up for a minute you will be hopelessly behind. You have to listen closely. Even if you do, you will probably think that you missed a lot of it.

Brendan has posted his slides on JavaScript 2 and the Open Web as a narrative.

The presentation starts off having a bit of fun with the characters behind the JavaScript 2 debate such as Douglas Crockford (Yoda above). You can argue about the politics of ES4 but the piece I found most interesting was Brendan taking code that is written in current JavaScript, and evolving it via iterations. In fact, I would love to have seen that as the bulk of the talk as it really shows you what JS2 is all about.

Here is the sample webmail code in JS1:

javascript
< view plain text >
  1. function send(msg) {
  2.   validateMessage(msg);
  3.   msg.id = sendToServer(JSON.encode(msg));
  4.   database[msg.id] = msg;
  5. }
  6.  
  7. function fetch() {
  8.   handleMessage(-1);                  // -1 means "get new mail"
  9. }
  10.  
  11. function get(n) {
  12.   if (uint(n) !== n)                  // JS1: n>>>0 === n
  13.       throw new TypeError;
  14.   if (n in database)
  15.       return database[n];
  16.   return handleMessage(n);
  17. }
  18.  
  19. var database = [];
  20.  
  21. function handleMessage(n) {
  22.   let msg = JSON.decode(fetchFromServer(n));
  23.   if (typeof msg != "object")
  24.       throw new TypeError;
  25.   if (msg.result == "no data")
  26.       return null;
  27.   validateMessage(msg);
  28.   return database[msg.id] = msg;
  29. }
  30.  
  31. function validateMessage(msg) {
  32.   function isAddress(a)
  33.       typeof a == "object" && a != null &&
  34.       typeof a.at == "object" && msg != null &&
  35.       typeof a.at[0] == "string" && typeof a.at[1] == "string" &&
  36.       typeof a.name == "string";
  37.   if (!(typeof msg == "object" && msg != null &&
  38.       typeof msg.id == "number" && uint(msg.id) === msg.id &&
  39.       typeof msg.to == "object" && msg != null &&
  40.       msg.to instanceof Array && msg.to.every(isAddress) &&
  41.       isAddress(msg.from) && typeof msg.subject == "string" &&
  42.       typeof msg.body == "string"))
  43.       throw new TypeError;
  44. }

And here it is after a set of evolutionary steps. You will see that this looks like a very different beast. Before you eek, we have to realize that most of the code that will be written won’t be cleaned up like this, but rather hacky JS like we have now.

javascript
< view plain text >
  1. type MsgNoId = {
  2.   to: [Addr], from: Addr, subject: string, body: string
  3. };
  4.  
  5. function send(msg: like MsgNoId) {
  6.   msg.id = sendToServer(JSON.encode(msg));
  7.   database[msg.id] = copyMessage(msg);
  8. }
  9.  
  10. function handleMessage(n) {
  11.   let msg = JSON.decode(fetchFromServer(n));
  12.   if (msg is like { result: string } && msg.result == "no data")
  13.       return null;
  14.   if (msg is like Msg)
  15.       return database[id] = copyMessage(msg);
  16.   throw new TypeError;
  17. }
  18.  
  19. function copyMessage(msg) {
  20.   function newAddr({ at: [user, host], name })
  21.       new Addr([user, host]: [string, string], name);
  22.  
  23.   let { to, from, subject, body, id } = msg;
  24.   return new Msg(to.map(newAddr), newAddr(from), subject, body, id);
  25. }

Another interesting myth that Brendan busted is the notion that:

Optional typing is required to make your applications perform

Tracing JIT

Related Content:

Posted by Dion Almaer at 7:48 am
8 Comments

+++--
3.7 rating from 27 votes

8 Comments »

Comments feed TrackBack URI

In art, typically the art critic, Doug, better understands what the artist, Brendon, has created. I think JS1 is a masterpiece in the style of Jackson Pollack…I am not sure what JS2 is.

Comment by jake — November 30, 2007

The interesting thing about that trace tree JIT is that the authors of the paper claim that they can do a lot better because hot spot (the entire thing is written in java) is generating poor machine code because the their JIT output doesn’t look like normal Java code. What’s also not mentioned in the slides is that the numbers for both rhino and the JIT don’t include time spent in the java runtime (the paper gives the example of 8 seconds of a 15 second run being spent in java setup). This doesn’t mean the numbers are dishonest, just realize that they’re research results and not something that’ll show up in this coming Firefox release.

As for the ES4 changes, I’m not happy with the Java constructs making their way into the language (particularly access contol). On the other hand, I like all the other changes. Just having java-like constructs doesn’t automatically mean importing Java best practices idiocy, right?

Comment by grayrest — November 30, 2007

grayrest: yes, as copiously noted in my blog, “preliminary” “research results” (btw, researchers can’t get published if they don’t work in Java and on HotSpot or Jikes/RVM, sad but true) — but HotSpot’s compilation time is not relevant to runtime, and I noted an x86 back end is under way, which bypasses HotSpot entirely. For Tamarin, we have x86 code generation, just not recast (and simplified) in trace-tree JIT form. That’s the next step.

So, not the next Firefox release — the one after that.

Thanks for mentioning ScreamingMonkey :-).

jake: Jackson Pollack’s abstract expressionism (crap in my book :-|) is far from JS. Anyway software is not purely art. Good ideas and engineering results from programming language history do not all come from Scheme and Self through Doug’s reductionistic filter.

If you can only compare JS1 to a mess of paint, and don’t know what JS2 is, please study some of the links in my blog post — especially the one to Peter Norvig’s presentation on how design patterns, like the ones Doug pushes, are artifacts of language bugs.

/be

Comment by Brendan Eich — November 30, 2007

Dion, you may want a separate item on this: the tutorial on evolutionary programming in ES4 is up at

http://www.ecmascript.org/es4/spec/evolutionary-programming-tutorial.pdf

I didn’t want to fill my talk with code for the audience to squint at — I had to have some geek culture reference fun and screaming monkey attacks too. But this document by Lars Hansen is well worth reading and studying.

/be

Comment by Brendan Eich — November 30, 2007

Apparently I’m a night. I guess that makes me Boba Fett.

Comment by Dustin Diaz — November 30, 2007

Dustin: no, Jedi Knight — Fett was a bounty hunter (scum ;-). I went out of my way to cast you in a positive (but perhaps doomed :-/) role.

/be

Comment by Brendan Eich — November 30, 2007

It depends which episode. Besides, I think we got off on the wrong foot. I will have to post some follow up questions on my blog. I’ll be sure to notify you when they’re up.

Comment by Dustin Diaz — November 30, 2007

I like “like”. It is similar, if not identical, in purpose to my
validate[1], which originally also was called “like” :-) So basically,
when using my lib you can already have some JavaScript2ness right now!
I wonder, if you can use “like” to check functional properties of an
object to get something like interfaces? Anyway, version 2 looks much
shorter and better than version 1, although version 1 could look
much shorter and better when using type checking and validation that
come with my lib. I hope everything works out for JavaScript 2. From
what i can see in the above example, it will support us programmers
more and thus reduce development time and bug numbers.

[1] http://www.cerny-online.com/cerny.js/documentation/schema/schema#validate

Comment by rocer — December 2, 2007

Leave a comment

You must be logged in to post a comment.