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

201–210 of 266 posts

Re: The State of JavaScript - Brendan Eich

#201

Post by haberman »

BrendanEich wrote: post #190
petegrif wrote: post #188

Earlier quoted context omitted.

I don't understand why you feel it necessary to make your points in such an inflammatory manner. Your arguments are well made, why do you feel the need to, for example, call someone 'astoundingly naive?' Being rude doesn't make your points more convincing and I would have hoped you were above that kind of thing. It's a pity because you have a huge amount to contribute.

I went out of my way to say that Haberman's position as I understood it -- not he himself -- was "astoundingly naive". This after he called me dishonest and speculated on motives. Are you using the same yardstick with me as with him? I think not. Arguing about motives is a form of the _ad hominem_ fallacy, and I was avoiding it , in contrast to my fine counterpart. Yeesh!

Oh come on. My label of "dishonest" was in regards to a statement, not you personally, just like your label of "astoundingly naive" against me.

And I didn't speculate about motives. I'm not sure what statements of mine you're taking so much offense to, but your speech has also been brusque and uncharitable at times ("Who are you to say...", "Here's a final clue:").

I also went out of my way to empathize with Mozilla's concerns and reasoning for not wanting to support NaCl, whereas you show no appreciation for why someone might ever legitimately want to run native code on the web.

Re: The State of JavaScript - Brendan Eich

#202

Post by BrendanEich »

dmorgan wrote: post #168
haberman wrote: post #162

Earlier quoted context omitted.

If I sound argumentative and fired up, it's because I feel like Mozilla has been casting stones on this issue for years. Imagine how you would feel if Google executives were publicly criticizing Mozilla efforts like Persona, arguing that they would never support them and no one else will either, basing their criticisms on issues that you are actively fixing. (For what it's worth, Persona looks promising to me persona…

> (P)NaCl are specifically designed to allow execution of untrusted code without making it run on top of a VM or GC And this is the argument he's making: that does not fly by browser vendors. They DON'T want to have code run OUTSIDE their VM/GC.

Thanks for the support, but that's not what I meant. NaCl + Pepper is like a VM where the compiler does the heavy lifting so the native code can run safely (Software Fault Isolation, SFI -- wild pointers lead to a safe non-exploitable crash), rather than a JITting or MMU- or hypervisor-based VM doing the heavy lifting at runtime.

It's quite clever, but still enough of a new thing that Chrome also sandboxes NaCl'ed code out of process. Belt and braces are good. No silver bullets.

But a VM is as a VM does. This is part of Google's VM-set and not any other browsers. The rule still applies.

Truly unsafe native code in plugins (e.g., un-NaCl'ed Flash) runs out of process too, and sandboxed to some extent, but it can cause problems that are not contained (and did at the last CanSecWest Pwn2Own contest, IIRC).

Re: The State of JavaScript - Brendan Eich

#203

Post by cmccabe »

bzbarsky wrote: post #115
haberman wrote: post #109

Earlier quoted context omitted.

> The issue here is that NaCl and Xax are proprietary approaches If you had told me in the 90s when Microsoft was king that someday "proprietary" would be used to describe a completely open-source, documented, published technology that its creator encourages others to adopt, I would have laughed and said it's impossible. > NaCl is weak at handling dynamically generated code They got it working for x86 ( http://static…

"proprietary" is a spectrum, not a binary decision. You can be open-source, documented (though NaCl is not so documented in practice because of the Pepper dependencies), published, and encouraged to adopt, but if your development is controlled completely by a single company and if you depend on other, undocumented, parts of that company's software stack, then you are more proprietary than something with an open (as i…

Sigh. Not all open source projects are community projects. That doesn't make them proprietary. I'm disappointed to see this kind of confusion on HN.

Rust doesn't have much of a community around it, besides Mozilla. Does that make it "proprietary"? Nope.

We all know NaCl is not going to be adopted-- not because it's not good enough, but because it's too good, and would threaten the native app ecosystems of Apple and Microsoft. pNaCl, same story. Google might end up using it as an app delivery mechanism in ChromeOS; that's about the limit of its potential usefulness.

It's particularly ironic to hear Brendan Eich complain about the lack of a standards-first approach in NaCl, since ECMAScript was designed behind closed doors at a single company. Anyway, ECMAScript seems to be good enough for building web UIs, and it's even a little less verbose than its "older brother" (whom it resembles not at all). So I think its quasi-monopoly is secure. I hope they pull the TypeScript extensions into the core language in the next version.

Re: The State of JavaScript - Brendan Eich

#204

Post by nnethercote »

dherman wrote: post #134
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…

> The presentation focused on what it perceived as missing features: structs (seriously?), classes, modules, syntactic sugar, macros, etc. The nature of a widely-used technology is that you can't remove features, you can only add. And yet adding features causes an increase in complexity. So what to do? The answer is to add features judiciously: prefer general features that cover a wide array of use cases and can prov…

> We intend to try this out with sweet.js, building something like "restrict mode" (http://restrictmode.org) as a module you can import.

Oh cool!

Re: The State of JavaScript - Brendan Eich

#205

Post by BrendanEich »

haberman wrote: post #201
BrendanEich wrote: post #190

Earlier quoted context omitted.

I went out of my way to say that Haberman's position as I understood it -- not he himself -- was "astoundingly naive". This after he called me dishonest and speculated on motives. Are you using the same yardstick with me as with him? I think not. Arguing about motives is a form of the _ad hominem_ fallacy, and I was avoiding it , in contrast to my fine counterpart. Yeesh!

Oh come on. My label of "dishonest" was in regards to a statement, not you personally, just like your label of "astoundingly naive" against me. And I didn't speculate about motives. I'm not sure what statements of mine you're taking so much offense to, but your speech has also been brusque and uncharitable at times ("Who are you to say...", "Here's a final clue:"). I also went out of my way to empathize with Mozilla'…

You wrote, very first comment at top:

"To dis NaCl on this basis and not even mention PNaCl is dishonest."

That was in response to my slides. You were calling me dishonest. Come on yourself!

You then went on about "propaganda" and scary salt crystals. Something is off right there. Mozilla doesn't make propaganda and we have a tiny fraction of Google's budget (which I can assure you has been deployed commercially to push NaCl).

I don't think your tone or content are balanced on any of this, and you at least climbed down on the salt crystals. Can you do likewise on the "dishonest"?

Re: The State of JavaScript - Brendan Eich

#206

Post by sayrer »

haberman wrote: post #201
BrendanEich wrote: post #190

Earlier quoted context omitted.

I went out of my way to say that Haberman's position as I understood it -- not he himself -- was "astoundingly naive". This after he called me dishonest and speculated on motives. Are you using the same yardstick with me as with him? I think not. Arguing about motives is a form of the _ad hominem_ fallacy, and I was avoiding it , in contrast to my fine counterpart. Yeesh!

Oh come on. My label of "dishonest" was in regards to a statement, not you personally, just like your label of "astoundingly naive" against me. And I didn't speculate about motives. I'm not sure what statements of mine you're taking so much offense to, but your speech has also been brusque and uncharitable at times ("Who are you to say...", "Here's a final clue:"). I also went out of my way to empathize with Mozilla'…

does PNaCl work? do you know the answer to that question?

Re: The State of JavaScript - Brendan Eich

#207

Post by bickfordb »

My jaw dropped on the byte code slides. Even though probably foolish to expect that the Javascript creator would offer non-Javascript solutions, I would guess that it would be significantly better to compile Javascript/CSS to a more efficient, stable, portable target byte code or source language (Go? Scheme? Postscript?) than to compile languages to Javascript. For example, when I played with it the Hello World ClojureScript example compiled to a Javascript file of over 100kbytes. It seems like Go and JIT'ed languages have demonstrated that extremely fast compilation of extremely efficient high level native code is possible.

Long-term it seems like it would be significantly better to encode these web language extensions (new CSS/Javascript syntax) as libraries instead of as API/run-time extensions so that each new version of web languages doesn't require all the run-times (Firefox, Chrome, Safari, IE) to adopt it and old run-times to phase out. The current standards/run-time process doesn't seem to be extremely well-thought out. Has anyone on these standards communities ever had to actually build or maintain a web application?

Re: The State of JavaScript - Brendan Eich

#208

Post by BrendanEich »

cmccabe wrote: post #203
bzbarsky wrote: post #115

Earlier quoted context omitted.

"proprietary" is a spectrum, not a binary decision. You can be open-source, documented (though NaCl is not so documented in practice because of the Pepper dependencies), published, and encouraged to adopt, but if your development is controlled completely by a single company and if you depend on other, undocumented, parts of that company's software stack, then you are more proprietary than something with an open (as i…

Sigh. Not all open source projects are community projects. That doesn't make them proprietary. I'm disappointed to see this kind of confusion on HN. Rust doesn't have much of a community around it, besides Mozilla. Does that make it "proprietary"? Nope. We all know NaCl is not going to be adopted-- not because it's not good enough, but because it's too good, and would threaten the native app ecosystems of Apple and M…

Rust has a healthy number of committers who are not employed by Mozilla. I will let pcwalton fill in details if necessary.

"Proprietary" as in "sole proprietor" is appropriate for a project with zero governance, launched by Google after some incubation closed-source, dominated by Googlers.

NaCl is not adopted because it's machine-dependent!

PNaCl is not ready. Show me Chrome Web Store games compiled with it and not NaCl, then we'll talk.

As I've written before on HN (see https://news.ycombinator.com/item?id=2998374, "I've paid my dues"), JS was created by me in a tearing hurry in 1995 for Netscape, the would-be market power that nevertheless avoided a monopoly conviction (unlike the other guys).

There is no "quasi-monopoly" here. Someone on HN schooled me on "monopoly" (http://news.ycombinator.com/item?id=2998590).

The issue with JS is not "monopoly" in the econ 101 sense. The issue is that JS is more than good enough, and getting better under competition and cooperation in the standards bodies. Therefore it is very hard to displace, and just as hard (if not moreso: a displacing language might be backward compatible) to supplement with a second language/VM in all browsers.

You should respond to this technical fact (by which I mean, the circumstance is well-founded in software costs).

Re: The State of JavaScript - Brendan Eich

#209

Post by BrendanEich »

bickfordb wrote: post #207

My jaw dropped on the byte code slides. Even though probably foolish to expect that the Javascript creator would offer non-Javascript solutions, I would guess that it would be significantly better to compile Javascript/CSS to a more efficient, stable, portable target byte code or source language (Go? Scheme? Postscript?) than to compile languages to Javascript. For example, when I played with it the Hello World Cloju…

> Has anyone on these standards communities ever had to actually build or maintain a web application?

Yes.

Re: The State of JavaScript - Brendan Eich

#210

Post by bzbarsky »

cmccabe wrote: post #203
bzbarsky wrote: post #115

Earlier quoted context omitted.

"proprietary" is a spectrum, not a binary decision. You can be open-source, documented (though NaCl is not so documented in practice because of the Pepper dependencies), published, and encouraged to adopt, but if your development is controlled completely by a single company and if you depend on other, undocumented, parts of that company's software stack, then you are more proprietary than something with an open (as i…

Sigh. Not all open source projects are community projects. That doesn't make them proprietary. I'm disappointed to see this kind of confusion on HN. Rust doesn't have much of a community around it, besides Mozilla. Does that make it "proprietary"? Nope. We all know NaCl is not going to be adopted-- not because it's not good enough, but because it's too good, and would threaten the native app ecosystems of Apple and M…

I think you missed my point.

Say you have an open-source project with a single owner, who makes all the decisions about it, and is willing to totally change it around to suit his needs.

Would you stake your business on use of that open-source project? Only to the extent that you're sure your needs align with the project owner's. Unless, of course, you're planning to fork anyway.

That's where NaCl is at the moment.

It's also where Rust is, even more than NaCl. Anyone who is not in the business of working on Servo is nuts if they're relying on Rust for anything important, so far. In my opinion. So yes, from my point of view Rust is definitely proprietary to Mozilla at the moment, and asking anyone else to use it (again for anything important, not just experiments) is just a recipe for disaster.

As far as NaCl adoption, Apple and Microsoft have their own reasons for not adopting it, for sure. But this subthread is about Mozilla's reasons, which certainly don't match those of Apple and Microsoft.

Post reply on HN