Proposal: Optional Static Typing (Part 3)

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Proposal: Optional Static Typing (Part 3)

Brandon Andrews
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/ecmascript-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/ecmascript-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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Optional Static Typing (Part 3)

Pranay Prakash
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 <[hidden email]> 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/ecmascript-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/ecmascript-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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Optional Static Typing (Part 3)

Isiah Meadows-2
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)

-----

Isiah Meadows
[hidden email]

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 <[hidden email]> 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 <[hidden email]> 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/ecmascript-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/ecmascript-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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Optional Static Typing (Part 3)

Brandon Andrews
> 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/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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Optional Static Typing (Part 3)

Jordan Harband
(btw the SIMD proposal has been dropped to stage 1, and implementations are not pursuing implementing it in JS for now https://github.com/tc39/proposals/blob/master/inactive-proposals.md)

On Thu, Jan 11, 2018 at 9:18 PM, Brandon Andrews <[hidden email]> 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/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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Optional Static Typing (Part 3)

kai zhu
In reply to this post by Brandon Andrews
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" <[hidden email]> 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/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
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Optional Static Typing (Part 3)

Isiah Meadows-2
Inline. Also, in summary, types just get in your way at times, but in
others, it's the best thing you could ever have.

-----

Isiah Meadows
[hidden email]

Looking for web consulting? Or a new website?
Send me an email and we can get started.
www.isiahmeadows.com


On Sat, Jan 13, 2018 at 1:59 AM, kai zhu <[hidden email]> 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?

Generally, the latter. C#/Java people tend to want static types, then
they wind up [writing unidiomatic TypeScript][1], wondering why it
won't work even there. But most users who are actually active in
wanting types tend to come from the JS community (there's a reason TS
and Flow are both incredibly expressive - they have to be to address
the average JS developer's needs).

[1]: https://github.com/Microsoft/TypeScript/issues/202#issuecomment-302095192

>
> 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.

Yeah, if your project happens to be less than about 30K lines of code.
I've got a personal pet project that's just above that, and I'm
already feeling the pains of the lack of type checking (I'm doing type
and value assertions all over the place). However, a 10K line of code
project with reasonable consistency within would fare better, since
it's much easier to keep in your head.

Also, cutting corners and dropping ugly hacks is possible in both
TypeScript and Flow, as they both have an `any` type which effectively
disables type checking. It's useful for unsafe casts that you know are
correct. Oh, and TS is technically a superset of JS, so `any` is the
default, absent any other type declarations.

As for classes, I'll agree they're overused, but there are times when
they're useful - they make for great DSLs and easier-to-use APIs, and
there are rare occasions where you actually need inheritance (they
make certain forms of extensibility easier, and they take less memory
than copying).

> 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).

Actually, it's the other way around: static typing has a higher
up-front cost, because it's much more rigid to start. It's harder to
write the initial prototype when you're [simultaneously verifying
it][2], but it's easier to make late-stage changes without introducing
new bugs\*. Trust me: I have first-hand experience with both
approaches.

\* Unless, of course, you have a very annoying
client/customer/manager/etc. who decided to ask for you to change half
of the project entirely for whatever reason, in which it's a people
problem, not a technical problem.

[2]: https://en.wikipedia.org/wiki/Curry%E2%80%93Howard_correspondence

>
> 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.

Note that in no place did *anyone* request that static types be
mandatory, and most of us had responded to suggest *reducing* the
scope of the proposal, not broaden it. Also, your premise of "can
magically ship ... with correct JS code right off the bat" is a straw
man based on the opposite of what static types are for. The whole
point of static types (and type checking in general) is founded on the
assumption you can't trust people to not make mistakes. If you can use
a program to help check those mistakes for you and alert you of them,
you're more likely to correct those mistakes before sending them to
production.

>
> On Jan 12, 2018 12:19, "Brandon Andrews" <[hidden email]> 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/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
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Optional Static Typing (Part 3)

Pier Bover
In reply to this post by kai zhu
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 <[hidden email]> 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" <[hidden email]> 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/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
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Optional Static Typing (Part 3)

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



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Optional Static Typing (Part 3)

Pier Bover
perspective-wise, type-related bugs are among the most easy to debug-and-fix 

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.
 
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.

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?

On Sat, Jan 13, 2018 at 3:45 PM, kai zhu <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> 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/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
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Optional Static Typing (Part 3)

Mark Volkmann
In reply to this post by kai zhu
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> 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/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
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




--
R. Mark Volkmann
Object Computing, Inc.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Optional Static Typing (Part 3)

Michał Wadas
In reply to this post by Brandon Andrews
I have many concerns about typing. 

Types are opinionated

Choice of type system significantly affects code that people write. As observed in many codebases, adoption of TypeScript favors object oriented style over functional style.

Choosing type system descending from Java type system is message "creators of language endorse OOP as main JavaScript paradigm". It's fine for TypeScript to take opinionated approach, but it's unlikely with TC39. 

If you don't see limitations of eg. TypeScript type system, try to express in its terms: "function takes subclass of Foo as parameter Ctor and returns subclass of Ctor extended by some methods". Not to mention reflection here (think of Bluebird's promisification)... 

Functional languages usually provide better type systems, but complexity can be prohibitive. Moreover, I don't know any programming language that combines type system as strong as eg. Idris and object oriented programming. 

Runtime type checking

Runtime type checking would incur significant cost on browsers (and JavaScript parse time is already an issue for smartphone CPUs). It's especially important to remember about dynamic nature of JavaScript. TypeScript can rely on assumption that no one creates accessors on Object.prototype or Array prototype, but it's unacceptable for language feature.

Therefore, chance of someone calling Object.defineProperty(Array.prototype, 7,...) requires type checking on every property assignment. There hundreds of ways to screw type system, including changes in inheritance in runtime. 

foo instanceof Foo; // true 
foo instanceof Foo; // false
foo instanceof Foo; // true 

Ups, someone overwritten Function.prototype[Symbol.hasInstance] with () => Math.random() > 0.5.

Compilation time type checking

Compilation time type checking requires tooling. If language relies on external  tool to strip type definitions, why whole typing can't be left to external tool? External tools can iterate faster than language and can compete. 

People hates writing types

That's why C++ have auto, Kotlin have val, and it's  significant reason why dynamically typed languages became popular. Type inference is awesome, but integrating it with existing JavaScript code in backwards compatible way seems to be hard.





_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: Proposal: Optional Static Typing (Part 3)

Bruno Jouhier
In reply to this post by Brandon Andrews
I'm coming from a long journey through dynamically typed (mostly LISP and JavaScript) and statically typed (mostly C, C++, Java and C#) languages, I'm now using TypeScript and I really like the mix of power and flexilbility that OST provides.

From my experience, the main benefits of OST are the following:

* self-documentation: I work with a large team and developers often need to explore code or use APIs written by others. Types are very helpful and save a lot of time. Even more with modern code editors thanks to intellisense, jump to definitions, ...
* code refactoring: I work on prototypes and I do a lot of code refactoring in the early stages of a project. Refactoring is painful without types: you either have to tediously check that you have put all the pieces back together, or accept to run several debugging passes to eliminate all the silly refactoring errors. OST reduces the cognitive load (you don't have to remember all the loose ends) and it saves a lot of time overall.

The pain point is that code needs to be transpiled. There are tools to help (and the TypeScript compiler has a file watch option) but for simple scripts/projects it would be nice to be able to run directly without preprocessing.

I don't mind if type systems remain outside of the ES spec but a nice improvement would be to have a provision for OST syntaxes in ES so that ES engines could load and execute code that contains type annotations, by just treating them as comments. Then, we would not need to transpile during development. 

I don't know if there are enough syntax markers to allow this without adding complete type grammars to the language. I imagine that a lookahead that kicks off after certain markers (colon, as/type/interface/declare keywords) and that skips certain token types (identifiers, literals, |, &) and balanced parentheses/curly braces/brackets may be able to do the job. But this might be easier said than done (and ASI might get in the way). 

Could this be a viable compromise?

Bruno

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: Proposal: Optional Static Typing (Part 3)

Bruno Jouhier
In reply to this post by Brandon Andrews
@Brandon

There are already two popular OST: TypeScript and Flow. They have tools, large communities, type libraries for a large number of ES modules, etc. 

It might be easier to submit your ideas to these communities than to push a third proposal. At least, a gap analysis would help people who already know these systems.

Bruno

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Optional Static Typing (Part 3)

Brandon Andrews
In reply to this post by Michał Wadas
> (btw the SIMD proposal has been dropped to stage 1, and implementations are not pursuing implementing it in JS for now tc39/proposals/blob/master/inactive-proposals.md)

Yeah, that seemed predictable. I wanted the SIMD operations to use operators intuitively. That and all the SIMD core types lacked ECMAScript equivalents. Like one expected to be able to write SIMD code and not lose all the speed-up dealing with Number or casts. Was never really sold on the idea of having a float32x4 when the language can't even represent float32 without a TypedArray. Putting the cart before the horse.


> where is this demand coming from?

Wherever TypeScript and Flow are used; so companies like Microsoft and Facebook. I know friends that use TypeScript exclusively for application development with teams of over three people. Personally I've worked on projects over 25K lines of Javascript usually by myself, and while it would have been nice to have types it's not necessary for what I did. I didn't use classes either and relied more on a mix between agile and cowboy programming. Things have changed over the years though.

One of the reasons I started wanting types and created this specification years ago was because I was working on more complex applications. Essentially taking programs that would be written (or were written in my case) in C++ and C#/WPF and writing them for the web for Android, Mac, Linux, and Windows. Part of this involved architecting and designing out ORM systems with database types and schemas. I was also doing a lot of binary WebSocket stuff at the time, some of which was somewhat performance critical with node.js on the backend. So to answer your question the demand would be developers that have transitioned to using HTML5 and Javascript for application development in teams. (In my case programs for all OSes along with web applications and interfaces). There's other reasons. My work projects have spawned off personal projects for myself in networking in databases. I'd like to use Javascript more, but I tend to fallback to C++ or C# simply because of the lack of types.

I find it strange to pretend like the demand isn't there. TypeScript, and Flow have existed for a while now and I hear about them all the time in my circles. OST as described in my mind brings in the core features that people are seeking such that they can use Javascript again by itself in the future. Some people might not use them, but a lot of people would in certain places. It also might open up new features and spin-off languages since types would have already been handled without reinventing the wheel like AS3, TypeScript, and Flow did.

Also realize I never intended this proposal to be implemented right away. It could take years still. Part of my slight worry as things draw on is that with all these proposals floating around that one of them will change the grammar slightly add new tokens, ASI, or other slight changes and make types infeasible or very inconsistent across the language.


> Choosing type system descending from Java type system is message "creators of language endorse OOP as main JavaScript paradigm". It's fine for TypeScript to take opinionated approach, but it's unlikely with TC39.

More like descending from Actionscript 3. I wouldn't relate a type system to OOP though. People still write non-OOP TypeScript. If you want to blame the rise of classes in Javascript you'd be looking at the introduction of classes themselves. You give programmers what they want and they'll use them for frameworks and programming. (The old way was just ugly or cumbersome so people avoided it was my experience). In any case classes are already in the spec. Types aren't going to change that.

> Runtime type checking would incur significant cost on browsers (and JavaScript parse time is already an issue for smartphone CPUs). It's especially important to remember about dynamic nature of JavaScript. TypeScript can rely on assumption that no one creates accessors on Object.prototype or Array prototype, but it's unacceptable for language feature.

I'm glad you brought that up. I've been thinking about this problem of types changing for a while. Can you write down a bunch of examples and scenarios? It would help to analyze them. (Creating an issue with all of them would be ideal).

Part of this has had me considering if freezing classes (and all recursively referenced types) used in the type system is viable. That is referencing a class in say a variable declaration or function signature would freeze the class. Seems a bit extreme of an option though that would cause problems for certain designs or ideas later where people want to add, remove, or update properties. Is it that important? When would a freeze even happen?

I think having a lot of examples would make this easier to analyze.


> People hates writing types
> That's why C++ have auto, Kotlin have val, and it's significant reason why dynamically typed languages became popular. Type inference is awesome, but integrating it with existing JavaScript code in backwards compatible way seems to be hard.

Part of this is to find out how hard a lot of this stuff is. Speaking of type inference someone opened a ticket that started a small discussion: https://github.com/sirisian/ecmascript-types/issues/27 Basically trying to figure out if larger non-Number literals could even be placed into the language without unforeseen issues.

> It might be easier to submit your ideas to these communities than to push a third proposal. At least, a gap analysis would help people who already know these systems.

I've talked to people in the communities in the past. They seem beyond caring about Javascript. I've been told to "just use TypeScript" on a few occasions with little input. I'd probably have to find someone very specific on their team willing to help. That's more or less why I made a comment about looking for a champion or a few to take over. If someone wants to pass this along or link my github I'd appreciate it.


Isiah, I was looking through my original old post. I must have missed the emails a year ago:

> First, no type checker (TypeScript, Flow, or any other) can fully check the core language (most notably bind, apply, call, and Object.assign).

> Second, they both still are missing some pretty significant features required for typing common JavaScript idioms (higher kinded types for Fantasy Land and Ramda users, variadic generics for bind, call, and apply, n-ary unions for Object.assign and similar, etc.).

I've had a section in my spec for typed rest parameters which I think covers a few cases. https://github.com/sirisian/ecmascript-types#rest-parameters Has anything changed with your view on these topics? Or examples and scenarios I should handle in the initial spec?
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Optional Static Typing (Part 3)

Michał Wadas

> Part of this has had me considering if freezing classes (and all recursively referenced types) used in the type system is viable.

function foo(bar: Array.<Set>) {
//whatever
}

[Array, Set] = [Set, Array];
foo(new Array([Set()]));

You can't freeze all builtins for obvious reasons.


You totally omitted point that your type system can't use or describe this function:


function issue(Ctor) {
   assert(Reflect.isConstructor(Ctor)); // Type system don't provide way to disguintish object with [[Construct]] and [[Call]] methods.
   assert(Foo.isPrototypeOf(Ctor)); // Type system don't provide way to ensure prototypal inheritance
   const retClass = class extends Ctor { // Type system don't provide way to describe types being returned from function
   };
   Object.assign(retClass.prototype, mixin); // Object.assign can be overridden to do anything, so actual code execution is required to prove it's valid
   return retClass;
}


TypeScript favors OOP because it supports virtually all OOP idioms, but doesn't support non-basic FPP idioms.


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Optional Static Typing (Part 3)

Brandon Andrews
>> Part of this has had me considering if freezing classes (and all recursively referenced types) used in the type system is viable.


```js
function foo(bar: Array.<Set>)
{
// whatever
}
[Array, Set] = [Set, Array];
foo(new Array([Set()]));
```

> You can't freeze all builtins for obvious reasons.


I'm out of ideas. Do you or anyone here see a way to get around such an issue?

> You totally omitted point that your type system can't use or describe this function:


```js
function issue(Ctor)
{
    assert(Reflect.isConstructor(Ctor)); // Type system don't provide way to disguintish object with [[Construct]] and [[Call]] methods.
    assert(Foo.isPrototypeOf(Ctor)); // Type system don't provide way to ensure prototypal inheritance
     
    const retClass = class extends Ctor // Type system don't provide way to describe types being returned from function
    {
    };
    Object.assign(retClass.prototype, mixin); // Object.assign can be overridden to do anything, so actual code execution is required to prove it's valid
    return retClass;
}
```

Just to be clear. Is Ctor a type? Like "class Ctor extends Foo {}" or an instance? If it's a Type it might be better handled with generics later like:

```js
function issue<Ctor extends Foo>(mixin)
{
    const retClass = class extends Ctor
    {
    };
    Object.assign(retClass.prototype, mixin);
    return retClass;
}
```

I hope I understood the requirements. Is it necessary to allow the type system to handle passing types as arguments? Do other languages allow this?

```js
assert(Reflect.isConstructor(Ctor)); // Type system don't provide way to disguintish object with [[Construct]] and [[Call]] methods.
```

So you'd expect a language feature like an interface that mandates a constructor or something more general like "this object is a class"?

```js
assert(Foo.isPrototypeOf(Ctor)); // Type system don't provide way to ensure prototypal inheritance
```

So I should explicitly state that derived classes can be passed to parameters typed with their super like most languages allow like:

```js
class A {}
class B extends A {}
function f(a:A) {}
f(new B()); // Valid
```

In your example:

```js
function issue(Ctor:Foo):Foo
{
}
class A {}
// issue(new A()); // TypeError, A must be type Foo or extended from Foo
```

Is that sufficient?

```js
const retClass = class extends Ctor // Type system don't provide way to describe types being returned from function
{
};
```

Would this be asking for interfaces and structural matching like in TypeScript? I left it out originally to simplify the proposal with the expectation it would be added in later. Do you see this more as a mandatory feature? "any" can be used in the meantime unless I'm mistaken. (I should probably add a section in the proposal covering this).
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Optional Static Typing (Part 3)

Brandon Andrews
Some follow-up as I think more about this.


> You can't freeze all builtins for obvious reasons.


I'm getting that the reason for not freezing them would be to define extensions? Could they not be defined and then frozen? I get that doesn't stop them from being dynamic still.


The ability to change the built ins like Object causes a number of issues as it makes all classes dynamic and your destructuring swap shows that well. It seems like as long as Object can be modified everything has to use run-time checking.


If Object could be made non-dynamic - froze it and made it const (or equivalent) - then one could write:


```js
const f = function(a:A)
{
        a.x = 0;
}
const A = new class
{
        x:uint8 = 5; // Object.defineProperty(A.prototype, 'x', { type: uint8, writable: true, value: 5 }); (I think, might have to think about this again, been a while).
}
f(new A()); // A is dynamic and the interpreter is forced to use a run-time check.

Object.freeze(A); // A is both const and frozen making it no longer dynamic? If the dynamicness was removed then the engine could search the code/AST and optimize f doing essentially a compile-time check at that point

f(new A()); // Compile-time verification for all instances of f where the argument is typed or the type can be inferred.
```


This usage of const works at global scope, but I feel like I'm missing something that would undermine this. Like without real namespace support this won't work well for some libraries. The syntax is also wordy and confusing. One could add const class A {} modifiers, but that's still confusing since codebases would be filled with it.


Also expecting users to freeze their classes to allow the interpreter and JIT to function sanely is asking a lot.


One problem that keeps bothering me is this delayed freezing doesn't help tooling. A class could be created, properties added in a complex operation, then the class frozen later. The tooling would be blind to all these changes.


I'm probably just barely touching the surface of issues. Anything I'm overlooking?
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Optional Static Typing (Part 3)

kai zhu
In reply to this post by Isiah Meadows-2
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 <[hidden email]> 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)

-----

Isiah Meadows
[hidden email]

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 <[hidden email]> 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 <[hidden email]> 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/ecmascript-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/ecmascript-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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Optional Static Typing (Part 3)

Pier Bover
 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 <[hidden email]> 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 <[hidden email]> 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)

-----

Isiah Meadows
[hidden email]

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 <[hidden email]> 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 <[hidden email]> 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/ecmascript-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/ecmascript-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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
12