Optional Strong Typing

J B port25 at gmail.com
Fri Aug 23 12:32:17 PDT 2013


@Brendan - The typing wouldn't be used at all during run-time. So, unlike
AS3, it wouldn't check if types were valid, and it wouldn't try an kind of
implicit coercion.

@Jeremy - "The implication being that implementors start shipping static
compilers where this parsing/stripping takes place (i.e., as a precursory
step to being interpreted)?"  --You would probably know better than me. I'm
not too sure how the various implementations work, but the idea is to
simply ignore all the special typing code.

"The problem with this statement is that "key features" is open for
interpretation." --You're right in that it's open for interpretation, but I
think we can both agree that there are things that most devs would agree
are key features, and most would not, and there are some where it would be
a coin flip; but, as there is a JS extension called "TypeScript" (the key
feature is in the very name), and there is a section in that list I linked
to dedicated to this key feature, I think it's a bit more important than...
generics... for instance.

"The fact is that devs already are building "large scale" projects using
plain ol' JS" --I prefer to have the option of static typing, because there
are definite benefits that are hard to ignore, especially when it's code
refactoring time. I'm not saying building large scale projects with untyped
code can't be done, or even that loose typing is a bad thing (it's not),
but static typing can often make things a whole hell of a lot easier for
larger projects with large amounts of developers.

"I'd be interested in seeing data that the de facto standard is to use
compile-to-JavaScript languages.  My own experience has been quite the
opposite." --For large scale/professional development? I think it's the
very reason why TypeScript exists, and why Visual Studio supports it. Also,
a description given for TypeScript is [1]: "TypeScript is a language for
application-scale JavaScript development."


[1] http://www.microsoft.com/en-us/download/details.aspx?id=34790




On Fri, Aug 23, 2013 at 2:03 PM, Jeremy Martin <jmar777 at gmail.com> wrote:

> > I mean the parser will strip all of the typing info out before it's
> compiled/interpreted.
>
> The implication being that implementors start shipping static compilers
> where this parsing/stripping takes place (i.e., as a precursory step to
> being interpreted)?
>
> > but it's been made worse by ECMAScript's lack of key features
>
> The problem with this statement is that "key features" is open for
> interpretation.
>
> > if JS was a little more large scale development friendly (like
> TypeScript), devs could just use plain ol' JS
>
> The fact is that devs already are building "large scale" projects using
> plain ol' JS (I myself have worked on JS projects with 100k+ loc without
> feeling the need for static typing).  The same goes for Python, PHP, Ruby,
> etc. - this isn't an attack against static typing, but it's hardly
> necessary for a language to be "friendly" for "large scale development".
>
> > 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.
>
> I'd be interested in seeing data that the de facto standard is to use
> compile-to-JavaScript languages.  My own experience has been quite the
> opposite.
>
>
> On Fri, Aug 23, 2013 at 2:24 PM, J B <port25 at gmail.com> 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> 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> 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>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> 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> 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> 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
>>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Jeremy Martin
>>>>> 661.312.3853
>>>>> http://devsmash.com
>>>>> @jmar777
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Jeremy Martin
>>> 661.312.3853
>>> http://devsmash.com
>>> @jmar777
>>>
>>
>>
>
>
> --
> Jeremy Martin
> 661.312.3853
> http://devsmash.com
> @jmar777
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130823/b9454da7/attachment.html>


More information about the es-discuss mailing list