I strongly disagree with kai zhu. 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?
The idea that optional static typings (OST from now on) are some "contamination" from other languages is naive. Programmers are not asking for OST because they lack perspective, quite the contrary, it's simple common sense. Types make code more obvious and deliberate. The importance of obviousness in code cannot be overstated. I'm not a guy coming from C# or Java. In my 20+ years of professional web dev I've spent 80% of my time writing ES languages. I wrote with ES4 extensively (AS3) and I experienced OST myself for years. In fact AS3 was 11 years ago a better language than JS is today and one of the biggest reasons for that were OST. 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. It seems you are missing the word "optional". Current optional ES classes are nothing more than syntactic sugar over prototypal inheritance, and since these classes were introduced no flexibility has been lost. With the introduction of OST no flexibility would be lost either and we could happily ship quick and dirty solutions if we needed/wanted to. 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. You are again ignoring the optional factor. With OST JavaScript could still be used by mediocre programmers, but maybe they could start architecturing their code better and survive integration. That was exactly my experience when I started to write AS3 back in 2007. It made me a better programmer and it was my stepping to stone to C#, C++, Go, Swift, etc. I really don't understand the irrational aversion to OST or classes in ES. If you don't want to use them, well don't use them. These features makes sense for a lot of programmers and IMO EcmaScript should not be a bastion of resistance against other languages, specially when it's the only language for building front end applications. On Sat, Jan 13, 2018 at 1:59 AM, kai zhu <kaizhu...@gmail.com> wrote: > 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" <warcraftthre...@sbcglobal.net> > 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 > > es-discuss@mozilla.org > > https://mail.mozilla.org/listinfo/es-discuss > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
