<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px">perspective-wise, type-related bugs are among the most easy to debug-and-fix</span> </blockquote><div><br></div><div>Eric Elliot has already argued that types do not alleviate bugs, and quite frankly it is irrelevant. The real value of OST is to be able to express structures and write more obvious code.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px">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.</span></blockquote><div><br></div><div>So first you used mediocre programmers to argue against OST, and now you are using a (terrible) product that forces you to use workarounds to argue against OST. What's your point really?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jan 13, 2018 at 3:45 PM, kai zhu <span dir="ltr"><<a href="mailto:kaizhu256@gmail.com" target="_blank">kaizhu256@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span class=""><div><blockquote type="cite"><div dir="ltr"><div>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.</div></div></blockquote></div></span><div><div dir="ltr"><div><br></div><div>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.</div><div><br></div><div>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.</div></div></div><div><div class="h5"><br><div><blockquote type="cite"><div>On Jan 14, 2018, at 12:48 AM, Pier Bover <<a href="mailto:pierbover11@gmail.com" target="_blank">pierbover11@gmail.com</a>> wrote:</div><br class="m_2728761574445210189Apple-interchange-newline"><div><div dir="ltr">I strongly disagree with kai zhu.<div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px">where is this demand coming from? newcomers from c# / java<br></span><span style="font-size:12.8px">who don't know anything about how javascript is used to ship<br></span><span style="font-size:12.8px">end-user-features and web-products?</span></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px">static-typing, like classes, makes frontend developers' lives harder;<br></span><span style="font-size:12.8px">it introduce non-essential, rigid structures, making it difficult to<br></span><span style="font-size:12.8px">cut the necessary corners (and the inevitable ugly-hacks needed)<br></span><span style="font-size:12.8px">during integration to ship a web-product.</span></blockquote><div><br></div></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px">maybe its different @ the large companies / orgs tc39 represents who<br></span><span style="font-size:12.8px">can hire better-than-average programmers that can magically ship<br></span><span style="font-size:12.8px">products with correct javascript code right-off-the-bat. but not so<br></span><span style="font-size:12.8px">for most of the web-industry that can only afford mediocre<br></span><span style="font-size:12.8px">javascript-programmers whose code-designs and architectures rarely<br></span><span style="font-size:12.8px">survive integration / productization intact.</span></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jan 13, 2018 at 1:59 AM, kai zhu <span dir="ltr"><<a href="mailto:kaizhu256@gmail.com" target="_blank">kaizhu256@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">rant warning<br>
<br>
> 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.<br>
<br>
where is this demand coming from? newcomers from c# / java<br>
who don't know anything about how javascript is used to ship<br>
end-user-features and web-products? or those who do and accept the<br>
reality that there's always lots of ugly corner-cutting involved with<br>
javascript to push a product out the door?<br>
<br>
static-typing, like classes, makes frontend developers' lives harder;<br>
it introduce non-essential, rigid structures, making it difficult to<br>
cut the necessary corners (and the inevitable ugly-hacks needed)<br>
during integration to ship a web-product.<br>
its usually easier for javascript-programmers to ship products if the<br>
code and async-logic they have to rewrite during integration and qa<br>
were mostly throwaway static-functions (with the assumption they WILL<br>
be rewritten during integration). versus classes with static-typing<br>
(that are more difficult to rewrite at the late-stage in<br>
web-development when it matters the most and have a higher tech-debt<br>
penalty).<br>
<br>
maybe its different @ the large companies / orgs tc39 represents who<br>
can hire better-than-average programmers that can magically ship<br>
products with correct javascript code right-off-the-bat. but not so<br>
for most of the web-industry that can only afford mediocre<br>
javascript-programmers whose code-designs and architectures rarely<br>
survive integration / productization intact.<br>
<br>
On Jan 12, 2018 12:19, "Brandon Andrews" <<a href="mailto:warcraftthreeft@sbcglobal.net" target="_blank">warcraftthreeft@sbcglobal.net</a><wbr>> wrote:<br>
><br>
> > 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?<br>
><br>
> 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: <a href="https://github.com/Microsoft/TypeScript/issues/4639" rel="noreferrer" target="_blank">https://github.com/Microsoft/T<wbr>ypeScript/issues/4639</a> Imagine if ECMAScript already had all those types and support function overloading. TypeScript could move on and implement more experimental ideas.<br>
><br>
> > 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.<br>
><br>
> Did you read the rationale? It specifically says:<br>
><br>
> > 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.<br>
><br>
> 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.<br>
><br>
><br>
><br>
><br>
> > 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.<br>
><br>
> 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: <a href="https://docs.python.org/2/library/array.html" rel="noreferrer" target="_blank">https://docs.python.org/2/libr<wbr>ary/array.html</a> I'm trying to avoid such things.<br>
><br>
> > 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:<br>
><br>
> > - Flow has `?Foo` for optional types, TypeScript just uses unions.<br>
><br>
> 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'.<br>
><br>
> > - TypeScript has mapped/index types, where Flow uses special named types.<br>
><br>
> I didn't include these.<br>
><br>
> > - Flow allows omitted parameter names in function types, TypeScript only allows named parameters with implicit `any` types.<br>
><br>
> I created an issue to be more explicit about optional and default typed parameters and the behavior.<br>
><br>
> > - Flow has exact types, TypeScript doesn't.<br>
><br>
> 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.<br>
><br>
> > - Flow has `opaque type`, TypeScript only has `type`.<br>
><br>
> Something to be decided later. Doesn't create breaking changes to add later.<br>
><br>
> > - Flow constrains with `T: Super`, TypeScript uses `T extends Super`.<br>
><br>
> 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).<br>
><br>
> > - Flow has existential types, TypeScript doesn't.<br>
><br>
> I definitely haven't included this. Flow is a few steps ahead of this proposal.<br>
><br>
> 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.<br>
><br>
> 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.<br>
> ______________________________<wbr>_________________<br>
> es-discuss mailing list<br>
> <a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
> <a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listi<wbr>nfo/es-discuss</a><br>
______________________________<wbr>_________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listi<wbr>nfo/es-discuss</a><br>
</blockquote></div><br></div>
</div></blockquote></div><br></div></div></div></blockquote></div><br></div>