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

Brendan Eich on Ecma TC39, JavaScript.next, and Google Dash

brendaneich.com

Post reply on HN
Print view View original

121–127 of 127 posts

Re: Brendan Eich on Ecma TC39, JavaScript.next, and Google Dash

#121

Post by BrendanEich »

equark wrote: post #120
mraleph wrote: post #115

Earlier quoted context omitted.

> A simple 1000x1000 matrix multiply in LuaJit is already 20x (not 2x!) faster than V8 and on par with C. You are using outdated measurements. Up to date results: http://attractivechaos.github.com/plb/plb-lang.png http://attractivechaos.github.com/plb/ The difference between V8 and LuaJIT is nowhere near 2x on matmul and comes from differences in language features (no debugger interruption support for generated code…

Interesting, thanks. Do you have a guess on what the Dart means by "Dash is designed with performance characteristics in mind, so that it is possible to create VMs that do not have the performance problems that all EcmaScript VMs must have." Where will a redesign likely see gains?

JS has notorious optimization hazards such as holes in arrays (Array.prototype[1] = "ha ha"; a = [0,,2]; ... a[i] for i=1 must find the prototype element), prototype delegation in general, delete and default-mutability, plus the eval of old and 'with' (respectively reformed in modern impls and specs, and banned in strict mode).

These all add some cost in either runtime guards, static analysis burdens, or a mix.

A new language could leave out most of these, but it would still want inheritance. Then the question would be: how useful is mutability along the inheritance chain, i.e. shadowing -- even if you remove 'delete'.

Beyond this, a new language or a JS extension (this is what the Dash memo rules out as un-possible, without evidence) could allow pinning down the shape of objects, even to include machine types such as int32, etc. That would allow for big speedups on certain benchmarks.

Re: Brendan Eich on Ecma TC39, JavaScript.next, and Google Dash

#122

Post by BrendanEich »

munificent wrote: post #96
BrendanEich wrote: post #92

Earlier quoted context omitted.

If you are that old, you really ought to have better reading comprehension. My argument has nothing to do with Netscape, me, or my high horse. Look, Netscape had a monopoly and put JS "on first" and just about everywhere. I'm done apologizing for that, I've made up for it in spades on standards work, and it's a fact I cannot recall and rewrite. The precise point now , here on planet earth and not wherever you are, is…

"I'm done apologizing for that, I've made up for it in spades on standards work, and it's a fact I cannot recall and rewrite." Wouldn't it be fair then to at least give Google the chance to do that standards work with Dart after it's released before labeling the company anti-open? How early should a language be announced? It's certainly not cool to drop it on the world when it's done and baked , solicit zero feedback…

Look at what's actually happened, never mind the future:

1. Dart development (Dash, whatever, and there may be more, including CSS and HTML killers; not sure, rumors swirl) has been ongoing for approximately 2 years -- or more. It didn't start last November.

2. Google members of Ecma TC39 have been working on ES.next (some harder than others, I observe) without being able to show how Dart solves "unfixable" JS problems. Such demonstrations would help either:

2a. steer JS toward fixes if the "unfixable" assertion is false (as seems likely to me; little is unfixable on the web), or else:

2b. abandon doomed fix-the-unfixable attempts and instead work harder on other and fixable problems (e.g. being a better target language for Dart-to-JS compilation).

3. Delayed open-source means other browser vendors and volunteers have a high hill to climb to become committers/reviewers/co-owners, so Google controls the open source. This has happened many times. Competitors are unlikely to join, especially if the code is complex and has deep dependencies on other code (cf. NaCl/Pepper).

BTW, WebKit is an example more than a counter-example. It was Apple-dominated even though early-mostly-open, and now Google has taxed Apple committers/reviewers and is gaining the upper hand.

WebKit was early-open, a fork of KHTML at first, then set up as webkit.org in 2005 patterned after mozilla.org and in the aftermath of a recruit-half-the-Safari-team-to-fork-Firefox attempt by Flock. This history shows more open that closed, and earlier open at that, but mixed up with various intrigues and corporate control agendas.

While the history is not a clean win for any point of view, WebKit is a "commons" of its own. Note how chromium.org has to hold the Google-only extensions that Apple et al. won't take.

4. Standardization of Dart could happen anywhere, but it would be perceived as anywhere from wasteful to hostile for Google to bypass Ecma TC39. Early opening of a draft spec or even just an open-source implementation again could have won friends and influenced people on TC39. Late opening goes the other way.

What actually has happened, from what we already know: late-open.

Re: Brendan Eich on Ecma TC39, JavaScript.next, and Google Dash

#123

Post by Andi »

BrendanEich wrote: post #92
floppybunny wrote: post #91

Earlier quoted context omitted.

Those of us old enough to remember (Brendan, that should include you) know that Javascript itself was developed by a company (Netscape) in pretty much exactly the same way, for pretty much exactly the same reasons. Get off your high horse...

If you are that old, you really ought to have better reading comprehension. My argument has nothing to do with Netscape, me, or my high horse. Look, Netscape had a monopoly and put JS "on first" and just about everywhere. I'm done apologizing for that, I've made up for it in spades on standards work, and it's a fact I cannot recall and rewrite. The precise point now , here on planet earth and not wherever you are, is…

I explicitly support Brendan's arguments. Programming languages are a STANDARD to help people COMMUNICATE units of functionality. If we frequently invent new languages that just mainly give us a new "style" to do things (and of course some will do this better, and others will do that better), we get an unnecessary chaos of different codebases that will be incompatible to each other but yet do basically the same. (1) Language design implies even more responsibility in versioning and adaptation to new programming paradigms than API design. Let me again cite Atwood's Law: "Any application that can be written in JavaScript, will eventually be written in JavaScript." (see http://www.codinghorror.com/blog/2009/08/all-programming-is-... ) It doesn't matter that much in which language a program is written, as long as the language level fits the level of your module / application and portabiliy (1) is high. I would even vote against a separate module type and other experiments that complicate JS sytax. But this is, of course, another discussion. What I like and heavily use is CoffeeScript. Thank you Brandon for keeping things in order!

Re: Brendan Eich on Ecma TC39, JavaScript.next, and Google Dash

#124

Post by [deleted] »

BrendanEich wrote: post #121
equark wrote: post #120

Earlier quoted context omitted.

Interesting, thanks. Do you have a guess on what the Dart means by "Dash is designed with performance characteristics in mind, so that it is possible to create VMs that do not have the performance problems that all EcmaScript VMs must have." Where will a redesign likely see gains?

JS has notorious optimization hazards such as holes in arrays (Array.prototype[1] = "ha ha"; a = [0,,2]; ... a[i] for i=1 must find the prototype element), prototype delegation in general, delete and default-mutability, plus the eval of old and 'with' (respectively reformed in modern impls and specs, and banned in strict mode). These all add some cost in either runtime guards, static analysis burdens, or a mix. A new…

[deleted]

Re: Brendan Eich on Ecma TC39, JavaScript.next, and Google Dash

#125

Post by equark »

BrendanEich wrote: post #121
equark wrote: post #120

Earlier quoted context omitted.

Interesting, thanks. Do you have a guess on what the Dart means by "Dash is designed with performance characteristics in mind, so that it is possible to create VMs that do not have the performance problems that all EcmaScript VMs must have." Where will a redesign likely see gains?

JS has notorious optimization hazards such as holes in arrays (Array.prototype[1] = "ha ha"; a = [0,,2]; ... a[i] for i=1 must find the prototype element), prototype delegation in general, delete and default-mutability, plus the eval of old and 'with' (respectively reformed in modern impls and specs, and banned in strict mode). These all add some cost in either runtime guards, static analysis burdens, or a mix. A new…

I hope Dart proves this out.

Things like lack of machine types and operator overloading make Javascript unusable for the data analysis and statistical computing work I'm doing. While these may be feasible Javascript extensions, I can't see how that would come about in the The typical response is that data analysis and statistical computing are server-side tasks. But that is not entirely true. Almost all the scientific applications I have worked on have major front-end needs where the web could help tremendously.

On a broader note, one thing I don't quite understand is the complaint about lack of resources. The web browser is one of the most fundamental pieces of technology that exists today. They are also reasonably profitable. From my understanding Google gives Mozilla $60 million a year for the search bar. If browser vendors cannot dedicate new teams of 2-10 programmers on some feature -- like a Dart VM or NaCL clone -- I'm inclined to say the industry should consolidate. New VMs for Javascript are created by hobbyist coders all the time, as part time projects. Why is implementing a new VM and language so much work for Mozilla?

Re: Brendan Eich on Ecma TC39, JavaScript.next, and Google Dash

#126

Post by tomica »

BrendanEich wrote: post #36
ootachi wrote: post #34

Earlier quoted context omitted.

How should we deal with the mandatory dependency on a particular major/minor/patchlevel version of SQLite? That seems bad to standardize on. I personally think there's definitely room for a SQL database API built into the browser, but Mozilla did have a point. It should be something a little bit better specified than that. Also, it's not singlehanded -- IE refused to support Web SQL as well IIRC, and they aren't goin…

Thanks, that's worth reiterating: IE wasn't buying. Alas they didn't get IndexedDB done for IE9. And, just because WebSQL wouldn't fly does not make IndexedDB the one and only winner. We need to revisit this whole messy area.

did anyone on the standard bodies (from MSFT?) suggest LINQ framework as a WebSQL "replacement" ?

it makes a lot of sense IMHO. it abstracts away dependency on exact SQLite version, but preserves a familiar SQL-like mental model. it is stable, mature, well understood and widely deployed/used (god i sound like a shill.. ;)

and has the added benefit that it can be implemented in two different flavours: as a standard JavaScript (ES3) library on top of WebSQL (or SQLite in Gecko), or as a first-class language extension with syntax sugar similar/related to array comprehensions (from JS1.7/Harmony/ES6)..

check out the two code samples, and a list of language extension (all feeling right at home in JS): http://en.wikipedia.org/wiki/Language_Integrated_Query#Langu...

if it wasn't proposed, can someone from WHATWG (like you Brendan ;) politely ask Microsoft to "contribute" any related intellectual property to W3C? how likely do you think would it be for AAPL/GOOG to accept it? (and if not, it could simply be implemented as a thin layer above WebSQL ;)

Re: Brendan Eich on Ecma TC39, JavaScript.next, and Google Dash

#127

Post by Nitramp »

chromatic wrote: post #66
adgar wrote: post #46

Earlier quoted context omitted.

But then if the VM optimizes code paths related to STRING operations, languages can't take advantage of them as easily. There's a reason why the fastest VMs are deeply tied to the semantics of the language they support, LuaJIT being the best example.

You're right about LuaJIT, but there's no reason the VM can't also optimize code paths related to high-level string operations.

Well, at some point you might run out of space in the opcode byte (or multiple bytes), and then you need longer sequences that put up more cache pressure and require more time decoding, right?

Also, the developers time budget and the VMs complexity migth keep you from optimizing all possible paths.

Post reply on HN