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
