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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >> > [email protected] >> > https://mail.mozilla.org/listinfo/es-discuss >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
