Optional Strong Typing

Brendan Eich brendan at mozilla.com
Fri Aug 23 12:03:43 PDT 2013

Has everyone forgotten ES4? Blasts from the past:


and then


ES4 failed in part because of AS3 namespaces (from original JS2/ES4 
namespaces in 1999, also in JScript.NET in 2000, IIRC; inspired by 
Common Lisp symbol packages), but also because on the Web it's very hard 
to know *when* to typecheck. Code loads all the time. Judgments may be 
invalidated down the road. The "any" type requires runtime checking.

So "strong typing" if it means "what AS3 does" bounced, hard.

The best we have in its place are the compile-to-JS langauges with 
optional and unsound type
If you want warnings, use WarnScript (er, TypeScript or Dart or ...).

If you want standardized warnings, we need lots more developer 
experience from TypeScript and other languages to get anywhere near a 
standard. ES8 at the earliest, given our move toward more rapid releases.

If you want a static type system -- which means soundness -- then there 
are big open research problems to solve.


J B wrote:
> @Jeremy: I mean the parser will strip all of the typing info out 
> before it's compiled/interpreted.
> @Axel: "Evolving a language standard used as broadly as ECMAScript 
> takes time" -- I agree.
> "You can see TypeScript as exploring future options for ECMAScript." 
> -- Wasn't AS3 already doing this?
> "Guards" -- Looks good...
> "TypeScript tracks JavaScript very closely, I would not consider it a 
> different language." It's compiled, and it's one of many options 
> available, which presents a problem in that if one code base is 
> written in TypeScript, and another in JavaScript++ will they be 
> compatible? Even if the resulting JS is, devs will be required to 
> learn several variants of JS. It's not that this isn't happening 
> elsewhere (libraries written in Java vs C#), but it's been made worse 
> by ECMAScript's lack of key features, which has caused a good many of 
> these languages to appear, and to be used. My point is, if JS was a 
> little more large scale development friendly (like TypeScript), devs 
> could just use plain ol' JS! Sure, some would still use language 
> extensions like TypeScript, but at least it wouldn't be the defacto 
> standard because of core inadequacies in base language.
> On Fri, Aug 23, 2013 at 1:06 PM, Jeremy Martin <jmar777 at gmail.com 
> <mailto:jmar777 at gmail.com>> wrote:
>     I mean it's a parse error that will throw prior to attempting to
>     execute it.  For example, consider:
>         (function() { var foo:String; })
>     This will throw an error, despite the fact that the function
>     hasn't been invoked.  I replied in haste, though... your point is
>     obviously valid for other scenarios.  Nonetheless, as a
>     non-authoritative response, you're going to need an argument far
>     more compelling than I can think of to see static typing seriously
>     considered.
>     On Fri, Aug 23, 2013 at 2:00 PM, J B <port25 at gmail.com
>     <mailto:port25 at gmail.com>> wrote:
>         Are you referring to browsers like Chrome that compile the JS
>         first? Then, yeah, I mean it shouldn't throw an error at
>         compile time.
>         On Fri, Aug 23, 2013 at 12:59 PM, Jeremy Martin
>         <jmar777 at gmail.com <mailto:jmar777 at gmail.com>> wrote:
>             > var foo:String;
>             That's already a compile-time error (as opposed to
>             runtime.... not sure if that's what you meant by the
>             interpreter throwing an error).
>             On Fri, Aug 23, 2013 at 1:56 PM, J B <port25 at gmail.com
>             <mailto:port25 at gmail.com>> wrote:
>                 And just to be clear, I'm not asking for run-time type
>                 checking or coercion; I'm simply asking that the
>                 interpreter not to thrown an error when it encounters
>                 something like this: var foo:String;
>                 On Fri, Aug 23, 2013 at 12:45 PM, J B
>                 <port25 at gmail.com <mailto:port25 at gmail.com>> wrote:
>                     For one, I wouldn't describe strong typing as a
>                     "pet feature". Two, no, as far as I know, most of
>                     those languages in that list don't offer macros or
>                     lots of parentheses; and, if they did, then, yeah,
>                     maybe it does say something.
>                     On Fri, Aug 23, 2013 at 12:41 PM, Domenic Denicola
>                     <domenic at domenicdenicola.com
>                     <mailto:domenic at domenicdenicola.com>> wrote:
>                         In general ECMAScript lacks lots of features.
>                         You may well ask why it doesn't have any other
>                         pet feature, and you can often point to
>                         compile-to-JS languages that add those. This
>                         doesn't imply that the feature should be added
>                         to the language.
>                         Here, let me try:
>                         ---
>                         I'm aware of LispyScript, as well as all of
>                         these:
>                         https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS.
>                         But those languages appear to have been
>                         created precisely because ECMAScript lacks
>                         features like lots of parentheses or macros.
>                         How many of those languages offer lots of
>                         parentheses? I count quite a few... Doesn't
>                         that say something?
>                         ---
>                         The existence of a feature in other languages
>                         does not imply it should be added to
>                         ECMAScript. You'll have to justify better than
>                         that why you think strong typing would be
>                         valuable to a language that has historically
>                         rejected it. (I'll wait for one of the old
>                         timers to chime in about the ES4 days here.)
>                 _______________________________________________
>                 es-discuss mailing list
>                 es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>                 https://mail.mozilla.org/listinfo/es-discuss
>             -- 
>             Jeremy Martin
>             661.312.3853 <tel:661.312.3853>
>             http://devsmash.com
>             @jmar777
>     -- 
>     Jeremy Martin
>     661.312.3853 <tel:661.312.3853>
>     http://devsmash.com
>     @jmar777
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

More information about the es-discuss mailing list