Proposal: Static Typing

Andrea Giammarchi andrea.giammarchi at gmail.com
Mon Mar 25 09:17:07 UTC 2019


the day I'll disable autocorrect everywhere will be always too late ...

transpolar => transpilers
trample => transpile





On Mon, Mar 25, 2019 at 10:13 AM Andrea Giammarchi <
andrea.giammarchi at gmail.com> wrote:

> I am having hard time understanding the counter argument "you need a
> transpolar anyway".
>
> That's been the case since ES2015 landed with breaking syntax that has
> been required mandatory transpilation to keep it backward compatible, with
> things also not really transpilble such as classes with built-in extends
> ability.
>
> Why suddenly the "need to transpile" is considered a point against any new
> JS feature? Are we already done with JS, if that's the case?
>
> TypeScript exists and it has its own problems, 'cause its slightly
> diversions from what's defined via TC39 causes just confusion (i.e. private
> fields, to name one, built-in extends still broken if you target ES5, while
> Babel 7 fixed that, and template literals behave differently too - Babel 7
> is the only one producing a standard behavior)
>
> On top of that, many things recently landed in JS has been inspired by
> CoffeeScript ... where was the "just use CoffeeScript" argument at that
> time? Transpilers were already a thing then too.
>
> Moreover ...
>
> > the real value of strict types, in my view, is at development time, not
> at run time.
>
> This is not correct. Check what AssemblyScript managed to do via types,
> targeting WASM instead of non-typed JS
>
> If TypeScript, with its quirks, will be the language that help developers
> and win JS in the WASM field, we can start considering JS a second class
> citizen of the Web (and soon of the backend too, see deno).
>
> Is this where we are with JS?
>
> > I would be curious to know if anybody has a usage for them at run time
>
> Developers might not have such usage, but V8 / Chackra / JSC /
> SpiderMonkey might spin up optimizations ahead of time, enabling right away
> hot code.
>
> > a "toolchain" that allows strict typing using JavaScript without having
> to "use TypeScript".
>
> even if it'll end up being identical or redundant, but I doubt it, for
> many companies/teams the least third parts dependencies you have the better
> is for code reliability.
>
> I personally don't trust TS because it breaks when it targets ES5 and I
> cannot control what other people target, but I would trust the standard
> path and tools aiming at all cost to trample it right, whenever transpiring
> is needed.
>
> With Edge moving to use Chrome, and Firefox and WebKit always catching up,
> these days introducing anything new might need transpilers just for a
> couple of years, instead of decades.
>
> Best Regards
>
>
>
>
>
> On Mon, Mar 25, 2019 at 9:55 AM Naveen Chawla <naveen.chwl at gmail.com>
> wrote:
>
>> Yes the real value of strict types, in my view, is at development time,
>> not at run time.
>>
>> However I would be curious to know if anybody has a usage for them at run
>> time, and an example of such a case...
>>
>> Otherwise, yes a "toolchain" that allows strict typing using JavaScript
>> without having to "use TypeScript".
>>
>> On Mon, 25 Mar 2019 at 04:58, Ranando King <kingmph at gmail.com> wrote:
>>
>>> One thing is definitively true. Any static type system added to ES must
>>> not be mandatory. Untyped code must be able to call typed code without
>>> forcing references into a fixed type. Likewise, typed code must be able to
>>> call untyped code without forcing references to give up type guarantees.
>>>
>>> On Sun, Mar 24, 2019 at 8:48 PM kai zhu <kaizhu256 at gmail.com> wrote:
>>>
>>>> i share a similar concern that static-typing makes little sense in
>>>> high-churn-rate UX-workflow-programming.
>>>>
>>>> it encourage people to bikeshed for correctness, on low-level code that
>>>> frequently gets rewritten every few weeks/months -- and with often
>>>> demoralizing effects.
>>>>
>>>> > On 24 Mar 2019, at 17:26, Bergi <a.d.bergi at web.de> wrote:
>>>> >
>>>> > Hello,
>>>> > to play the devils advocate: why does JavaScript need static typing?
>>>> >
>>>> > Your proposal doesn't really answer that. Sure, it mentions tooling
>>>> and
>>>> > IDEs that can provide you with type hints and complain on mistakes,
>>>> but
>>>> > things like Flow and Typescript do this today already.
>>>> > What's your goal, to have JS engines run Typescript(-like) code
>>>> natively
>>>> > without transpiling? For backwards-compatibility you'd have to do that
>>>> > anyway, especially if new type system features are introduced
>>>> incrementally.
>>>> >
>>>> > What's the point of building this feature into engines? It just
>>>> provides
>>>> > additional complexity. Not to mention the difficulty of finding a
>>>> > suitable type system that is both sophisticated enough to describe all
>>>> > useful code (not taking away too much flexibility) and simple enough
>>>> to
>>>> > understand without a CS degree. And which interfaces well with
>>>> un-typed
>>>> > completely dynamic code.
>>>> >
>>>> > What does "static typing" even mean to you in a dynamic scripting
>>>> > language? JavaScript is not compiled by the developer, it is run by
>>>> the
>>>> > user. Where (when) do you expect types to be checked? Should the
>>>> engine
>>>> > throw early errors (during parsing)? During parsing of which parts of
>>>> > the code, even when "normal" (untyped) code is calling into typed
>>>> code?
>>>> > Or do you expect dynamic runtime errors, like when assigning an
>>>> invalid
>>>> > value to a "typed variable" or calling a "typed function" with wrong
>>>> > arguments? Are type definitions completely constant or could they be
>>>> > mutated/extended/etc dynamically (and what happens when you introduce
>>>> > new types with `eval` or by loading another script)?
>>>> >
>>>> > A proposal would need to provide an objective that answers all these
>>>> > questions, before even considering any particular type system or
>>>> syntax.
>>>> >
>>>> > One way to go forward that I can see would be a proposal that
>>>> reserves a
>>>> > relatively unrestricted syntax for type annotations (which are already
>>>> > considered during every grammar amendment anyway, for compatibility
>>>> with
>>>> > Flow/Typescript), but not assign any semantics to them and require
>>>> > engines to simply ignore them. External tooling could then use these
>>>> > annotations according to its own rules.
>>>> >
>>>> > kind regards,
>>>> > Bergi
>>>> > _______________________________________________
>>>> > es-discuss mailing list
>>>> > es-discuss at mozilla.org
>>>> > https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> es-discuss at mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20190325/712d2391/attachment-0001.html>


More information about the es-discuss mailing list