My JSConf.eu presentation. Some recycling from CapitolJS, but new stuff in the middle on ES6 special forms triangle, monocle-mustache, classes (syntax in progress), and how the JS community can help.
7. A very brief history
mozilla
2
Tuesday, October 4, 2011
8. A very brief history
• Ten days in May 1995: “Mocha”, form validation, img rollovers, scripting of Java
mozilla
2
Tuesday, October 4, 2011
9. 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?)
mozilla
2
Tuesday, October 4, 2011
10. 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)
mozilla
2
Tuesday, October 4, 2011
11. 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
mozilla
2
Tuesday, October 4, 2011
12. 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
mozilla
2
Tuesday, October 4, 2011
13. 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”
mozilla
2
Tuesday, October 4, 2011
14. 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
mozilla
2
Tuesday, October 4, 2011
15. 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
mozilla
• 2009: ES5: “use strict”, JSON, Object.create, etc.
2
Tuesday, October 4, 2011
17. The Harmony goals
• Be a better language for writing:
mozilla
3
Tuesday, October 4, 2011
18. The Harmony goals
• Be a better language for writing:
• complex applications
mozilla
3
Tuesday, October 4, 2011
19. The Harmony goals
• Be a better language for writing:
• complex applications
• libraries (including the DOM) shared by those applications
mozilla
3
Tuesday, October 4, 2011
20. 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
mozilla
3
Tuesday, October 4, 2011
21. 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
mozilla
3
Tuesday, October 4, 2011
22. 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
mozilla
3
Tuesday, October 4, 2011
23. 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
mozilla
3
Tuesday, October 4, 2011
24. 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 subset mozilla
3
Tuesday, October 4, 2011
26. Approved for ES6
• let, const, function in block scope
mozilla
4
Tuesday, October 4, 2011
27. Approved for ES6
• let, const, function in block scope
• destructuring: let {x, y} = pt; let [s, v, o] = triple()
mozilla
4
Tuesday, October 4, 2011
28. 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=2, w=3}) {...}
mozilla
4
Tuesday, October 4, 2011
29. 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=2, w=3}) {...}
• rest, spread: function g(i, j, ...r) { return r.slice(i, j); }
let a = [0, 1, 2, 3],
o = new any_constructor(...a)
mozilla
4
Tuesday, October 4, 2011
30. 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=2, w=3}) {...}
• 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
mozilla
4
Tuesday, October 4, 2011
31. 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=2, w=3}) {...}
• 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) {...} }
mozilla
4
Tuesday, October 4, 2011
32. 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=2, w=3}) {...}
• 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; }
mozilla
4
Tuesday, October 4, 2011
33. 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=2, w=3}) {...}
• 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; }
mozilla
• comprehensions: return [x+y for x of a for y of b]
4
Tuesday, October 4, 2011
40. Quasi-Literals
• Injection-safer string interpolation and domain-specific languages
mozilla
6
Tuesday, October 4, 2011
41. 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:
mozilla
6
Tuesday, October 4, 2011
42. 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
mozilla
6
Tuesday, October 4, 2011
43. 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"],
cooked: ["literalPart1", "literalPart1"]},
substitution)
mozilla
6
Tuesday, October 4, 2011
44. 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"],
cooked: ["literalPart1", "literalPart1"]},
substitution)
• Multiline string literals w/o prefix: `literalPart1${substitution}
(yes, that was a newline!) literalPart2`
mozilla
6
Tuesday, October 4, 2011
45. 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"],
cooked: ["literalPart1", "literalPart1"]},
substitution)
• Multiline string literals w/o prefix: `literalPart1${substitution}
(yes, that was a newline!) literalPart2`
mozilla
• Multiline regexp literals: re`literalPart1${substitution}
(yes, that was a newline!) w+ literalPart2`
6
Tuesday, October 4, 2011
46. Classes sort of made it, but face existential doubt
mozilla
7
Tuesday, October 4, 2011
47. Classes sort of made it, but face existential doubt
• Sugar for prototypal object pattern, also supports closure patterns:
mozilla
7
Tuesday, October 4, 2011
48. Classes sort of made it, but face existential doubt
• Sugar for prototypal object pattern, also supports closure patterns:
• const px = Name.create(‘x’), py = Name.create(‘y’);
class Point extends Base {
constructor(x, y) {
super();
this[px] = x, this[py] = y;
this.r = function() { return Math.sqrt(x*x + y*y); }
}
get x() { return this[px]; }
get y() { return this[py]; }
proto_r() { return Math.sqrt(this[px] * this[px] +
this[py] * this[py]); }
equals(p) { return this[px] === p[px] &&
this[py] === p[py]; } mozilla
}
7
Tuesday, October 4, 2011
50. Triangle (the proto operator)
• Instead of var obj = {__proto__: base, a: 1, b: 2}, use
let obj = base <| {a: 1, b: 2}
mozilla
8
Tuesday, October 4, 2011
51. Triangle (the proto operator)
• Instead of var obj = {__proto__: base, a: 1, b: 2}, use
let obj = base <| {a: 1, b: 2}
• Works for other literal object forms:
let arr = base <| [p, q, r]
let fun = base <| function (...args) { ... }
let re = base <| /(w+)s+(w)+/g
mozilla
8
Tuesday, October 4, 2011
54. The monocle-mustache operator
• Inspired by PrototypeJS’s Object.extend
• base.{a:1, b:2} // warning: updates base
mozilla
9
Tuesday, October 4, 2011
55. The monocle-mustache operator
• Inspired by PrototypeJS’s Object.extend
• base.{a:1, b:2} // warning: updates base
• Copies all “own” right-hand-side properties (including private names) to base
mozilla
9
Tuesday, October 4, 2011
56. The monocle-mustache operator
• Inspired by PrototypeJS’s Object.extend
• base.{a:1, b:2} // warning: updates base
• Copies all “own” right-hand-side properties (including private names) to base
• Should it generate a fresh value instead of mutating?
let obj = base.{a:1, b:2}
mozilla
9
Tuesday, October 4, 2011
57. The monocle-mustache operator
• Inspired by PrototypeJS’s Object.extend
• base.{a:1, b:2} // warning: updates base
• Copies all “own” right-hand-side properties (including private names) to base
• Should it generate a fresh value instead of mutating?
let obj = base.{a:1, b:2}
• Or if we want Prototype-style update, should it look like an assignment op?
base .= {a:1, b:2}
mozilla
9
Tuesday, October 4, 2011
58. Class pattern using triangle-monocle-mustache
mozilla
10
Tuesday, October 4, 2011
59. Class pattern using triangle-monocle-mustache
• const px = Name.create(‘x’), py = Name.create(‘y’);
let Point = Base <| function (x, y) {
super();
this[px] = x, this[py] = y;
this.r = function() { return Math.sqrt(x*x + y*y); }
}.prototype.{
get x() { return this[px]; },
get y() { return this[py]; },
proto_r() { return Math.sqrt(this[px] * this[px] +
this[py] * this[py]); },
equals(p) { return this[px] === p[px] &&
this[py] === p[py]; }
}.constructor.{
allPoints: [] // class “static” property!
} mozilla
10
Tuesday, October 4, 2011
60. Syntax, yay
mozilla
11
Tuesday, October 4, 2011
61. Syntax, yay
• Do we want class syntax, or triangle-monocle-mustache -- or triangle-monocle-
equals-mustache? (triangle-monocle-long-nose-mustache?!)
mozilla
11
Tuesday, October 4, 2011
62. Syntax, yay
• Do we want class syntax, or triangle-monocle-mustache -- or triangle-monocle-
equals-mustache? (triangle-monocle-long-nose-mustache?!)
• CoffeeScript has class as sugar for the prototypal pattern -- why can’t JS?
mozilla
11
Tuesday, October 4, 2011
63. Syntax, yay
• Do we want class syntax, or triangle-monocle-mustache -- or triangle-monocle-
equals-mustache? (triangle-monocle-long-nose-mustache?!)
• CoffeeScript has class as sugar for the prototypal pattern -- why can’t JS?
• Using funny operators is error prone and (to some, in some fonts) ugly
mozilla
11
Tuesday, October 4, 2011
64. Syntax, yay
• Do we want class syntax, or triangle-monocle-mustache -- or triangle-monocle-
equals-mustache? (triangle-monocle-long-nose-mustache?!)
• CoffeeScript has class as sugar for the prototypal pattern -- why can’t JS?
• Using funny operators is error prone and (to some, in some fonts) ugly
• TC39, even with the “champions” model, falls into bikeshedding if the syntax is
not super-awesome from the start
mozilla
11
Tuesday, October 4, 2011
65. Syntax, yay
• Do we want class syntax, or triangle-monocle-mustache -- or triangle-monocle-
equals-mustache? (triangle-monocle-long-nose-mustache?!)
• CoffeeScript has class as sugar for the prototypal pattern -- why can’t JS?
• Using funny operators is error prone and (to some, in some fonts) ugly
• TC39, even with the “champions” model, falls into bikeshedding if the syntax is
not super-awesome from the start
• Should we have a world-wide syntax beauty contest?
mozilla
11
Tuesday, October 4, 2011
66. Not yet in Harmony: arrow function syntax
mozilla
12
Tuesday, October 4, 2011
67. Not yet in Harmony: arrow function syntax
• Arrow function syntax, instead of λ, ƒ, or # (want to save # for later)
mozilla
12
Tuesday, October 4, 2011
68. 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
mozilla
12
Tuesday, October 4, 2011
69. 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)
mozilla
12
Tuesday, October 4, 2011
70. 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;
}
mozilla
12
Tuesday, October 4, 2011
71. 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) )
mozilla
12
Tuesday, October 4, 2011
72. 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” mozilla
12
Tuesday, October 4, 2011
73. 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
mozilla
print(b); // [1, 4, 9, 16]
13
Tuesday, October 4, 2011
74. More block lambda revival
• Paren-free calls, control effects: you know you want it...
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
mozilla
14
Tuesday, October 4, 2011
76. Syntax, yay again
• Do we need shorter function syntax at all?
mozilla
15
Tuesday, October 4, 2011
77. Syntax, yay again
• Do we need shorter function syntax at all?
• Some say no. @mikeal: “I got 99 problems and JavaScript syntax ain’t one.”
mozilla
15
Tuesday, October 4, 2011
78. Syntax, yay again
• 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:
mozilla
15
Tuesday, October 4, 2011
79. Syntax, yay again
• 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.
mozilla
15
Tuesday, October 4, 2011
80. Syntax, yay again
• 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.”
mozilla
15
Tuesday, October 4, 2011
81. Syntax, yay again
• 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.
mozilla
15
Tuesday, October 4, 2011
83. Harmony tune-up
• It’s good to question the process as well as the product
mozilla
16
Tuesday, October 4, 2011
84. Harmony tune-up
• It’s good to question the process as well as the product
• Harmony is both conservative (consensus is hard to achieve) and path-
dependent (e.g., because macro research takes time, we’re adding syntactic
special forms that could be macros -- if only we had macros)
mozilla
16
Tuesday, October 4, 2011
85. Harmony tune-up
• It’s good to question the process as well as the product
• Harmony is both conservative (consensus is hard to achieve) and path-
dependent (e.g., because macro research takes time, we’re adding syntactic
special forms that could be macros -- if only we had macros)
• Should we take Dart to heart, without over-reacting? I can’t wait!
mozilla
16
Tuesday, October 4, 2011
86. Harmony tune-up
• It’s good to question the process as well as the product
• Harmony is both conservative (consensus is hard to achieve) and path-
dependent (e.g., because macro research takes time, we’re adding syntactic
special forms that could be macros -- if only we had macros)
• Should we take Dart to heart, without over-reacting? I can’t wait!
• One idea 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
mozilla
16
Tuesday, October 4, 2011
87. Harmony tune-up
• It’s good to question the process as well as the product
• Harmony is both conservative (consensus is hard to achieve) and path-
dependent (e.g., because macro research takes time, we’re adding syntactic
special forms that could be macros -- if only we had macros)
• Should we take Dart to heart, without over-reacting? I can’t wait!
• One idea 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
• Prototyping is hard. We could use help from the community...
mozilla
16
Tuesday, October 4, 2011
89. Good news tonight
• ES6 is being drafted
mozilla
17
Tuesday, October 4, 2011
90. Good news tonight
• ES6 is being drafted
• It contains lots of awesome already
mozilla
17
Tuesday, October 4, 2011
91. Good news tonight
• ES6 is being drafted
• It contains lots of awesome already
• Prototyping in SpiderMonkey and V8 is ongoing, so we’ll actually implementor-
and user-test before finalizing the spec
mozilla
17
Tuesday, October 4, 2011
92. Good news tonight
• ES6 is being drafted
• It contains lots of awesome already
• Prototyping in SpiderMonkey and V8 is ongoing, so we’ll actually implementor-
and user-test before finalizing the spec
• Even if we cut a few things -- still awesome
mozilla
17
Tuesday, October 4, 2011
93. Good news tonight
• ES6 is being drafted
• It contains lots of awesome already
• Prototyping in SpiderMonkey and V8 is ongoing, so we’ll actually implementor-
and user-test before finalizing the spec
• Even if we cut a few things -- still awesome
• Help us find the prettiest and most usable syntax
mozilla
17
Tuesday, October 4, 2011
96. RiverTrail: Parallel JS
• A ParallelArray library, like typed arrays but immutable.
mozilla
19
Tuesday, October 4, 2011
97. RiverTrail: Parallel JS
• A ParallelArray library, like typed arrays but immutable.
• map, reduce, combine, filter, partition, scan, scatter -- all produce fresh
ParallelArray results
mozilla
19
Tuesday, October 4, 2011
98. 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 associativity to parallelize arithmetic operations (this does inject
some f.p. non-determinism).
mozilla
19
Tuesday, October 4, 2011
99. 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 associativity 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
mozilla
19
Tuesday, October 4, 2011
100. 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 associativity 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)
mozilla
19
Tuesday, October 4, 2011
101. 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 associativity 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! mozilla
19
Tuesday, October 4, 2011
102. 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);
mozilla
20
Tuesday, October 4, 2011
103. 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
);
. . . mozilla
21
Tuesday, October 4, 2011
105. Always bet on JS
• First they said JS couldn’t be useful
for building “rich Internet apps”
Tuesday, October 4, 2011
106. Always bet on JS
• First they said JS couldn’t be useful
for building “rich Internet apps”
• Then they said it couldn’t be fast
Tuesday, October 4, 2011
107. Always bet on JS
• First they said JS couldn’t be useful
for building “rich Internet apps”
• Then they said it couldn’t be fast
• Then they said it couldn’t be fixed
Tuesday, October 4, 2011
108. Always bet on JS
• First they said JS couldn’t be useful
for building “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
Tuesday, October 4, 2011
109. Always bet on JS
• First they said JS couldn’t be useful
for building “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!
Tuesday, October 4, 2011
110. Always bet on JS
• First they said JS couldn’t be useful
for building “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
Tuesday, October 4, 2011
111. Q&A
• @BrendanEich on twitter
• brendan@mozilla.org
• es-discuss@mozilla.org
mozilla
23
Tuesday, October 4, 2011