Brendan Eich brendan at mozilla.org
Wed Aug 13 23:44:27 PDT 2008

On Aug 13, 2008, at 11:24 PM, Neil Mix wrote:

>> I do get the idea that a consumer of an API is helped with some good
>> error messages. Sometimes I have public API functions of a library
>> that start something like
>> function(a, b) {
>>  /* begin debug */
>>  isInt(a); // throws
>>  isStr(b); // throws
>>  /* end debug */
>> ...
>> The debugging code is stripped when deploying for production for
>> better download and runtime performance.

Dating myself here: I had to deal with Fortran, long ago. Kernighan  
and Plauger created a structured programming language based on  
Fortran, which translated to Fortran: Ratfor ("Rational Fortran").

Not saying JS is Fortran, but really, unless it floats your boat, why  
not improve the language directly so it can support, declaratively if  
possible, things you have to do with hand tools and magic comments  
and offline sanitizers and so on?

Those extra things may be necessary now, but not forever. And they're  
not a good use of programmer time, even if the initial development  
cost is sunk (see sunk cost fallacy).

>> Does type checking catch misspelling bugs?

It can, yes. Without some notion of an object type, var o = foo();  
o.mispelled can't be caught (suppose foo returns {misspelled: 42}).  
AS3 does this, even for unqualified references if you are within a  
package. But see below.

>>> To the extent that there's static type checking available to catch
>>> errors early on, it's a huge productivity gain.
>> Is Harmony type checking even going to be static?
> These are great questions that I don't know the answer to.

It's ironic that ES4 already dropped its optional static type  
checker. The 'use strict' proposal that was circulated, which was the  
subject of efforts at subsetting and unification with 3.1 folks, was  
like Perl's "use strict" -- use good taste and sanity. It was not  
AS3's static type + sanity checker.

I think the fear and hate around any whiff of static typing tained  
ES4 -- I'm glad to get past it, with Harmony if not with our earlier,  
unnoticed cuts.

> Clearly
> this needs time to sort out in committee.  But I'll weigh in with an
> early opinion that the option to do static type checking in JavaScript
> would, IMO, be a very good thing.

Although ES4 dropped the optional static type checker, ActionScript  
was going to keep its checker, hooked up via the toolchain IIRC.  
There's nothing preventing such extensions, but I don't foresee the  
committee specifying an optional checker. The runtime type system,  
however, needs to be fully specified, and if it's done right, then  
any static type checker will be a conservative partial evaluation of  
some sort.

I've written that interoperation problems could result if different  
browsers used different degrees of conservatism and partial  
evaluation, but I don't expect static checker extensions in most  
browsers, and I'm also not too worried about people testing in the  
more lenient one where the stricter one has enough market share for  
the interop failure to be a problem. The issue will be what works in  
browsers with their dynamic type checking (whatever it ends up being).

Before we cut the type checker from ES4, we were wrestling with when  
a browser might try to check. Code is loaded often; windows and  
frames can reference one another; documents and script tags come and  
go. Cormac suggested just checking when things seem stable or  
quiescent, repeatedly, and issue warnings. Not your "must go to  
editor, fix stupid error, and recompile" experience, but arguably a  
better one than Java heads have.


More information about the Es-discuss mailing list