Proposal: Optional Static Typing (Part 3)

Pier Bover pierbover11 at gmail.com
Tue Jan 16 14:01:41 UTC 2018


>  javascript-fatigue is partly the realization from naive newcomers that
you almost always end up with spaghetti-code after integration, no matter
how hard you fight it

And don't you think the lack of OST is in part fueling this situation?

On Tue, Jan 16, 2018 at 7:44 AM, kai zhu <kaizhu256 at gmail.com> wrote:

> more ranting.
> tldr - javascript-programmers are more productive spending their
> limited-time documenting and writing validation-code for endpoint-level
> rest-apis instead of for code-level business-logic (swagger/openapi is more
> useful than OST/flow/typescript).
>
> i'm generally a javascript-architecture skeptic.  from my experience in
> industry, there is zero-correlation between careful architecting (*cough*
> bikeshedding) and successfully getting over the javascript-integration hump
> to ship a product.  the “best" architecture/design for any given
> web-project is whatever ad-hoc hacks/rewrites/fire-fighting it takes to get
> you past the integration-stage (and javascript-fatigue is partly the
> realization from naive newcomers that you almost always end up with
> spaghetti-code after integration, no matter how hard you fight it).  it
> might be different at microsoft/facebook/google, but their abnormal tooling
> environments (and resulting skewed world-view of javascript) are hardly
> representative of the industry as a whole.
>
> what does correlate with successfully shipping a product, is having
> well-documented endpoint rest-apis, so the frontend-folks aren’t completely
> clueless during integration when they try talking to the backend, and it
> doesn’t respond or timeout for some reason.  a web-project has a higher
> chance of shipping successfully if you spend your limited engineering-time
> doing integration-level documentation and validation-checking (using
> swagger as shown in following screenshots) instead of code-level OST which
> nobody talking to your server during integration cares about:
>
> (these screenshots are from real-world endpoint rest-apis that have been
> documented with integration-level type-checking using swagger -
> https://kaizhu256.github.io/node-swgg-google-maps/build..
> beta..travis-ci.org/app/)
>
>
>
>
>
>
>
>
>
> On Jan 11, 2018, at 10:01 PM, Isiah Meadows <isiahmeadows at gmail.com>
> wrote:
>
> 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.
>
> Conversely, PHP took a similar approach and initially also made it
> cosmetic to start, only later taking advantage of *some* type annotations
> by adding runtime behavior to some of the simpler ones (like primitives).
>
> 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.
> - TypeScript has mapped/index types, where Flow uses special named types.
> - Flow allows omitted parameter names in function types, TypeScript only
> allows named parameters with implicit `any` types.
> - Flow has exact types, TypeScript doesn't.
> - Flow has `opaque type`, TypeScript only has `type`.
> - Flow constrains with `T: Super`, TypeScript uses `T extends Super`.
> - Flow has 3 different ways of importing bindings a module (depending on
> what's being imported), TypeScript only has one.
> - Flow has existential types, TypeScript doesn't.
>
> Also, both TypeScript and Flow are still working out how to properly type
> some of the more advanced JS (like variadic functions and auto-curried
> functions), so their syntax is *still* not exactly stable enough I'd feel
> comfortable encoding much into the spec. (They do have a stable core,
> though.)
>
> One other thing is that multiple active proposals could end up requiring
> TS and/or Flow to substantially change parts of their syntax, including:
>
> - Private [fields][1] and [methods][2] (stage 3 and 2 respectively,
> affects TS)
> - [First class protocols][3] (stage 1, affects both TS and Flow)
> - [Typed literals][4] (stage 1, affects TS mostly)
>
> [1]: https://github.com/tc39/proposal-class-fields
> [2]: http://github.com/tc39/proposal-static-class-features/
> [3]: https://github.com/michaelficarra/proposal-first-class-protocols
> [4]: https://github.com/mikewest/tc39-proposal-literals
>
> -----
>
> Isiah Meadows
> me at isiahmeadows.com
>
> Looking for web consulting? Or a new website?
> Send me an email and we can get started.
> www.isiahmeadows.com
>
> On Thu, Jan 11, 2018 at 3:09 AM, Pranay Prakash <pranay.gp at gmail.com>
> 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?
>>
>> 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.
>>
>> Waiting to hear more thoughts on this :)
>>
>> On Thu, 11 Jan 2018 at 11:56 Brandon Andrews <
>> warcraftthreeft at sbcglobal.net> wrote:
>>
>>> It's been a year and a half since my last post and I've made a number of
>>> small changes and corrections over 2.5 years. The proposal is still on my
>>> github at:
>>>
>>>
>>> https://github.com/sirisian/ecmascript-types
>>>
>>> I've talked to a lot of people about it, but I haven't gotten much
>>> criticism or suggested improvements. I'm a bit in over my head in trying to
>>> flesh out all the details or all the nuanced syntax changes that a
>>> championed proposal would be expected to do. That said I've been making
>>> more changes lately to try to find edge cases and potential problems.
>>>
>>>
>>> I've been jotting down issues here: https://github.com/sirisian/ec
>>> mascript-types/issues I closed a number of them recently as I made
>>> changes.
>>>
>>> If anyone has any comments on what I should expand, look into more, or
>>> change I'm open to discussing them here or on github.
>>>
>>> One issue in particular is this: https://github.com/sirisian/ec
>>> mascript-types/issues/15 It covers whether I should introduce a new
>>> assignment operator to my proposal. Maybe there's another way to look at it
>>> or a different solution. I need fresh eyes on the whole proposal really to
>>> get a list of new issues to tackle this year.
>>>
>>> I'm also not against having one or multiple people champion it and
>>> working on it without me. (I haven't been able to dedicate time to read the
>>> ECMAScript spec and really understanding the grammar fully so having
>>> someone qualified to take over would help the proposal a lot).
>>>
>>>
>>> Thanks for reading the proposal for anyone that has the time.
>>> _______________________________________________
>>> 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
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180116/eaa5bbfb/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2018-01-16 at 7.04.28 PM.png
Type: image/png
Size: 182107 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180116/eaa5bbfb/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2018-01-16 at 7.08.19 PM.png
Type: image/png
Size: 69142 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180116/eaa5bbfb/attachment-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2018-01-16 at 7.05.04 PM.png
Type: image/png
Size: 100711 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180116/eaa5bbfb/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2018-01-16 at 6.55.38 PM.png
Type: image/png
Size: 59871 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180116/eaa5bbfb/attachment-0011.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2018-01-16 at 7.13.24 PM.png
Type: image/png
Size: 141494 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180116/eaa5bbfb/attachment-0012.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2018-01-16 at 7.27.24 PM.png
Type: image/png
Size: 236024 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180116/eaa5bbfb/attachment-0013.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2018-01-16 at 6.54.16 PM.png
Type: image/png
Size: 72837 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180116/eaa5bbfb/attachment-0014.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2018-01-16 at 7.25.19 PM.png
Type: image/png
Size: 65619 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180116/eaa5bbfb/attachment-0015.png>


More information about the es-discuss mailing list