Comment by BrendanEich | Hacker News Reader

Comment by BrendanEich | Hacker News Reader

Parent Full thread

What a formatting mess -- I hope you can you still edit your post and put two newlines after the >-cited lines from my post, and the text where you start replying? Thanks.

If I can read through the mess, you seem to be saying you can't evaluate PNaCl, so you'll just make airy and overconfident assertions about it. Even on HN, that doesn't fly. -1!

When I challenge your further assertion that something is "easily integrated into any browser", you switch subjects to arguing for prototyping and developing a complex system before standardizing it. Good idea (but beware the difficulty standardizing it late if simpler evolutionary hops beat it in the meanwhile; more below on this). However true, that is a dodge, it does not excuse your assertion about "easily integrated".

Doubling down by citing "the DOM" as if Pepper were only about OS and DOM APIs, or as if even just the DOM implementations in different engines had enough in common to make interfacing from native code (not from JS, which is hard enough even with a decade+ history of written standards and market-driven interop testing) easy, just repeats this bad pattern. So -2.

Then you seem to confuse ES4 with Harmony (which I made clear came about after ES4 failed). -3.

At this point on USENET, you'd hear a plonk. But I'll close with one more point:

Mozilla and Google using LLVM does not equate to standardizing PNaCl. Pepper is one problem, a big one, but not the only one. Consider also the folly of using a linker-oriented intermediate representation for a shelf-stable Web-scale object file format. See Dan Gohman's "LLVM IR is a compiler IR" post:

http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/0437...

Shortest-path evolution usually wins on the Web. Trying to standardize PNaCl -- including Pepper and LLVM IR abused or patched into shape as a long-lived object file format -- is an impossibly long, almost exclusively Google-dependent, path.

Extending JS among competing engines whose owners cooperate in Ecma TC39, via a series of much shorter and independently vetted and well-justified (by all those engine owners) path-steps? That is happening in front of your eyes.

You may not like it. You may want to say "Go home, evolution, you are drunk":

http://wtfevolution.tumblr.com/post/40659237456/this-pelican...

But it would be foolish to bet against evolution.

/be

>What a formatting mess -- I hope you can you still edit your post and put two newlines after the >-cited lines from my post, and the text where you start replying? Thanks.

Sorry, for the bad formatting, when I understood that it's broken I wasn't able to edit it.

>At this point on USENET, you'd hear a plonk. But I'll close with one more point:

I didn't want to argue with you, I just described how it looked to me (and I mentioned it in the previous comments). I just have no expertise here and now see that there're problems which aren't mentioned by googlers in their presentations. May be you are right, may be they are right. I am sorry if I offended you.

>Shortest-path evolution usually wins on the Web. Trying to standardize PNaCl -- including Pepper and LLVM IR abused or patched into shape as a long-lived object file format -- is an impossibly long, almost exclusively Google-dependent, path.

Yes, it is. I have no choice other than to use JavaScript in one form or another. However, I would love to be able to use a beautiful modern and well thought language on the client instead of rusty JavaScript (or Dart or GWT). I like the Mozilla Rust, but it is a system programming language. I'd love to see something of similar spirit but oriented towards client. Unfortunately, it will take too much time until it happens.

Not looking to argue, just add some value: you say "too much time until it happens" and I've heard that before, many times -- most recently re: Dart (see that Channel 9 Lars&Anders interview).

Funny thing, it has been years since Dart started, ditto PNaCl. Who says JS is the slow path? I suspect it will get there faster (for tangible definitions of "there", e.g., a Rust2JS compiler for you) with well-focused work.

/be

> Rust2JS

Pretty please! Excited to see pcwalton's zero.rs work, which I understand to be a prerequisite for a Rust2JS. But deeper JS integration than emscripten currently provides (e.g., mapping rust structs to harmony binary data StructTypes?) would be even more awesome. When are you going to land 749786, anyway?

Re: Dart and PNaCl--they've been useful for providing political cover to people who want to evolve JS more aggressively.

Heh, I really do need to land int64/uint64 support. The patch needs tests and some cleanup first. This week may afford some hacking time (finally) instead of just rebasing time.

In theory it shouldn't be necessary to mal-invest in long-odds/single-vendor (and therefore hard to standardize without dominant market power) innovations at high cost, just to drive minimal investment in evolving the web in shorter-odds ways. Especially when the same company is collaborating in TC39 to evolve JS, and owns the V8 engine!

Competitive strategy or just a side effect? I suspect the latter, and even if strategy, it's not cheap. Anyway, we didn't need it as cover to do asm.js. That came from @azakai's work on Emscripten plus Mozilla Research's "make the Web better" agenda and answer the "JavaScript -- is there anything it can't do?" q. with results (negative or positive).

/be

I hate Javascript. Sorry if this offended anyone. I think it was good for its limited use case during the early Web 1.0 - Web 2.0 era.

So therefore I dont like asm.js either. I much prefer LLVM or PNaCI. But that is in an ideal world. In real world i would have to agree asm.js seems the way forward. Even with asm.js being a shortcut, it would still take many years for it to gain enough traction and improvement to be really useful as an universal compiler target. Much like what is currently happening now with JVM. Except almost everyone already has a JS Engine Installed, no need to download a Java Runtime.

That way everyone can really use what ever languages that love or they want. With Everything2js.

I hope the future evolution of Javascript will take performance as a consideration. Such as SIMD etc.

May the day of languages independent web come faster.

Some days, I hate JS too. But hate leads to the dark side. It is what it is. Might as well hate endosymbionts who power our cells for being ugly.

We're all over performance, including SIMD. Multiple approaches but definitely up for the Dart-like direct approach. Talking to John McCutchan of Google about lining up JS on this front so Dart2JS has a complete target.

/be

Reply on news.ycombinator.com