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/libr >> ary/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
