Optional Strong Typing

Jeremy Martin jmar777 at gmail.com
Fri Aug 23 12:03:49 PDT 2013


> 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/af95979f/attachment.html>


More information about the es-discuss mailing list