IDE support?

[Andreas Rossberg]

On 13 September 2011 16:48, Brendan Eich <brendan at mozilla.com> wrote:
> On Sep 13, 2011, at 5:33 AM, Andreas Rossberg wrote:
>>
>> * There are extra costs in space and time to doing the runtime analysis.
>> * Compile time is runtime, so there are severe limits to how smart you
>> can afford to get in a compiler.
>
> These are bearable apples to trade against the moldy oranges you'd make the world eat by introducing type annotations to JS. Millions of programmers would start annotating "for performance", i.e., gratuitously, making a brittle world at high aggregate cost.
>
> The costs born in browsers by implementors and (this can hit users, but it's marginal) at runtime when evaluating code are less, I claim.

Depends on how good you want to optimize. Aggressive compilers can be
really slow. There are limits to what you can bear at runtime.
Especially, when you have to iterate the process.


>> * The massive complexity that comes with implementing all this affects
>> stability.
>
> This one I'm less sympathetic to, since we won't get rid of untyped JS up front. A sunk cost fallacy? If we could make a "clean break" (ahem), sure. Otherwise this cost must be paid.

Well, the counter-argument would be that you wouldn't need to care
about optimising untyped code as much, if the user had the option to
switch to a typed sublanguage for performance.


>> * Wrt limits, even in the ideal case, you can only approximate the
>> performance of typed code -- e.g. for property access you have at
>> least two memory accesses (type and slot) plus a comparison and
>> branch, where a typed language would only do 1 memory access.
>
> That's *not* the ideal case. Brian Hackett's type inference work in SpiderMonkey can eliminate the overhead here. Check it out.

I'm actually pretty excited about that, and hope to see more on that
front. Cool stuff.

However, that ideal case is achieved in a relatively small percentage
of cases only. Otherwise we should probably not see a (already
impressive) 20-40% speed-up (IIRC), but rather something closer to
200-400%.


>> * Type inference might mitigate some more of these cases, but will be
>> limited to fairly local knowledge.
>
> s/might/does/ -- why did you put type inference in a subjunctive mood? Type inference in SpiderMonkey (Firefox nightlies) is not "local".

Fair enough re the subjunctive. Still, there are principal limitations
to what type inference can do. Especially for OO. You hit on
undecidable territory very quickly. You also have to give up at
boundaries such as native bindings, calls to eval, or (in ES6) to the
module loader, unless you're given extra information by the programmer
(this is basically the separate compilation problem).

So the inferencer has to work with approximations and fallbacks. For a
language like JS, where a lot of conceptual polymorphism, potential
mutation, and "untypable" operations are going on, those
approximations will remain omnipresent, except, mostly, in
sufficiently local contexts.

Not to say that it is not worth extending the boundaries -- it
definitely is. But it will only get you that far.


>> * Omnipresent mutability is another big performance problem in itself,
>> because most knowledge is never stable.
>
> Type annotations or (let's say) "guards" as for-all-time monotonic bounds on mutation are useful to programmers too, for more robust programming-in-the-large. That's a separate (and better IMHO) argument than performance. It's why they are on the Harmony agenda.

Of course I'd never object to the statement that there are far better
reasons to have typy features than performance. :) I just didn't
mention it because it wasn't the topic of the discussion.


>> So despite all the cool technology we use these days, it is safe to
>> assume that we will never play in the performance league of typed
>> languages. Unless we introduce real types into JS, of course. :)
>
> Does JS need to be as fast as Java? Would half as fast be enough?

No, it doesn't have to be as fast. Not yet, at least... I estimate we
have another 3 years. ;)

/Andreas