118
Capital^H^HolJS [email protected] Sunday, September 18, 2011

Capitol js

Embed Size (px)

DESCRIPTION

My CapitolJS 2011 talk. Firefox add-on source for the Parallel JS demo: http://github.com/RiverTrail/RiverTrail

Citation preview

Page 1: Capitol js

Capital^H^[email protected]

Sunday, September 18, 2011

Page 2: Capitol js

Capital^H^[email protected]

• History, goals

Sunday, September 18, 2011

Page 3: Capitol js

Capital^H^[email protected]

• History, goals

• ES6, what’s in it?

Sunday, September 18, 2011

Page 4: Capitol js

Capital^H^[email protected]

• History, goals

• ES6, what’s in it?

• Dart: I can’t wait!

Sunday, September 18, 2011

Page 5: Capitol js

Capital^H^[email protected]

• History, goals

• ES6, what’s in it?

• Dart: I can’t wait!

• Harmony tune-up

Sunday, September 18, 2011

Page 6: Capitol js

Capital^H^[email protected]

• History, goals

• ES6, what’s in it?

• Dart: I can’t wait!

• Harmony tune-up

• RiverTrail demo

Sunday, September 18, 2011

Page 7: Capitol js

mozilla

A very brief history

2

Sunday, September 18, 2011

Page 8: Capitol js

mozilla

A very brief history

• Ten days in May 1995: “Mocha”, form validation, img rollovers, scripting of Java

2

Sunday, September 18, 2011

Page 9: Capitol js

mozilla

A very brief history

• Ten days in May 1995: “Mocha”, form validation, img rollovers, scripting of Java

• September 1995: “LiveScript” (did Netscape marketing go to Microsoft after?)

2

Sunday, September 18, 2011

Page 10: Capitol js

mozilla

A very brief history

• Ten days in May 1995: “Mocha”, form validation, img rollovers, scripting of Java

• September 1995: “LiveScript” (did Netscape marketing go to Microsoft after?)

• December 1995: “JavaScript”, thanks to Bill Joy (a Sun Founder)

2

Sunday, September 18, 2011

Page 11: Capitol js

mozilla

A very brief history

• Ten days in May 1995: “Mocha”, form validation, img rollovers, scripting of Java

• September 1995: “LiveScript” (did Netscape marketing go to Microsoft after?)

• December 1995: “JavaScript”, thanks to Bill Joy (a Sun Founder)

• 1996-1997: ES1 thanks to ECMA (now Ecma) TC39 -- see my TXJS talk

2

Sunday, September 18, 2011

Page 12: Capitol js

mozilla

A very brief history

• Ten days in May 1995: “Mocha”, form validation, img rollovers, scripting of Java

• September 1995: “LiveScript” (did Netscape marketing go to Microsoft after?)

• December 1995: “JavaScript”, thanks to Bill Joy (a Sun Founder)

• 1996-1997: ES1 thanks to ECMA (now Ecma) TC39 -- see my TXJS talk

• 1999: ES3: function expressions, RegExps, try/catch/finally, switch, do-while

2

Sunday, September 18, 2011

Page 13: Capitol js

mozilla

A very brief history

• Ten days in May 1995: “Mocha”, form validation, img rollovers, scripting of Java

• September 1995: “LiveScript” (did Netscape marketing go to Microsoft after?)

• December 1995: “JavaScript”, thanks to Bill Joy (a Sun Founder)

• 1996-1997: ES1 thanks to ECMA (now Ecma) TC39 -- see my TXJS talk

• 1999: ES3: function expressions, RegExps, try/catch/finally, switch, do-while

• 2005: the Ajax revolution, followed by “The Ajax Experience”

2

Sunday, September 18, 2011

Page 14: Capitol js

mozilla

A very brief history

• Ten days in May 1995: “Mocha”, form validation, img rollovers, scripting of Java

• September 1995: “LiveScript” (did Netscape marketing go to Microsoft after?)

• December 1995: “JavaScript”, thanks to Bill Joy (a Sun Founder)

• 1996-1997: ES1 thanks to ECMA (now Ecma) TC39 -- see my TXJS talk

• 1999: ES3: function expressions, RegExps, try/catch/finally, switch, do-while

• 2005: the Ajax revolution, followed by “The Ajax Experience”

• 2008: ES4 RIP, Harmony founded in July at the Oslo TC39 meeting

2

Sunday, September 18, 2011

Page 15: Capitol js

mozilla

A very brief history

• Ten days in May 1995: “Mocha”, form validation, img rollovers, scripting of Java

• September 1995: “LiveScript” (did Netscape marketing go to Microsoft after?)

• December 1995: “JavaScript”, thanks to Bill Joy (a Sun Founder)

• 1996-1997: ES1 thanks to ECMA (now Ecma) TC39 -- see my TXJS talk

• 1999: ES3: function expressions, RegExps, try/catch/finally, switch, do-while

• 2005: the Ajax revolution, followed by “The Ajax Experience”

• 2008: ES4 RIP, Harmony founded in July at the Oslo TC39 meeting

• 2009: ES5: “use strict”, JSON, Object.create, etc.

2

Sunday, September 18, 2011

Page 16: Capitol js

mozilla

The Harmony goals

3

Sunday, September 18, 2011

Page 17: Capitol js

mozilla

The Harmony goals

• Be a better language for writing:

3

Sunday, September 18, 2011

Page 18: Capitol js

mozilla

The Harmony goals

• Be a better language for writing:

• complex applications

3

Sunday, September 18, 2011

Page 19: Capitol js

mozilla

The Harmony goals

• Be a better language for writing:

• complex applications

• libraries (including the DOM) shared by those applications

3

Sunday, September 18, 2011

Page 20: Capitol js

mozilla

The Harmony goals

• Be a better language for writing:

• complex applications

• libraries (including the DOM) shared by those applications

• code generators targeting the new edition

3

Sunday, September 18, 2011

Page 21: Capitol js

mozilla

The Harmony goals

• Be a better language for writing:

• complex applications

• libraries (including the DOM) shared by those applications

• code generators targeting the new edition

• Better tests, if not a testable (executable) specification

3

Sunday, September 18, 2011

Page 22: Capitol js

mozilla

The Harmony goals

• Be a better language for writing:

• complex applications

• libraries (including the DOM) shared by those applications

• code generators targeting the new edition

• Better tests, if not a testable (executable) specification

• Adopt de facto standards where possible

3

Sunday, September 18, 2011

Page 23: Capitol js

mozilla

The Harmony goals

• Be a better language for writing:

• complex applications

• libraries (including the DOM) shared by those applications

• code generators targeting the new edition

• Better tests, if not a testable (executable) specification

• Adopt de facto standards where possible

• Keep versioning as simple and linear as possible

3

Sunday, September 18, 2011

Page 24: Capitol js

mozilla

The Harmony goals

• Be a better language for writing:

• complex applications

• libraries (including the DOM) shared by those applications

• code generators targeting the new edition

• Better tests, if not a testable (executable) specification

• Adopt de facto standards where possible

• Keep versioning as simple and linear as possible

• Support a statically verifiable, object-capability secure subset

3

Sunday, September 18, 2011

Page 25: Capitol js

mozilla

Approved for ES6

4

Sunday, September 18, 2011

Page 26: Capitol js

mozilla

Approved for ES6

• let, const, function in block scope

4

Sunday, September 18, 2011

Page 27: Capitol js

mozilla

Approved for ES6

• let, const, function in block scope

• destructuring: let {x, y} = pt; let [s, v, o] = triple()

4

Sunday, September 18, 2011

Page 28: Capitol js

mozilla

Approved for ES6

• let, const, function in block scope

• destructuring: let {x, y} = pt; let [s, v, o] = triple()

• parameter default values: function f(x, y=1, z=0) {...}

4

Sunday, September 18, 2011

Page 29: Capitol js

mozilla

Approved for ES6

• let, const, function in block scope

• destructuring: let {x, y} = pt; let [s, v, o] = triple()

• parameter default values: function f(x, y=1, z=0) {...}

• rest, spread: function g(i, j, ...r) { return r.slice(i, j); } let a = [0,1,2,3], o = new any_constructor(...a)

4

Sunday, September 18, 2011

Page 30: Capitol js

mozilla

Approved for ES6

• let, const, function in block scope

• destructuring: let {x, y} = pt; let [s, v, o] = triple()

• parameter default values: function f(x, y=1, z=0) {...}

• rest, spread: function g(i, j, ...r) { return r.slice(i, j); } let a = [0,1,2,3], o = new any_constructor(...a)

• proxies, weak maps: Proxy.create(handler, proto), new WeakMap

4

Sunday, September 18, 2011

Page 31: Capitol js

mozilla

Approved for ES6

• let, const, function in block scope

• destructuring: let {x, y} = pt; let [s, v, o] = triple()

• parameter default values: function f(x, y=1, z=0) {...}

• rest, spread: function g(i, j, ...r) { return r.slice(i, j); } let a = [0,1,2,3], o = new any_constructor(...a)

• proxies, weak maps: Proxy.create(handler, proto), new WeakMap

• modules: module M { export function fast_sin(x) {...} }

4

Sunday, September 18, 2011

Page 32: Capitol js

mozilla

Approved for ES6

• let, const, function in block scope

• destructuring: let {x, y} = pt; let [s, v, o] = triple()

• parameter default values: function f(x, y=1, z=0) {...}

• rest, spread: function g(i, j, ...r) { return r.slice(i, j); } let a = [0,1,2,3], o = new any_constructor(...a)

• proxies, weak maps: Proxy.create(handler, proto), new WeakMap

• modules: module M { export function fast_sin(x) {...} }

• iterators, generators: function* gen() { yield 1; yield 2; }

4

Sunday, September 18, 2011

Page 33: Capitol js

mozilla

Approved for ES6

• let, const, function in block scope

• destructuring: let {x, y} = pt; let [s, v, o] = triple()

• parameter default values: function f(x, y=1, z=0) {...}

• rest, spread: function g(i, j, ...r) { return r.slice(i, j); } let a = [0,1,2,3], o = new any_constructor(...a)

• proxies, weak maps: Proxy.create(handler, proto), new WeakMap

• modules: module M { export function fast_sin(x) {...} }

• iterators, generators: function* gen() { yield 1; yield 2; }

• comprehensions: return [a+b for a of A for b of B]

4

Sunday, September 18, 2011

Page 34: Capitol js

mozilla

Yet more approved for ES6

5

Sunday, September 18, 2011

Page 35: Capitol js

mozilla

Yet more approved for ES6

• Binary data:

5

Sunday, September 18, 2011

Page 36: Capitol js

mozilla

Yet more approved for ES6

• Binary data:

• const Point2D = new StructType({ x: uint32, y: uint32 }), Color = new StructType({ r: uint8, g: uint8, b: uint8 }), Pixel = new StructType({ point: Point2D, color: Color });

5

Sunday, September 18, 2011

Page 37: Capitol js

mozilla

Yet more approved for ES6

• Binary data:

• const Point2D = new StructType({ x: uint32, y: uint32 }), Color = new StructType({ r: uint8, g: uint8, b: uint8 }), Pixel = new StructType({ point: Point2D, color: Color });

• const Triangle = new ArrayType(Pixel, 3);

5

Sunday, September 18, 2011

Page 38: Capitol js

mozilla

Yet more approved for ES6

• Binary data:

• const Point2D = new StructType({ x: uint32, y: uint32 }), Color = new StructType({ r: uint8, g: uint8, b: uint8 }), Pixel = new StructType({ point: Point2D, color: Color });

• const Triangle = new ArrayType(Pixel, 3);

• new Triangle([{ point: { x: 0, y: 0 }, color: { r: 255, g: 255, b: 255 } }, { point: { x: 5, y: 5 }, color: { r: 128, g: 0, b: 0 } }, { point: { x: 10, y: 0 }, color: { r: 0, g: 0, b: 128 } }]);

5

Sunday, September 18, 2011

Page 39: Capitol js

mozilla

Quasi-Literals

6

Sunday, September 18, 2011

Page 40: Capitol js

mozilla

Quasi-Literals

• Injection-safer string interpolation and domain-specific languages

6

Sunday, September 18, 2011

Page 41: Capitol js

mozilla

Quasi-Literals

• Injection-safer string interpolation and domain-specific languages

• Backtick-quoted string desugars to a function call that operates on the literal portions and substitution results:

6

Sunday, September 18, 2011

Page 42: Capitol js

mozilla

Quasi-Literals

• Injection-safer string interpolation and domain-specific languages

• Backtick-quoted string desugars to a function call that operates on the literal portions and substitution results:

• quasi`literalPart1${substitution}literalPart2` desugars to

6

Sunday, September 18, 2011

Page 43: Capitol js

mozilla

Quasi-Literals

• Injection-safer string interpolation and domain-specific languages

• Backtick-quoted string desugars to a function call that operates on the literal portions and substitution results:

• quasi`literalPart1${substitution}literalPart2` desugars to

• quasi({raw: ["literalPart1", "literalPart1"], unescaped: ["literalPart1", "literalPart1"]}, substitution)

6

Sunday, September 18, 2011

Page 44: Capitol js

mozilla

Quasi-Literals

• Injection-safer string interpolation and domain-specific languages

• Backtick-quoted string desugars to a function call that operates on the literal portions and substitution results:

• quasi`literalPart1${substitution}literalPart2` desugars to

• quasi({raw: ["literalPart1", "literalPart1"], unescaped: ["literalPart1", "literalPart1"]}, substitution)

• Multiline string literals w/o prefix: `literalPart1${substitution} (yes, that was a newline!) literalPart2`

6

Sunday, September 18, 2011

Page 45: Capitol js

mozilla

Quasi-Literals

• Injection-safer string interpolation and domain-specific languages

• Backtick-quoted string desugars to a function call that operates on the literal portions and substitution results:

• quasi`literalPart1${substitution}literalPart2` desugars to

• quasi({raw: ["literalPart1", "literalPart1"], unescaped: ["literalPart1", "literalPart1"]}, substitution)

• Multiline string literals w/o prefix: `literalPart1${substitution} (yes, that was a newline!) literalPart2`

• Multiline regexp literals: re`literalPart1${substitution} (yes, that was a newline!) \w+ literalPart2`

6

Sunday, September 18, 2011

Page 46: Capitol js

mozilla

Classes made it, barely (Yay, I think? Why am I sad?)

7

Sunday, September 18, 2011

Page 47: Capitol js

mozilla

Classes made it, barely (Yay, I think? Why am I sad?)

• Sugar for prototypal object pattern, also supports closure patterns:

7

Sunday, September 18, 2011

Page 48: Capitol js

mozilla

Classes made it, barely (Yay, I think? Why am I sad?)

• Sugar for prototypal object pattern, also supports closure patterns:

• class Point { constructor(x, y) { private x = x, y = y; public closed_r() { return Math.sqrt(x*x + y*y); } } get x() { return @x; } get y() { return @y; } equals(p) { return @x === p@x && @y === p@y; } proto_r() { return Math.sqrt(@x * @x + @y * @y); } }

7

Sunday, September 18, 2011

Page 49: Capitol js

mozilla

Classes made it, barely (Yay, I think? Why am I sad?)

• Sugar for prototypal object pattern, also supports closure patterns:

• class Point { constructor(x, y) { private x = x, y = y; public closed_r() { return Math.sqrt(x*x + y*y); } } get x() { return @x; } get y() { return @y; } equals(p) { return @x === p@x && @y === p@y; } proto_r() { return Math.sqrt(@x * @x + @y * @y); } }

• Private member reference syntax (@x, p@x) still up in the air...

7

Sunday, September 18, 2011

Page 50: Capitol js

mozilla

Classes made it, barely (Yay, I think? Why am I sad?)

• Sugar for prototypal object pattern, also supports closure patterns:

• class Point { constructor(x, y) { private x = x, y = y; public closed_r() { return Math.sqrt(x*x + y*y); } } get x() { return @x; } get y() { return @y; } equals(p) { return @x === p@x && @y === p@y; } proto_r() { return Math.sqrt(@x * @x + @y * @y); } }

• Private member reference syntax (@x, p@x) still up in the air...

• extends, prototype, and super work the way you want

7

Sunday, September 18, 2011

Page 51: Capitol js

mozilla

Not yet in Harmony: arrow function syntax

8

Sunday, September 18, 2011

Page 52: Capitol js

mozilla

Not yet in Harmony: arrow function syntax

• Arrow function syntax, instead of λ, ƒ, or # (want to save # for later)

8

Sunday, September 18, 2011

Page 53: Capitol js

mozilla

Not yet in Harmony: arrow function syntax

• Arrow function syntax, instead of λ, ƒ, or # (want to save # for later)

• Just like CoffeeScript: let identity = (x) -> x

8

Sunday, September 18, 2011

Page 54: Capitol js

mozilla

Not yet in Harmony: arrow function syntax

• Arrow function syntax, instead of λ, ƒ, or # (want to save # for later)

• Just like CoffeeScript: let identity = (x) -> x

• Expression body: const square = (x) -> (x * x)

8

Sunday, September 18, 2011

Page 55: Capitol js

mozilla

Not yet in Harmony: arrow function syntax

• Arrow function syntax, instead of λ, ƒ, or # (want to save # for later)

• Just like CoffeeScript: let identity = (x) -> x

• Expression body: const square = (x) -> (x * x)

• Statement body: let countUsed = (str) -> { if (str in usedWords) usedWords[str]++; else usedWords[str] = 1; }

8

Sunday, September 18, 2011

Page 56: Capitol js

mozilla

Not yet in Harmony: arrow function syntax

• Arrow function syntax, instead of λ, ƒ, or # (want to save # for later)

• Just like CoffeeScript: let identity = (x) -> x

• Expression body: const square = (x) -> (x * x)

• Statement body: let countUsed = (str) -> { if (str in usedWords) usedWords[str]++; else usedWords[str] = 1; }

• Fat arrow too: callback = (msg) => ( this.vmail.push(msg) )

8

Sunday, September 18, 2011

Page 57: Capitol js

mozilla

Not yet in Harmony: arrow function syntax

• Arrow function syntax, instead of λ, ƒ, or # (want to save # for later)

• Just like CoffeeScript: let identity = (x) -> x

• Expression body: const square = (x) -> (x * x)

• Statement body: let countUsed = (str) -> { if (str in usedWords) usedWords[str]++; else usedWords[str] = 1; }

• Fat arrow too: callback = (msg) => ( this.vmail.push(msg) )

• Binding forms: let f() -> “writable” const K() -> “readonly”

8

Sunday, September 18, 2011

Page 58: Capitol js

mozilla

Not yet in Harmony: block lambda revival

• Inspired by Smalltalk via Ruby

let empty = {||}; // no need for space between bars

assert(empty() === undefined); assert(typeof empty === "function"); // native and implements [[Call]] assert(empty.length === 0);  let identity = {|x| x}; // completion is return value  assert(identity(42) === 42); assert(identity.length === 1);  let a = [1, 2, 3, 4]; let b = a.map {|e| e * e} // paren-free call with block is // idiomatic control structure so // no semicolon at end

print(b); // [1, 4, 9, 16]

9

Sunday, September 18, 2011

Page 59: Capitol js

mozilla

More block lambda revival

• Paren-free calls, control effects: you know you want it...

10

b = a.map {|e| // newline in block ok e * e * e} // newline after ends call function find_first_odd(a) { a.forEach { |e, i| if (e & 1) return i; } // returns from function return -1;} function escape_return() { return {|e| return e};}b = escape_return();try { b(42); } catch (e) {} // error, return from // inactive function

Sunday, September 18, 2011

Page 60: Capitol js

mozilla

Syntax, yay

11

Sunday, September 18, 2011

Page 61: Capitol js

mozilla

Syntax, yay

• Do we need shorter function syntax at all?

11

Sunday, September 18, 2011

Page 62: Capitol js

mozilla

Syntax, yay

• Do we need shorter function syntax at all?

• Some say no. @mikeal: “I got 99 problems and JavaScript syntax ain’t one.”

11

Sunday, September 18, 2011

Page 63: Capitol js

mozilla

Syntax, yay

• Do we need shorter function syntax at all?

• Some say no. @mikeal: “I got 99 problems and JavaScript syntax ain’t one.”

• Others say yes, but divide into roughly three camps:

11

Sunday, September 18, 2011

Page 64: Capitol js

mozilla

Syntax, yay

• Do we need shorter function syntax at all?

• Some say no. @mikeal: “I got 99 problems and JavaScript syntax ain’t one.”

• Others say yes, but divide into roughly three camps:

• Arrow function syntax, as in CoffeeScript.

11

Sunday, September 18, 2011

Page 65: Capitol js

mozilla

Syntax, yay

• Do we need shorter function syntax at all?

• Some say no. @mikeal: “I got 99 problems and JavaScript syntax ain’t one.”

• Others say yes, but divide into roughly three camps:

• Arrow function syntax, as in CoffeeScript.

• Block lambdas. @jashkenas: “For the record, I too favor [block lambdas] if arrows in JS will need curlies to delimit blocks. Curlies or arrows, not both.”

11

Sunday, September 18, 2011

Page 66: Capitol js

mozilla

Syntax, yay

• Do we need shorter function syntax at all?

• Some say no. @mikeal: “I got 99 problems and JavaScript syntax ain’t one.”

• Others say yes, but divide into roughly three camps:

• Arrow function syntax, as in CoffeeScript.

• Block lambdas. @jashkenas: “For the record, I too favor [block lambdas] if arrows in JS will need curlies to delimit blocks. Curlies or arrows, not both.”

• Some leading ugly character, maybe \ -- unsure about this, return.

11

Sunday, September 18, 2011

Page 67: Capitol js

Dart to the heart

Sunday, September 18, 2011

Page 68: Capitol js

Dart to the heart• Some things I’ve heard & read

Sunday, September 18, 2011

Page 69: Capitol js

Dart to the heart• Some things I’ve heard & read

• “If JavaScript does not have {classes, “guards”}, then it will be REPLACED!” [May 2010 TC39 meeting]

Sunday, September 18, 2011

Page 70: Capitol js

Dart to the heart• Some things I’ve heard & read

• “If JavaScript does not have {classes, “guards”}, then it will be REPLACED!” [May 2010 TC39 meeting]

• “better performance profile”

Sunday, September 18, 2011

Page 71: Capitol js

Dart to the heart• Some things I’ve heard & read

• “If JavaScript does not have {classes, “guards”}, then it will be REPLACED!” [May 2010 TC39 meeting]

• “better performance profile”

• “amenable to tooling”, “(e.g. with optional types)”

Sunday, September 18, 2011

Page 72: Capitol js

Dart to the heart• Some things I’ve heard & read

• “If JavaScript does not have {classes, “guards”}, then it will be REPLACED!” [May 2010 TC39 meeting]

• “better performance profile”

• “amenable to tooling”, “(e.g. with optional types)”

• “Fundamental problems [like the] single Number primitive....”

Sunday, September 18, 2011

Page 73: Capitol js

mozilla

iOS, lolwut?

13

Sunday, September 18, 2011

Page 74: Capitol js

mozilla

iOS, lolwut?

• Leaked memo: “The emergence of compelling alternative platforms like iOS has meant that the web platform must compete on its merits, not just its reach.”

13

Sunday, September 18, 2011

Page 75: Capitol js

mozilla

iOS, lolwut?

• Leaked memo: “The emergence of compelling alternative platforms like iOS has meant that the web platform must compete on its merits, not just its reach.”

• m-k-s on Hacker News: “If they think per the leaked mail that devs are choosing iOS over browsers because of JS, they have their heads in the sand.

Those choices are happening due to iOS as a platform not because devs are somehow so much more happier learning/using Objective-C! The best thing that Google could do is to KEEP working hard on improving the browser platform.”

13

Sunday, September 18, 2011

Page 76: Capitol js

mozilla

Food for thought

14

Sunday, September 18, 2011

Page 77: Capitol js

mozilla

Food for thought

• The “REPLACED” threat and “optional types” suggest either

14

Sunday, September 18, 2011

Page 78: Capitol js

mozilla

Food for thought

• The “REPLACED” threat and “optional types” suggest either

• Optional static types a la Strongtalk [Bracha & Griswold]

14

Sunday, September 18, 2011

Page 79: Capitol js

mozilla

Food for thought

• The “REPLACED” threat and “optional types” suggest either

• Optional static types a la Strongtalk [Bracha & Griswold]

• Optional runtime guards, as proposed for Harmony but not in ES6

14

Sunday, September 18, 2011

Page 80: Capitol js

mozilla

Food for thought

• The “REPLACED” threat and “optional types” suggest either

• Optional static types a la Strongtalk [Bracha & Griswold]

• Optional runtime guards, as proposed for Harmony but not in ES6

• Syntax: let i :: int = 0; function f(a :: G)...

14

Sunday, September 18, 2011

Page 81: Capitol js

mozilla

Food for thought

• The “REPLACED” threat and “optional types” suggest either

• Optional static types a la Strongtalk [Bracha & Griswold]

• Optional runtime guards, as proposed for Harmony but not in ES6

• Syntax: let i :: int = 0; function f(a :: G)...

• Semantics are runtime-pluggable, tie into trademarks proposal (nominal)

14

Sunday, September 18, 2011

Page 82: Capitol js

mozilla

Food for thought

• The “REPLACED” threat and “optional types” suggest either

• Optional static types a la Strongtalk [Bracha & Griswold]

• Optional runtime guards, as proposed for Harmony but not in ES6

• Syntax: let i :: int = 0; function f(a :: G)...

• Semantics are runtime-pluggable, tie into trademarks proposal (nominal)

• Proposals came at last minute (May TC39 meeting), not ready for ES6

14

Sunday, September 18, 2011

Page 83: Capitol js

mozilla

Food for thought

• The “REPLACED” threat and “optional types” suggest either

• Optional static types a la Strongtalk [Bracha & Griswold]

• Optional runtime guards, as proposed for Harmony but not in ES6

• Syntax: let i :: int = 0; function f(a :: G)...

• Semantics are runtime-pluggable, tie into trademarks proposal (nominal)

• Proposals came at last minute (May TC39 meeting), not ready for ES6

• Why not int32, int64, bignum, as well as number (double)?

14

Sunday, September 18, 2011

Page 84: Capitol js

mozilla

The trouble with numbers

15

Sunday, September 18, 2011

Page 85: Capitol js

mozilla

The trouble with numbers

• How to introduce a sane numeric tower for JS?

15

Sunday, September 18, 2011

Page 86: Capitol js

mozilla

The trouble with numbers

• How to introduce a sane numeric tower for JS?

• Suffixes: 4294967295u + 1 === 0u,

2147483647i + 1 === -2147483648i; // WTF!

15

Sunday, September 18, 2011

Page 87: Capitol js

mozilla

The trouble with numbers

• How to introduce a sane numeric tower for JS?

• Suffixes: 4294967295u + 1 === 0u,

2147483647i + 1 === -2147483648i; // WTF!

• Promotion rules as in C, but with dynamic types

15

Sunday, September 18, 2011

Page 88: Capitol js

mozilla

The trouble with numbers

• How to introduce a sane numeric tower for JS?

• Suffixes: 4294967295u + 1 === 0u,

2147483647i + 1 === -2147483648i; // WTF!

• Promotion rules as in C, but with dynamic types

• This smells like trouble

15

Sunday, September 18, 2011

Page 89: Capitol js

mozilla

The trouble with numbers

• How to introduce a sane numeric tower for JS?

• Suffixes: 4294967295u + 1 === 0u,

2147483647i + 1 === -2147483648i; // WTF!

• Promotion rules as in C, but with dynamic types

• This smells like trouble

• Better: use bignum arithmetic; use int arithmetic; etc.

15

Sunday, September 18, 2011

Page 90: Capitol js

mozilla

Better performance predictability

16

Sunday, September 18, 2011

Page 91: Capitol js

mozilla

Better performance predictability

• JS engines currently have performance predictability problems, it’s true

16

Sunday, September 18, 2011

Page 92: Capitol js

mozilla

Better performance predictability

• JS engines currently have performance predictability problems, it’s true

• Speculation can go wrong, fall back on slow paths

16

Sunday, September 18, 2011

Page 93: Capitol js

mozilla

Better performance predictability

• JS engines currently have performance predictability problems, it’s true

• Speculation can go wrong, fall back on slow paths

• Array holes, prototype properties being deleted, unshadowing/fore-shadowing all hurt a bit

16

Sunday, September 18, 2011

Page 94: Capitol js

mozilla

Better performance predictability

• JS engines currently have performance predictability problems, it’s true

• Speculation can go wrong, fall back on slow paths

• Array holes, prototype properties being deleted, unshadowing/fore-shadowing all hurt a bit

• But JS engines are still improving rapidly (e.g. the SpiderMonkey Type Inference work by Brian Hackett)

16

Sunday, September 18, 2011

Page 95: Capitol js

mozilla

Better performance predictability

• JS engines currently have performance predictability problems, it’s true

• Speculation can go wrong, fall back on slow paths

• Array holes, prototype properties being deleted, unshadowing/fore-shadowing all hurt a bit

• But JS engines are still improving rapidly (e.g. the SpiderMonkey Type Inference work by Brian Hackett)

• It’s way too soon to throw in the towel

16

Sunday, September 18, 2011

Page 96: Capitol js

mozilla

Better performance predictability

• JS engines currently have performance predictability problems, it’s true

• Speculation can go wrong, fall back on slow paths

• Array holes, prototype properties being deleted, unshadowing/fore-shadowing all hurt a bit

• But JS engines are still improving rapidly (e.g. the SpiderMonkey Type Inference work by Brian Hackett)

• It’s way too soon to throw in the towel

• We could add more opt-into-high-performance knobs, but: No.

16

Sunday, September 18, 2011

Page 97: Capitol js

mozilla

Harmony tune-up

17

Sunday, September 18, 2011

Page 98: Capitol js

mozilla

Harmony tune-up

• It’s good to question the process

17

Sunday, September 18, 2011

Page 99: Capitol js

mozilla

Harmony tune-up

• It’s good to question the process

• Harmony is both conservative (consensus is hard to achieve) and path-dependent (because macro research takes time, we’re adding syntactic special forms that could be macros -- if only we had macros)

17

Sunday, September 18, 2011

Page 100: Capitol js

mozilla

Harmony tune-up

• It’s good to question the process

• Harmony is both conservative (consensus is hard to achieve) and path-dependent (because macro research takes time, we’re adding syntactic special forms that could be macros -- if only we had macros)

• Should we take the Dart clues to heart, without over-reacting?

17

Sunday, September 18, 2011

Page 101: Capitol js

mozilla

Harmony tune-up

• It’s good to question the process

• Harmony is both conservative (consensus is hard to achieve) and path-dependent (because macro research takes time, we’re adding syntactic special forms that could be macros -- if only we had macros)

• Should we take the Dart clues to heart, without over-reacting?

• My suggestion is to prototype in SpiderMonkey and V8 some of the strawman proposals that did not make ES6 now, and see if any deserve promotion to ES6

17

Sunday, September 18, 2011

Page 102: Capitol js

mozilla

RiverTrail: Parallel JS

18

Sunday, September 18, 2011

Page 103: Capitol js

mozilla

RiverTrail: Parallel JS

• A ParallelArray library, like typed arrays but immutable.

18

Sunday, September 18, 2011

Page 104: Capitol js

mozilla

RiverTrail: Parallel JS

• A ParallelArray library, like typed arrays but immutable.

• map, reduce, combine, filter, partition, scan, scatter -- all produce fresh ParallelArray results

18

Sunday, September 18, 2011

Page 105: Capitol js

mozilla

RiverTrail: Parallel JS

• A ParallelArray library, like typed arrays but immutable.

• map, reduce, combine, filter, partition, scan, scatter -- all produce fresh ParallelArray results

• Relies on commutativity to parallelize arithmetic operations (this does inject some f.p. non-determinism).

18

Sunday, September 18, 2011

Page 106: Capitol js

mozilla

RiverTrail: Parallel JS

• A ParallelArray library, like typed arrays but immutable.

• map, reduce, combine, filter, partition, scan, scatter -- all produce fresh ParallelArray results

• Relies on commutativity to parallelize arithmetic operations (this does inject some f.p. non-determinism).

• A Firefox add-on that runs a Narcissus-based JS-to-OpenCL compiler over ParallelArray code

18

Sunday, September 18, 2011

Page 107: Capitol js

mozilla

RiverTrail: Parallel JS

• A ParallelArray library, like typed arrays but immutable.

• map, reduce, combine, filter, partition, scan, scatter -- all produce fresh ParallelArray results

• Relies on commutativity to parallelize arithmetic operations (this does inject some f.p. non-determinism).

• A Firefox add-on that runs a Narcissus-based JS-to-OpenCL compiler over ParallelArray code

• Source: github.com/RiverTrail/RiverTrail (user id should’ve been IntelLabs)

18

Sunday, September 18, 2011

Page 108: Capitol js

mozilla

RiverTrail: Parallel JS

• A ParallelArray library, like typed arrays but immutable.

• map, reduce, combine, filter, partition, scan, scatter -- all produce fresh ParallelArray results

• Relies on commutativity to parallelize arithmetic operations (this does inject some f.p. non-determinism).

• A Firefox add-on that runs a Narcissus-based JS-to-OpenCL compiler over ParallelArray code

• Source: github.com/RiverTrail/RiverTrail (user id should’ve been IntelLabs)

• Demo code is funny: it contains a "DO NOT use strict”; directive!

18

Sunday, September 18, 2011

Page 109: Capitol js

mozilla

RiverTrail demo sample code

• the ParallelArray constructor builds on typed arrays:

NBody.private.initVel = new Array(numBodies);

NBody.private.initVelTA = new Float32Array(numBodies * 4);

var initAsteroidPos = new Array(50);

for (i = 0; i < 50; i++) {    initAsteroidPos[i] = new ParallelArray([                                            NBody.private.posTA[i * 3 + 0],     // x                                            NBody.private.posTA[i * 3 + 1],                                            NBody.private.posTA[i * 3 + 2],                                            ]); }  . . . NBody.private.asteroidPos = new ParallelArray(Float32Array, initAsteroidPos);  . . . NBody.private.vel = new ParallelArray(Float32Array, NBody.private.initVel);

19

Sunday, September 18, 2011

Page 110: Capitol js

mozilla

ParallelArray methods in action

• combine method is a workhorse (takes variable number of args)

"animateTickParallel": function animateTickParallel() {

    // increment (+=) velocity by acceleration    var newVel = NBody.private.vel.combine(                  1,                     low_precision(NBody.bodyVelocityLoopified),                     NBody.private.pos,                     numBodies,                     NBody.Constant.deltaTime,                     NBody.Constant.epsSqr,                     NBody.time,                     NBody.private.asteroidPos                 );  . . .

20

Sunday, September 18, 2011

Page 111: Capitol js

Always bet on JS

Sunday, September 18, 2011

Page 112: Capitol js

Always bet on JS• First they said JS couldn’t be useful

for buildling “rich Internet apps”

Sunday, September 18, 2011

Page 113: Capitol js

Always bet on JS• First they said JS couldn’t be useful

for buildling “rich Internet apps”

• Then they said it couldn’t be fast

Sunday, September 18, 2011

Page 114: Capitol js

Always bet on JS• First they said JS couldn’t be useful

for buildling “rich Internet apps”

• Then they said it couldn’t be fast

• Then they said it couldn’t be fixed

Sunday, September 18, 2011

Page 115: Capitol js

Always bet on JS• First they said JS couldn’t be useful

for buildling “rich Internet apps”

• Then they said it couldn’t be fast

• Then they said it couldn’t be fixed

• Then it couldn’t do multicore/GPU

Sunday, September 18, 2011

Page 116: Capitol js

Always bet on JS• First they said JS couldn’t be useful

for buildling “rich Internet apps”

• Then they said it couldn’t be fast

• Then they said it couldn’t be fixed

• Then it couldn’t do multicore/GPU

• Wrong every time!

Sunday, September 18, 2011

Page 117: Capitol js

Always bet on JS• First they said JS couldn’t be useful

for buildling “rich Internet apps”

• Then they said it couldn’t be fast

• Then they said it couldn’t be fixed

• Then it couldn’t do multicore/GPU

• Wrong every time!

• My advice: always bet on JS

Sunday, September 18, 2011