> 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] > <mailto:[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] > <mailto:[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 > > <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 > > <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] <mailto:[email protected]> > > https://mail.mozilla.org/listinfo/es-discuss > > <https://mail.mozilla.org/listinfo/es-discuss> > _______________________________________________ > es-discuss mailing list > [email protected] <mailto:[email protected]> > https://mail.mozilla.org/listinfo/es-discuss > <https://mail.mozilla.org/listinfo/es-discuss> >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
