Re: es-discuss Digest, Vol 131, Issue 16

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

Re: es-discuss Digest, Vol 131, Issue 16

Ranando King
Just throwing in my 2 cents.

I would argue that this represents such a fundamental change to how the language works, that it would actually represent a new language, even though they're optional. One problem is in how this would be implemented. Making types optional introduces a lot of overhead in type checking. Such checks would have to occur at runtime since ES is a language capable of self-modification. What's more is that the weight of all these checks happening at runtime would cause a serious performance penalty to run speed.

On the flip side, ```class``` already provides some of what you want to do. The proposal for private fields brings class even closer. If decorators are allowed to be applied to both non-objects and function parameters, then decorators could be used to close the gap. All that would be needed is to define a decorator for each desired type. The decorators would take care of the type checks while performing the documentation purposes you're saying would be one of the biggest features.

Having used many typed languages before, I cannot deny the usefulness of types. However, where Javascript is concerned, mixing typed and untyped variables leads to complexities that could be flatly impossible to optimize. Have you considered what would happen if someone does something like this:

```javascript
function doSomething(param: int32) {
   //Do something here
}

var a = 32;
doSomething(a);
a = "foo";
doSomething(a);
```
The engine would not be able to optimize this... ever. Every call would involve a type check before the call is made since the type of the parameter cannot be guaranteed to be converted to an int32. The engine would either need to disallow such a call from an untyped value, or type check every time.

If you can imagine implementing types as syntactic sugar over what can already be done in ES6 (maybe with the inclusion of ES7 or proposed features) you might find a bit less push-back.


On Sat, Jan 13, 2018 at 3:43 PM, <[hidden email]> wrote:
Send es-discuss mailing list submissions to
        [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
        https://mail.mozilla.org/listinfo/es-discuss
or, via email, send a message with subject or body 'help' to
        [hidden email]

You can reach the person managing the list at
        [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of es-discuss digest..."

Today's Topics:

   1. Re: Proposal: Optional Static Typing (Part 3) (Mark Volkmann)


---------- Forwarded message ----------
From: Mark Volkmann <[hidden email]>
To: kai zhu <[hidden email]>
Cc: Brandon Andrews <[hidden email]>, es-discuss <[hidden email]>
Bcc: 
Date: Sat, 13 Jan 2018 15:43:52 -0600
Subject: Re: Proposal: Optional Static Typing (Part 3)
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



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

Re: es-discuss Digest, Vol 131, Issue 16

Mark Volkmann
If optional types in JS were implemented like they are in Flow, the types would be stripped before runtime. There are only there for pre-runtime type checking. So nothing related to optimization would change and there would be no runtime type checking.

---
R. Mark Volkmann
Object Computing, Inc.

On Jan 13, 2018, at 5:27 PM, Ranando King <[hidden email]> wrote:

Just throwing in my 2 cents.

I would argue that this represents such a fundamental change to how the language works, that it would actually represent a new language, even though they're optional. One problem is in how this would be implemented. Making types optional introduces a lot of overhead in type checking. Such checks would have to occur at runtime since ES is a language capable of self-modification. What's more is that the weight of all these checks happening at runtime would cause a serious performance penalty to run speed.

On the flip side, ```class``` already provides some of what you want to do. The proposal for private fields brings class even closer. If decorators are allowed to be applied to both non-objects and function parameters, then decorators could be used to close the gap. All that would be needed is to define a decorator for each desired type. The decorators would take care of the type checks while performing the documentation purposes you're saying would be one of the biggest features.

Having used many typed languages before, I cannot deny the usefulness of types. However, where Javascript is concerned, mixing typed and untyped variables leads to complexities that could be flatly impossible to optimize. Have you considered what would happen if someone does something like this:

```javascript
function doSomething(param: int32) {
   //Do something here
}

var a = 32;
doSomething(a);
a = "foo";
doSomething(a);
```
The engine would not be able to optimize this... ever. Every call would involve a type check before the call is made since the type of the parameter cannot be guaranteed to be converted to an int32. The engine would either need to disallow such a call from an untyped value, or type check every time.

If you can imagine implementing types as syntactic sugar over what can already be done in ES6 (maybe with the inclusion of ES7 or proposed features) you might find a bit less push-back.


On Sat, Jan 13, 2018 at 3:43 PM, <[hidden email]> wrote:
Send es-discuss mailing list submissions to
        [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
        https://mail.mozilla.org/listinfo/es-discuss
or, via email, send a message with subject or body 'help' to
        [hidden email]

You can reach the person managing the list at
        [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of es-discuss digest..."

Today's Topics:

   1. Re: Proposal: Optional Static Typing (Part 3) (Mark Volkmann)


---------- Forwarded message ----------
From: Mark Volkmann <[hidden email]>
To: kai zhu <[hidden email]>
Cc: Brandon Andrews <[hidden email]>, es-discuss <[hidden email]>
Bcc: 
Date: Sat, 13 Jan 2018 15:43:52 -0600
Subject: Re: Proposal: Optional Static Typing (Part 3)
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


_______________________________________________
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: es-discuss Digest, Vol 131, Issue 16

Mark Volkmann
That is why we have the websites definitelytyped.org and https://github.com/flowtype/flow-typed. Sure they don’t have type definitions for all libraries, but more are being added all the time and developers can provide their own definitions to fill in the gaps. Being able to use types, even when some libraries do not have type definitions is still far better than not using types at all.

---
R. Mark Volkmann
Object Computing, Inc.

On Jan 13, 2018, at 9:49 PM, Ranando King <[hidden email]> wrote:

Stripping the types does solve the runtime problem, but only at the cost of creating another. Suppose a website imported a remote library with types in it. There's no way that, with the types stripped at runtime, the remote library and the local code could validate that each other were satisfying their type requirements. That is a major issue. The simple process of modularization reduces the usefulness of types that are stripped at runtime to only validating the self-consistency of each individual module. Good unit testing can already do that.

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

Re: es-discuss Digest, Vol 131, Issue 16

Isiah Meadows-2
And to add to that, TypeScript also supports in-package type
definitions, too. (Quite a few libraries elect to do this instead.)
-----

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 Sun, Jan 14, 2018 at 5:16 AM, Mark Volkmann
<[hidden email]> wrote:

> That is why we have the websites definitelytyped.org and
> https://github.com/flowtype/flow-typed. Sure they don’t have type
> definitions for all libraries, but more are being added all the time and
> developers can provide their own definitions to fill in the gaps. Being able
> to use types, even when some libraries do not have type definitions is still
> far better than not using types at all.
>
> ---
> R. Mark Volkmann
> Object Computing, Inc.
>
> On Jan 13, 2018, at 9:49 PM, Ranando King <[hidden email]> wrote:
>
> Stripping the types does solve the runtime problem, but only at the cost of
> creating another. Suppose a website imported a remote library with types in
> it. There's no way that, with the types stripped at runtime, the remote
> library and the local code could validate that each other were satisfying
> their type requirements. That is a major issue. The simple process of
> modularization reduces the usefulness of types that are stripped at runtime
> to only validating the self-consistency of each individual module. Good unit
> testing can already do that.
>
>
> _______________________________________________
> 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