Optional Strong Typing

Quildreen Motta quildreen at gmail.com
Sat Aug 31 14:29:26 PDT 2013


Ressurrecting this thread whoo :)

I don't feel static typing making its way to JavaScript. It just wouldn't
fit. The core libraries haven't been designed for it, and the community
libraries haven't been designated for it. I'd say static typing in JS is a
lost cause now. Designing a language for type guarantees takes a far
different route than designing a overtly dynamic language — there are
plenty of operations in JS whose types that are not even predictable, which
often causes JITs to drop optimisations defined for one function or another.

However, guards and contracts are cool. They're run-time type checking, and
they'll just work with what we have right now. You won't get a Haskell type
system, but you'll get confidence about the inputs where it matters.

That said, you can still try to shoehorn types in JS by way of an external
tool or compile-to-JS language. TypeScript takes this route (Dart too, to a
point, but it's a watered-down-Strongtalk-for-teh-web, really). You still
won't have Haskell's type system, but you'll have a nice design and
documentation tool if you design your type system right. You can't achieve
much more than this if you're targeting JS, we can't change the language to
being Haskell, or ML, or Scala, since we can't break existing code.

To say that types are strictly necessary for "large scale applications," is
a bit odd, though, and according to some research about effectiveness of
type systems, perhaps also incorrect — but I don't remember the name of the
papers, and I'm usually skeptical of such papers on CS.



On 24 August 2013 08:57, David Bruant <bruant.d at gmail.com> wrote:

> 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/<http://coding.smashingmagazine.com/2013/04/18/introduction-to-programming-type-systems/>
> [2] https://www.youtube.com/watch?**v=Il4swGfTOSM<https://www.youtube.com/watch?v=Il4swGfTOSM>
> [3] http://www.youtube.com/watch?**feature=player_detailpage&v=**
> O83-d0t0Ldw#t=797<http://www.youtube.com/watch?feature=player_detailpage&v=O83-d0t0Ldw#t=797>
>
> ______________________________**_________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>



-- 
--
Quildreen "Sorella" Motta  (http://killdream.github.com/)
*— JavaScript Alchemist / Minimalist Designer / PLT hobbyist —*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130831/438d1be5/attachment.html>


More information about the es-discuss mailing list