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 ; [email protected]
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=
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
