Le 23/08/2013 19:38, J B a écrit :
So the defacto response for large scale JS development will always be:
Use X?
Even if so, why would it be a big deal?
Just to clarify a point, I read interesting definitions of what "weak",
"strong", "static" and "dynamic" typing means [1]. Not sure how they are
grounded with more formal definitions.
Anyway, according to this definition, JavaScript is dynamically strongly
typed.
I imagine your question is then "why can't we have optional static
typing in JS?". And I'm not entirely sure what the benefits would be for
the entire language. Static typing has huge benefits at development time
(early errors, errors more meaningful than "undefined is not a
function"! Had a 5 week experience with TypeScript on a real-life
project that'll ship soon. That made a difference). The downside of JS
types is that JS engines will have to verify them and that adds to total
runtime cost, especially load time, which we don't need to be slower
than it is now (something about a 1000ms time to glass barrier [2]).
Just to be clear, the main problem isn't JS engines ability to compile
JS with optional static type, but more our practice to load too much
code (that will have to be verified before running). Hopefully that
trend will change, but the web isn't ready to add another static
verification step I believe.
If the JS engine had knowledge of static types, *maybe* they could go
faster (after the slower load time). But how much faster? Current JS
engines go really fast after doing type inference when the code is type
stable. The interesting part is that the instrumentation/JIT-compilation
costs only for long-running code (and not all the code we've loaded!
especially not the unused paths!!), but practice shows that the cost is
very small compared to the gains it provides.
On a related note, I've recently been asked whether TypeScript compiled
more efficient JS (cc'ing Luke Hoban to be sure I'm not spreading
misinformation). My answer was that no, it doesn't by itself. TypeScript
is very respectful of the input JS (and that's a feature!). However, the
JS subset the TypeScript compiler encourages to write to has stable
types and has a very strong chance to run faster in current engines.
An interesting approach to static typing is asm.js. The interesting part
is that the statically compiled part is very localized (and not
whole-language-scoped), so its cost is localized. Brendan suggests [3]
that ahead of time compilation can only provide better performance. I
wonder what's the cost of the static verification is and how much it
hurts load time. I'm especially wondering whether this cost will not
hurt performance too much when people will load lots of unnecessary
asm.js code (cc'ing Dave Herman in case he has answers on that topic),
which is obviously not measured by current benchmarks.
Anyway, whole-language static typing sounds like a bad idea and "use X"
seems to be to good way forward. The compile-to-JS battle has just
started. Let's be patient.
David
[1]
http://coding.smashingmagazine.com/2013/04/18/introduction-to-programming-type-systems/
[2] https://www.youtube.com/watch?v=Il4swGfTOSM
[3]
http://www.youtube.com/watch?feature=player_detailpage&v=O83-d0t0Ldw#t=797
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
