Proposal: Optional Static Typing (Part 3)

Mark Volkmann r.mark.volkmann at gmail.com
Sat Jan 13 21:43:52 UTC 2018


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 <kaizhu256 at gmail.com> 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 <pierbover11 at gmail.com> 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 <kaizhu256 at 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" <warcraftthreeft at 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/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
>> > es-discuss at mozilla.org
>> > https://mail.mozilla.org/listinfo/es-discuss
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
R. Mark Volkmann
Object Computing, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180113/074f00f0/attachment-0001.html>


More information about the es-discuss mailing list