If optional types in JS were implemented like they are in Flow, the types would be stripped before runtime. There are only there for pre-runtime type checking. So nothing related to optimization would change and there would be no runtime type checking.
--- R. Mark Volkmann Object Computing, Inc. > On Jan 13, 2018, at 5:27 PM, Ranando King <[email protected]> wrote: > > Just throwing in my 2 cents. > > I would argue that this represents such a fundamental change to how the > language works, that it would actually represent a new language, even though > they're optional. One problem is in how this would be implemented. Making > types optional introduces a lot of overhead in type checking. Such checks > would have to occur at runtime since ES is a language capable of > self-modification. What's more is that the weight of all these checks > happening at runtime would cause a serious performance penalty to run speed. > > On the flip side, ```class``` already provides some of what you want to do. > The proposal for private fields brings class even closer. If decorators are > allowed to be applied to both non-objects and function parameters, then > decorators could be used to close the gap. All that would be needed is to > define a decorator for each desired type. The decorators would take care of > the type checks while performing the documentation purposes you're saying > would be one of the biggest features. > > Having used many typed languages before, I cannot deny the usefulness of > types. However, where Javascript is concerned, mixing typed and untyped > variables leads to complexities that could be flatly impossible to optimize. > Have you considered what would happen if someone does something like this: > > ```javascript > function doSomething(param: int32) { > //Do something here > } > > var a = 32; > doSomething(a); > a = "foo"; > doSomething(a); > ``` > The engine would not be able to optimize this... ever. Every call would > involve a type check before the call is made since the type of the parameter > cannot be guaranteed to be converted to an int32. The engine would either > need to disallow such a call from an untyped value, or type check every time. > > If you can imagine implementing types as syntactic sugar over what can > already be done in ES6 (maybe with the inclusion of ES7 or proposed features) > you might find a bit less push-back. > > >> On Sat, Jan 13, 2018 at 3:43 PM, <[email protected]> wrote: >> Send es-discuss mailing list submissions to >> [email protected] >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://mail.mozilla.org/listinfo/es-discuss >> or, via email, send a message with subject or body 'help' to >> [email protected] >> >> You can reach the person managing the list at >> [email protected] >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of es-discuss digest..." >> >> Today's Topics: >> >> 1. Re: Proposal: Optional Static Typing (Part 3) (Mark Volkmann) >> >> >> ---------- Forwarded message ---------- >> From: Mark Volkmann <[email protected]> >> To: kai zhu <[email protected]> >> Cc: Brandon Andrews <[email protected]>, es-discuss >> <[email protected]> >> Bcc: >> Date: Sat, 13 Jan 2018 15:43:52 -0600 >> Subject: Re: Proposal: Optional Static Typing (Part 3) >> Not sure if this is the place to debate whether optional type support in >> JavaScript would be a good thing, but I'll throw in my perspective. I used >> to be anti-types. Then I decided to give Flow a try. Initially it felt like >> I was spending a lot of time just learning the syntax and trying to make >> Flow happy. But after a few weeks I caught on and noticed that every time >> Flow complained it was actually correct. Then I needed to so some >> refactoring. That's where the big benefit is for me. I no longer have to >> manually determine what would break if I want to do things like change a >> function name, change a property name in an object, and much more. I just >> make the change and Flow tells me where I need to make adjustments. So >> whether JavaScript adds types, I don't think I'll go back to not having >> them. I'd much rather use Flow or TypeScript than not have types at all. >> >> On Sat, Jan 13, 2018 at 2:45 PM, kai zhu <[email protected]> wrote: >>>> 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. >>> >>> >>> then we agree to disagree. perspective-wise, type-related bugs are among >>> the most easy to debug-and-fix things in javascript (or any serious >>> programming language really). OST brings little to the productivity-table >>> in offering to help solve a relatively trivial problem on the javascript >>> bug-spectrum, while distracting us from bigger-picture show-stoppers. like >>> say, integration-level bugs dealing with async-io and timeouts, that can >>> invalidate design-decisions / performance-tradeoffs made at the >>> application-level and require major code rewrites. >>> >>> for example, did you find out during integration / qa, that mongodb’s >>> scalability claim (using its old mmapv1 storage-engine) is a lie, and even >>> with indexing, its real-world query-performance for your use-case drops >>> dramatically when the db grows past 10gb (to maybe 30-60 seconds / query >>> which is similar to mysql at such scale)? great, now you have to retool the >>> application with a new caching-scheme (or maybe a *shudder* message-queue) >>> to compensate, and perhaps search-and-replace the timeout value everywhere >>> a request to mongodb is made in your code. these are the kinds of bugs >>> that keep javascript-developers awake at night, not some kiddie >>> string-instead-of-number type-error. >>> >>>>> On Jan 14, 2018, at 12:48 AM, Pier Bover <[email protected]> wrote: >>>>> >>>>> 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 <[email protected]> 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" <[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 >>>> >>> >>> >>> _______________________________________________ >>> es-discuss mailing list >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >>> >> >> >> >> -- >> R. Mark Volkmann >> Object Computing, Inc. >> >> _______________________________________________ >> 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
