IDE support?

[François REMY]

Well, you're right to point the difficulty encountered while stepping "in" 
and "out" of a typed environment. I know I'm fairly limited in my 
understanding of JavaScript VMs because they've become both wonderful and 
very complex tools at the same time, but I've got the chance to understand 
pretty deeply the .NET CLR. In fact, when you use the "Object" type for a 
parameter, you must know that sending an integer or a boolean to the fuction 
will require something called "boxing" (I think it's the kind of problem you 
rose in your mail).

It's true that it's rather uncommon in .NET since nearly everything is 
strongly typed. But it comes at a cost, I understand it. Depending on the 
cost of "boxing" and "unboxing", it may be a worse overhead than the initial 
one (the one where nothing would be typed). But, well, this problem has to 
be taken in account in the current implementation of ECMAScript, right? 
Since you can call methods on integers or booleans, there must be some kind 
of Boxing involved somewhere.

Anyway, I feel like annotating is needed, somewhere. For exemple, Visual 
Studio does know that the return value of document.getElementById is a 
HTMLElement. Since he doesn't have access to the browser own code, it must 
be hard-coded somewhere. It's the same for framework functions. You don't 
want your IDE to analyse the whole jQuery framework each time you use it. If 
it has simple annotation on its functions return values and parameters, this 
task can be done when needed and very quickly. Almost chirugically.

An exemple : in VB.NET, if you have a function taking an Enum as a 
parameter, the Intellisense will provide you as options the flag names 
defined in the enum. But in your code, you may want to treat the value as an 
int and there's no way, from the code, to guess it's coming form an enum if 
it wasn't stated in the parameter type.

So, yes, annotating types can help a lot. Inference can do a lot, too. I 
almost never specify the types of my variables and my lambda's parameters, 
to quote a few. From the informations gathered from a small amount of 
annotation, the compiler can guess those things for me, right when I'm 
typing the code. If I make changes to my program, it will be able to 
"update" the type inference and check incompatibilities. All this was a pain 
when type inference was not enabled.

Static typing, type inferfence and virtual execution are both very useful 
tools, and each of them solves almost the same problem. But each of them has 
case it solves pretty well and others it don't. Making them working together 
is the dream we should have. Actually, working together is the motto of the 
web as a whole...



-----Message d'origine----- 
From: Brendan Eich
Sent: Tuesday, September 13, 2011 9:11 PM
To: François REMY
Cc: John J Barton ; es-discuss at mozilla.org
Subject: Re: IDE support?

On Sep 13, 2011, at 1:02 AM, François REMY wrote:

> Okay, maybe you don't have to seek throug a dictionnary anymore. But 
> still, the performance overhead is higher than you would want to. Because 
> it's possible to achieve no overhead, even a small overhead is an overhead 
> to be deleted. The fastest code is the code you don't have to execute.

You're right, small constant factors and terms matter asymptotically.

More apples-to-oranges, but we have to weigh and decide: JS programmer 
productivity is not clearly helped by adding type annotations. We worked 
through a number of scenarios for ES4:

* Typed code calling untyped code: dynamic barriers required to enforce 
invariants, this'll cost.

* Untyped code calling typed code: spot-checks (remember "like") or barriers 
required, ditto.

* The easy one, typed calling typed, but then you've probably harmed 
productivity by over-annotating.

The gravity well is steep. AS3 went far down it and its users 
over-annotated. Different economics and tooling on the web, so maybe we'll 
be luckier -- or perhaps an attempt to sell optional type annotations will 
simply fail to close -- no widespread adoption.

This all assumes we have a sound optional type system. We never had one for 
ES4. It's a research area. TC39 is not doing research, remember?


> A compiler may be very dumb, if I say something is true, he know it's 
> true. On the other side, a compiler can be as smart as you want, there are 
> things he'll never be able to guess.

Yes, but does JS need to run almost as fast as C?

BTW, for well-behaved benchmarks using typed arrays, our tracing JIT does 
run about as fast as C. So really, you have to stipulate workload. For all 
workloads, must JS run almost as fast as C? No way!

/be=