• Like
JSLOL
Upcoming SlideShare
Loading in...5
×

JSLOL

  • 2,561 views
Uploaded on

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.

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.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,561
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
7
Comments
0
Likes
3

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. JSLOL brendan@mozilla.orgTuesday, October 4, 2011
  • 2. JSLOL brendan@mozilla.org • History, goalsTuesday, October 4, 2011
  • 3. JSLOL brendan@mozilla.org • History, goals • ES6, what’s in it?Tuesday, October 4, 2011
  • 4. JSLOL brendan@mozilla.org • History, goals • ES6, what’s in it? • ControversiesTuesday, October 4, 2011
  • 5. JSLOL brendan@mozilla.org • History, goals • ES6, what’s in it? • Controversies • Harmony tune-upTuesday, October 4, 2011
  • 6. JSLOL brendan@mozilla.org • History, goals • ES6, what’s in it? • Controversies • Harmony tune-up • RiverTrail demoTuesday, October 4, 2011
  • 7. A very brief history mozilla 2Tuesday, October 4, 2011
  • 8. A very brief history • Ten days in May 1995: “Mocha”, form validation, img rollovers, scripting of Java mozilla 2Tuesday, 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 2Tuesday, 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 2Tuesday, 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 2Tuesday, 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 2Tuesday, 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 2Tuesday, 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 2Tuesday, 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. 2Tuesday, October 4, 2011
  • 16. The Harmony goals mozilla 3Tuesday, October 4, 2011
  • 17. The Harmony goals • Be a better language for writing: mozilla 3Tuesday, October 4, 2011
  • 18. The Harmony goals • Be a better language for writing: • complex applications mozilla 3Tuesday, October 4, 2011
  • 19. The Harmony goals • Be a better language for writing: • complex applications • libraries (including the DOM) shared by those applications mozilla 3Tuesday, 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 3Tuesday, 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 3Tuesday, 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 3Tuesday, 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 3Tuesday, 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 3Tuesday, October 4, 2011
  • 25. Approved for ES6 mozilla 4Tuesday, October 4, 2011
  • 26. Approved for ES6 • let, const, function in block scope mozilla 4Tuesday, October 4, 2011
  • 27. Approved for ES6 • let, const, function in block scope • destructuring: let {x, y} = pt; let [s, v, o] = triple() mozilla 4Tuesday, 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 4Tuesday, 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 4Tuesday, 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 4Tuesday, 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 4Tuesday, 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 4Tuesday, 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] 4Tuesday, October 4, 2011
  • 34. Yet more approved for ES6 mozilla 5Tuesday, October 4, 2011
  • 35. Yet more approved for ES6 • Binary data: mozilla 5Tuesday, October 4, 2011
  • 36. 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 }); mozilla 5Tuesday, October 4, 2011
  • 37. 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); mozilla 5Tuesday, October 4, 2011
  • 38. 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 } }]); mozilla 5Tuesday, October 4, 2011
  • 39. Quasi-Literals mozilla 6Tuesday, October 4, 2011
  • 40. Quasi-Literals • Injection-safer string interpolation and domain-specific languages mozilla 6Tuesday, 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 6Tuesday, 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 6Tuesday, 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 6Tuesday, 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 6Tuesday, 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` 6Tuesday, October 4, 2011
  • 46. Classes sort of made it, but face existential doubt mozilla 7Tuesday, October 4, 2011
  • 47. Classes sort of made it, but face existential doubt • Sugar for prototypal object pattern, also supports closure patterns: mozilla 7Tuesday, 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 } 7Tuesday, October 4, 2011
  • 49. Triangle (the proto operator) mozilla 8Tuesday, 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 8Tuesday, 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 8Tuesday, October 4, 2011
  • 52. The monocle-mustache operator mozilla 9Tuesday, October 4, 2011
  • 53. The monocle-mustache operator • Inspired by PrototypeJS’s Object.extend mozilla 9Tuesday, October 4, 2011
  • 54. The monocle-mustache operator • Inspired by PrototypeJS’s Object.extend • base.{a:1, b:2} // warning: updates base mozilla 9Tuesday, 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 9Tuesday, 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 9Tuesday, 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 9Tuesday, October 4, 2011
  • 58. Class pattern using triangle-monocle-mustache mozilla 10Tuesday, 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 10Tuesday, October 4, 2011
  • 60. Syntax, yay mozilla 11Tuesday, 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 11Tuesday, 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 11Tuesday, 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 11Tuesday, 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 11Tuesday, 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 11Tuesday, October 4, 2011
  • 66. Not yet in Harmony: arrow function syntax mozilla 12Tuesday, October 4, 2011
  • 67. Not yet in Harmony: arrow function syntax • Arrow function syntax, instead of λ, ƒ, or # (want to save # for later) mozilla 12Tuesday, 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 12Tuesday, 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 12Tuesday, 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 12Tuesday, 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 12Tuesday, 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 12Tuesday, 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] 13Tuesday, 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 14Tuesday, October 4, 2011
  • 75. Syntax, yay again mozilla 15Tuesday, October 4, 2011
  • 76. Syntax, yay again • Do we need shorter function syntax at all? mozilla 15Tuesday, 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 15Tuesday, 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 15Tuesday, 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 15Tuesday, 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 15Tuesday, 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 15Tuesday, October 4, 2011
  • 82. Harmony tune-up mozilla 16Tuesday, October 4, 2011
  • 83. Harmony tune-up • It’s good to question the process as well as the product mozilla 16Tuesday, 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 16Tuesday, 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 16Tuesday, 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 16Tuesday, 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 16Tuesday, October 4, 2011
  • 88. Good news tonight mozilla 17Tuesday, October 4, 2011
  • 89. Good news tonight • ES6 is being drafted mozilla 17Tuesday, October 4, 2011
  • 90. Good news tonight • ES6 is being drafted • It contains lots of awesome already mozilla 17Tuesday, 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 17Tuesday, 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 17Tuesday, 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 17Tuesday, October 4, 2011
  • 94. Help us, pretty/usable syntax pony-corn! mozilla 18Tuesday, October 4, 2011
  • 95. RiverTrail: Parallel JS mozilla 19Tuesday, October 4, 2011
  • 96. RiverTrail: Parallel JS • A ParallelArray library, like typed arrays but immutable. mozilla 19Tuesday, 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 19Tuesday, 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 19Tuesday, 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 19Tuesday, 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 19Tuesday, 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 19Tuesday, 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 20Tuesday, 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 21Tuesday, October 4, 2011
  • 104. Always bet on JSTuesday, 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 fastTuesday, 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 fixedTuesday, 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/GPUTuesday, 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 JSTuesday, October 4, 2011
  • 111. Q&A • @BrendanEich on twitter • brendan@mozilla.org • es-discuss@mozilla.org mozilla 23Tuesday, October 4, 2011