rant warning > The demand for types as a different approach to code has been so strong in > the past few years that separate languages have been created to deal with the > perceived shortcomings.
where is this demand coming from? newcomers from c# / java who don't know anything about how javascript is used to ship end-user-features and web-products? or those who do and accept the reality that there's always lots of ugly corner-cutting involved with javascript to push a product out the door? static-typing, like classes, makes frontend developers' lives harder; it introduce non-essential, rigid structures, making it difficult to cut the necessary corners (and the inevitable ugly-hacks needed) during integration to ship a web-product. its usually easier for javascript-programmers to ship products if the code and async-logic they have to rewrite during integration and qa were mostly throwaway static-functions (with the assumption they WILL be rewritten during integration). versus classes with static-typing (that are more difficult to rewrite at the late-stage in web-development when it matters the most and have a higher tech-debt penalty). maybe its different @ the large companies / orgs tc39 represents who can hire better-than-average programmers that can magically ship products with correct javascript code right-off-the-bat. but not so for most of the web-industry that can only afford mediocre javascript-programmers whose code-designs and architectures rarely survive integration / productization intact. On Jan 12, 2018 12:19, "Brandon Andrews" <[email protected]> wrote: > > > I'm still yet to read the entire proposal, but with a quick skim, it seems > > to me like this is essentially what Typescript or Flow offers you: i.e. an > > opt-in type system? > > This is in the core of ECMAScript, so the types would be real. The > implementers would be encouraged to use native hardware types. But yes, > outside of that it is an opt-in type system. Language built on top of it > would then benefit from this. I often wonder if languages built on top of ES6 > haven't limited themselves because types don't exist. That is they'd do more, > but didn't because the complexity of transpiling. Stuff like this: > https://github.com/Microsoft/TypeScript/issues/4639 Imagine if ECMAScript > already had all those types and support function overloading. TypeScript > could move on and implement more experimental ideas. > > > I'm wondering if you have any good reasons to want there to be a > > standardised static type annotation syntax within ECMAScript instead of a > > "Bring Your Own Type Checker" system. If you do have some thoughts on this, > > you might also want to include that as a preface on your Github's > > README.You have a "Rationale" bit that seems to ignore the existence of > > these existing systems. > > Did you read the rationale? It specifically says: > > > The demand for types as a different approach to code has been so strong in > > the past few years that separate languages have been created to deal with > > the perceived shortcomings. > > More of the rationale was below the types proposed. I've moved it up into the > rationale since it fits better there. If there's more you think should be > added I'll include it. I'm trying to keep things concise since it's a long > proposal. I could go into an explanation that TypeScript and other languages > are generally just a superset of Javascript and benefit from bringing their > features closer to the base language and possibly the hardware? It seems too > obvious to me to write something like that. > > > > > > From a quick read, I'm more in favor of something that's a little more > > restricted to start, something like what Python has. Python has optional > > static type annotations, but the Python interpreter just ignores them. They > > are present purely for the purposes of tooling, and are silently ignored at > > runtime. > > The goal with this proposal is to get essentially native hardware types where > applicable. All the proposed types have special operator rules, value ranges > (overflow behavior), and in the case of SIMD very real performance impact > behind them. While documentation hints are a side-effect, I'm more focused > instead for pushing ECMAScript toward being a more powerful language. Python > is a classic example of where data type shortcomings lead to unintuitiveness > or weird design like: https://docs.python.org/2/library/array.html I'm trying > to avoid such things. > > > One of the reasons why I'd prefer a simpler approach to start is that > > TypeScript and Flow, the two main implementations that add syntax, have a > > *very* similar syntax, but have several nuances that would make a heavier > > proposal much harder to accomplish: > > > - Flow has `?Foo` for optional types, TypeScript just uses unions. > > I have a section on unions with a small explanation on why I left it out. I > kept it simple by only adding nullable types. Right now someone would > overload or use 'any'. > > > - TypeScript has mapped/index types, where Flow uses special named types. > > I didn't include these. > > > - Flow allows omitted parameter names in function types, TypeScript only > > allows named parameters with implicit `any` types. > > I created an issue to be more explicit about optional and default typed > parameters and the behavior. > > > - Flow has exact types, TypeScript doesn't. > > I hadn't even considered something like this. It sounds interesting for > configuration options. They introduce new tokens. Something I'm very much > avoiding for this initial proposal. > > > - Flow has `opaque type`, TypeScript only has `type`. > > Something to be decided later. Doesn't create breaking changes to add later. > > > - Flow constrains with `T: Super`, TypeScript uses `T extends Super`. > > There's a section on generics and why it isn't included already. I'm with you > that it's far too complex to add in with initial types. There's no breaking > changes introduced by adding it later. (Mostly because it introduces new > tokens which would be a huge deal). > > > - Flow has existential types, TypeScript doesn't. > > I definitely haven't included this. Flow is a few steps ahead of this > proposal. > > It seems like a lot of these features already aren't included in the > proposal. I definitely hold your view that the proposal has to be minimal, > but I think my minimal is functionally minimal. Something that when > implemented allows developers to experiment and then discussion can progress > from there to how more features can be added. I'm trying to be thourough > though as to not harm a future proposal so if any of my decisions block > something I'm open to changes. > > Most of my thoughts and focus have been on what I think of as the basics. How > types interact with declarations, functions, classes, destructuring, > allocation, and control structures. The future consideration sections are > mostly a catalogue of ensuring that these basic initial features and designs > will work as the language incorporates other proposals. > _______________________________________________ > 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
