Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The State of JavaScript - Brendan Eich

brendaneich.github.com

Post reply on HN
Print view View original

121–130 of 266 posts

Re: The State of JavaScript - Brendan Eich

#121

Post by haberman »

bzbarsky wrote: post #113
haberman wrote: post #14

> NaCl? Not portable. To dis NaCl on this basis and not even mention PNaCl is dishonest. http://www.chromium.org/nativeclient/pnacl/building-and-test... > Defined by implementation. As it should be, until the implementation settles and it's clear what interfaces should be standardized. What a waste of time it would have been to standardize the pre-PNaCl work, for example. I wouldn't expect Rust (for example) to be st…

Taking your points one at a time: 1) If PNaCl ever happens and is not directly tied to Chrome's internals (which it is at the moment), the discussion can be revisited. 2) Google is opposed to anyone else being more involved in the process. Other people have tried. 3) Mozilla has no particular concerns about "losing face" if a pragmatic decision is needed. We're a lot more worried about consequences for users and the…

> Calling "NaCL" an "open technology" is about on par with calling Silverlight an "open technology", for what it's worth.

Silverlight is closed-source, patent-encumbered, and released by a company with a history of "embrace, extend, extinguish." That someone who appears to be speaking for Mozilla would draw this comparison is, again, disappointing.

> If PNaCl ever happens and is not directly tied to Chrome's internals (which it is at the moment), the discussion can be revisited.

This claim is directly at odds with the public statements of Mozilla's Chris Blizzard, who argues against the very idea of native code delivery to browsers. His arguments aren't against the NaCl implementation, process, etc, they are fundamental arguments against native code in general: http://www.theregister.co.uk/2011/09/12/google_native_client...

> Basically, as far as I can tell your argument comes down to saying that Mozilla should be open to implement PNaCl (not NaCl)

I'm not even hoping for that at the moment, at this stage I'm only hoping for them to stop maligning it publicly, like Chris Blizzard saying it will lead to DLL hell, or like with Brendan's slide that desaturates a picture of salt as if (P)NaCl is going to come for your children in the night.

Re: The State of JavaScript - Brendan Eich

#122

Post by BrendanEich »

haberman wrote: post #121
bzbarsky wrote: post #113

Earlier quoted context omitted.

Taking your points one at a time: 1) If PNaCl ever happens and is not directly tied to Chrome's internals (which it is at the moment), the discussion can be revisited. 2) Google is opposed to anyone else being more involved in the process. Other people have tried. 3) Mozilla has no particular concerns about "losing face" if a pragmatic decision is needed. We're a lot more worried about consequences for users and the…

> Calling "NaCL" an "open technology" is about on par with calling Silverlight an "open technology", for what it's worth. Silverlight is closed-source, patent-encumbered, and released by a company with a history of "embrace, extend, extinguish." That someone who appears to be speaking for Mozilla would draw this comparison is, again, disappointing. > If PNaCl ever happens and is not directly tied to Chrome's internal…

Was the salt crystal image scary? Boo hoo!

It was from Dave Herman, and it was not intended to be scary at all. It's appealing to physics and chemistry nerds. Salt has had a bad rap, to borrow from Montgomery Burns on eggs.

This is descending into silly-season political talk. Google chose the NaCl + Pepper pun. They can take the scary images, if those images truly are scary.

BTW, Chris Blizzard works for Facebook now.

Back to more serious topics...

UPDATE: to be fair to blizzard, he was objecting (as bz reminds me) on behalf of Mozilla to paving the web with x86 or other machine-dependent code, however compiled. Mozilla still opposes more such machine-specific plugin code. Think of NaCl as a safer plugin compiler, nothing more. We believe the Web should not need plugins to fill decade-long gaps from the '90s that real "coopetition" among browsers in standards bodies can fill much sooner, without the problems that plugins bring.

Re: The State of JavaScript - Brendan Eich

#123

Post by bzbarsky »

haberman wrote: post #121
bzbarsky wrote: post #113

Earlier quoted context omitted.

Taking your points one at a time: 1) If PNaCl ever happens and is not directly tied to Chrome's internals (which it is at the moment), the discussion can be revisited. 2) Google is opposed to anyone else being more involved in the process. Other people have tried. 3) Mozilla has no particular concerns about "losing face" if a pragmatic decision is needed. We're a lot more worried about consequences for users and the…

> Calling "NaCL" an "open technology" is about on par with calling Silverlight an "open technology", for what it's worth. Silverlight is closed-source, patent-encumbered, and released by a company with a history of "embrace, extend, extinguish." That someone who appears to be speaking for Mozilla would draw this comparison is, again, disappointing. > If PNaCl ever happens and is not directly tied to Chrome's internal…

> and released by a company with a history of > "embrace, extend, extinguish."

It's worth considering technology on its merits, not just based on past behavior of companies. In recent years, Microsoft has been much more of a team player in the web space than Google has, for what it's worth.

That said, I didn't claim NaCL was in all respects identical to Silverlight. I said it was comparable. It's more open in some ways (open source), less in others (e.g. no independent reimplementations, and precious little chance of any as things stand). The provenance is equally unpalatable, from my point of view; Google may not be aiming for "extinguish", not least because that's not very likely with the web at this point, but it's certainly aiming for "embrace, extend, coopt", which is not much better.

> That someone who appears to be speaking for Mozilla

In general, people who work on Mozilla speak for themselves. The cases when they're speaking for "Mozilla" are very rare and always marked as such. In this instance, I'm speaking for myself.

> This claim is directly at odds with the public statements > of Mozilla's Chris Blizzard

Chris and I don't always agree on everything. But some of his arguments are certainly valid. I didn't say I'd adopt PNaCl with open arms; just that the discussion should be revisited. As long as we're talking about things that are hardware-dependent, there's just no point having the discussion at all.

> at this stage I'm only hoping for them to stop maligning > it publicly

What you view as "maligning" someone else may view as an attempt to keep Google from pushing hardware-dependent code as part of the web platform, which is what they're trying to do. All a matter of perspective, I suppose.

Re: The State of JavaScript - Brendan Eich

#124

Post by masklinn »

cygx wrote: post #118
surrealize wrote: post #110

Earlier quoted context omitted.

I was going by this blog post from Brendan Eich: https://brendaneich.com/2011/06/new-javascript-engine-module... Where he says "[...] TraceMonkey, which we launched ahead of Chrome and V8". Maybe "shipped" was the wrong word. I suppose there's some definition of "launched" that makes the statement true; tracemonkey landed, and was announced, in August 2008. But you're right, the Chrome beta (Sept. 2, 2008 according t…

TraceMonkey was announced on 2008-08-23, after 2 months of development[1]. V8 had its first public release together with Chrome 2008-09-02 as you already mentioned, but development appears to have started in 2006 according to some of the copyright notes in the initial SVN export[2]. [1] https://brendaneich.com/2008/08/tracemonkey-javascript-light... [2] http://code.google.com/p/v8/source/detail?r=2

Which seems to confirm there would be a Tracemonkey even without V8 ever existing.

Re: The State of JavaScript - Brendan Eich

#125

Post by lhnn »

mikecane wrote: post #75

Need some advice here. I want to learn JavaScript -- but after reading all that, I wonder if all those changes/additions means that I should wait? Or will learning JavaScript now make little difference and all those changes/additions will make sense when enacted?

For the record, I just bought "Javascript and jQuery: The Missing Manual 2e" and am impressed with its style of teaching.

Yes, as someone who has programming background, it sometimes seems to be directed at those with no programming experience, but it still helps to start from the beginning and walk through.

As someone with a some CSS, HTML knowledge and no CLUE what the DOM was or how javascript interacts with HTML/CSS, it's been a good few days for me.

Re: The State of JavaScript - Brendan Eich

#126

Post by BrendanEich »

SeanLuke wrote: post #86

This presentation saddened me. The presentation focused on what it perceived as missing features: structs (seriously?), classes, modules, syntactic sugar, macros, etc. But the huge gaping holes in Javascript are not missing features. They are fundamental errors in the language. Things like ==, numbers as strings, eval, incorrect definitions of false, semicolon insertion, and -- heaven help us all -- improper lexical…

You seem to misunderstand "structs" -- see http://wiki.ecmascript.org/doku.php?id=harmony:binary_data, this is an extension of WebGL's typed arrays, which are already in all the new browsers (IE10 too).

As for implicit coercions, I enjoyed Gary Bernhardt's "Wat", referred to it, and at past talks even mocked along with. At Strange Loop, I went through each "Wat" in the "Wat Secrets Revealed" slide series (use down arrow when you see it greyed in).

Of course (!) I regret the implicit conversions that make == not an equivalence relation with disparate types on left and right (NaN is a different story: blame IEEE754). Who wouldn't? As I said at Strange Loop, some colleagues at Netscape were hot for lazy/loose number/string matching, and "I was an idiot! I gave them what they wanted."

There may be hope of fixing even ==, if we get macros done right. You would opt into macrology redefining == to be === or whatever you want. But this is in the future.

And that's the point: JS must grow compatibly, given its cursed/blessed position in the web. There is no other option that costs as little incrementally. True, we could paint into a corner. I don't see that happening, not with the vibrant and very smart JS developer community (communities, really) with whom we are working.

On a practical level, I once ran into someone who used to work at IDEO and became a JS hacker in the course of doing a startup. I asked him about == quirks and the like. He just shrugged and said "you learn what to avoid and move on." That is the voice of practical wisdom (until such time as macros help fix the quirks for good).

So my advice is cheer up!

Re: The State of JavaScript - Brendan Eich

#128

Post by jon6 »

haberman wrote: post #14

> NaCl? Not portable. To dis NaCl on this basis and not even mention PNaCl is dishonest. http://www.chromium.org/nativeclient/pnacl/building-and-test... > Defined by implementation. As it should be, until the implementation settles and it's clear what interfaces should be standardized. What a waste of time it would have been to standardize the pre-PNaCl work, for example. I wouldn't expect Rust (for example) to be st…

Also Nacl supports threads while emscripten does not. For a large set of applications (including my own games) this is a deal breaker to using emscripten.

Re: The State of JavaScript - Brendan Eich

#129

Post by BrendanEich »

surrealize wrote: post #108
SeanLuke wrote: post #86

This presentation saddened me. The presentation focused on what it perceived as missing features: structs (seriously?), classes, modules, syntactic sugar, macros, etc. But the huge gaping holes in Javascript are not missing features. They are fundamental errors in the language. Things like ==, numbers as strings, eval, incorrect definitions of false, semicolon insertion, and -- heaven help us all -- improper lexical…

This presentation focused on work that's more recent. Improving the scoping story with let/const is one of the things that TC39 agreed on relatively early, though: http://wiki.ecmascript.org/doku.php?id=harmony:let http://wiki.ecmascript.org/doku.php?id=harmony:const http://wiki.ecmascript.org/doku.php?id=harmony:block_scoped_... Some of the new-function/lambda-syntax proposals even support Tennent's Correspondence P…

We gave up on TCP for => function syntax. I think Java reached the same conclusion.

It's really hard to retrofit TCP onto a C-like language with statements as well as expressions. At best you please only some programmers and confuse others, at a fairly high implementation cost (e.g., return from within a lambda called after its containing function deactivated).

See https://mail.mozilla.org/pipermail/es-discuss/2012-March/021... and especially https://mail.mozilla.org/pipermail/es-discuss/2012-March/021....

Re: The State of JavaScript - Brendan Eich

#130

Post by BrendanEich »

colin_jack wrote: post #85

This is from the a section on custom iterators in the related blog post ( https://brendaneich.com/2012/10/harmony-of-dreams-come-true/ ): "We require opt-in to avoid future-hostility against custom iterators for collection objects. Such objects probably do not want any kind of general property iterator default, which if left on Object.prototype, might be object-detected and prevent installation of the correct custom…

Python does not have a default iterator for its objects. It does for dicts of course, but JS objects are not dicts (lots of issues there).
Post reply on HN