31–40 of 41 posts
This would be best case scenario so we could get rid of the tedious work that one has to put in to make an older library have type checking.
I'd be much more enthusiastic about using a type system if it was a part of an official ES-next spec. Right now community efforts around static typing are divided between two very similar, but incompatible type systems, similar to the situation we had a few years ago with CommonJS and AMD modules (though the two module systems are much more dissimmilar than Flow and TypeScript). The module debate has been been mostly…
Interestingly, a type system was proposed for JavaScript around 2007 as part of ES4, which was later abandoned [1]. The proposed details in [2] are strikingly similar to what we've ended up with in Flow and TypeScript. [1] https://en.wikipedia.org/wiki/ECMAScript#4th_Edition_.28aban... [2] https://www.ecma-international.org/activities/Languages/Lang...
I'd be much more enthusiastic about using a type system if it was a part of an official ES-next spec. Right now community efforts around static typing are divided between two very similar, but incompatible type systems, similar to the situation we had a few years ago with CommonJS and AMD modules (though the two module systems are much more dissimmilar than Flow and TypeScript). The module debate has been been mostly…
It feels a little bit like if you'd want a linter to be part of an ES spec. As in: I appreciate TypeScript for the compile-time guarantees it gives me.
The immediate benefit to adding Typescript/Flow-like annotations to the ES spec would be that you could run Typescript files unchanged (without transpilation) in the browser, even if the Browser didn't do any type checks for you. You could still use TS or Flow to do the type checks in a separate process, but you could potentially drop the type-stripping steps in TS or Babel. The possibility exists that eventually the browser could also start to enforce basic type checks, but the immediate benefit of slightly faster build processes with no type-stripping step shouldn't be overlooked.
I've always wondered if you could let the engine do the type checking or create type definition files for you, maybe an optional v8 flag? This would be best case scenario so we could get rid of the tedious work that one has to put in to make an older library have type checking.
That inference is also made available more directly in dts-gen [1], which is a tool built around Typescript inferencing that produces decent first pass type definition files for a library.
dts-gen may be something to try the next time you need a definition file. (Personally, I still prefer to start a new definition file by hand, but it's good to have an automated option, even if only to double-check your work.)
Earlier quoted context omitted.
Soundness means that if the type system says that a variable has a particular type, then it definitely has that type at runtime. A sound type system is always correct, and an unsound type system might be incorrect in some cases. Here's an example of unsoundness in TypeScript: https://www.typescriptlang.org/play/index.html#src=function%... TypeScript incorrectly (but conveniently) says that Array can be assigned to Ar…
So Flow seem to be complaining that number and string are incompatible types for the array elements. I attempted to change your arr.push(3) statement to one that is appending a string, and it gave the same error even though it should not have given an error in that case. Neither Flow nor TypeScript are correct in this instance. Neither keep track of the actual array element's value, just the general type of the array…
https://flow.org/try/#0GYVwdgxgLglg9mABAWwKYGd0FUAOAVAC1QEEA...
Both Flow and TypeScript have good type inference (with Flow's generally being better, I think) and do pretty well with all type annotations removed, but that wasn't shown in my example because I explicitly annotated all types.
Note that if you do want/need to give an explicit type annotation for this sort of thing, Flow provides `$ReadOnlyArray`, where `Array` is assignable to `$ReadOnlyArray`:
https://flow.org/try/#0GYVwdgxgLglg9mABAWwKYGd0FUAOAVAC1QEEA...
It sounds like you're arguing that TypeScript is wrong because it's overly-permissive, and Flow is wrong because it's overly-strict, which makes sense. That's probably why people prefer to use the word "sound" to describe Flow rather than "correct". Every sound type system has cases where you can write perfectly correct code that would be rejected by the type system (which is provable because of the halting problem). Opting into a type system always means that you limit the type of code you can write in exchange for better automatic verification.
Earlier quoted context omitted.
Soundness means that if the type system says that a variable has a particular type, then it definitely has that type at runtime. A sound type system is always correct, and an unsound type system might be incorrect in some cases. Here's an example of unsoundness in TypeScript: https://www.typescriptlang.org/play/index.html#src=function%... TypeScript incorrectly (but conveniently) says that Array can be assigned to Ar…
So Flow seem to be complaining that number and string are incompatible types for the array elements. I attempted to change your arr.push(3) statement to one that is appending a string, and it gave the same error even though it should not have given an error in that case. Neither Flow nor TypeScript are correct in this instance. Neither keep track of the actual array element's value, just the general type of the array…
This example is quite interesting because javascript itself does not provide a way to check the type of an array, unlike a primitive. This is likely due to the fact that an empty array doesn't really have a type for it's items yet.
Here is an example where typescript can infer the type using the `typeof` runtime check but provide compile time checking.
https://www.typescriptlang.org/play/index.html#src=function%...
Earlier quoted context omitted.
So Flow seem to be complaining that number and string are incompatible types for the array elements. I attempted to change your arr.push(3) statement to one that is appending a string, and it gave the same error even though it should not have given an error in that case. Neither Flow nor TypeScript are correct in this instance. Neither keep track of the actual array element's value, just the general type of the array…
The issue with changing `arr.push(3)` to `arr.push('baz')` is that there's still a type annotation on the function saying `Array `. If you get rid of the type annotation or change it to `Array `, flow is ok with it: https://flow.org/try/#0GYVwdgxgLglg9mABAWwKYGd0FUAOAVAC1QEEA... Both Flow and TypeScript have good type inference (with Flow's generally being better, I think) and do pretty well with all type annotations…
Earlier quoted context omitted.
Soundness means that if the type system says that a variable has a particular type, then it definitely has that type at runtime. A sound type system is always correct, and an unsound type system might be incorrect in some cases. Here's an example of unsoundness in TypeScript: https://www.typescriptlang.org/play/index.html#src=function%... TypeScript incorrectly (but conveniently) says that Array can be assigned to Ar…
So Flow seem to be complaining that number and string are incompatible types for the array elements. I attempted to change your arr.push(3) statement to one that is appending a string, and it gave the same error even though it should not have given an error in that case. Neither Flow nor TypeScript are correct in this instance. Neither keep track of the actual array element's value, just the general type of the array…
That's because the author told Flow explicitly to expect an array of strings and numbers.
Earlier quoted context omitted.
So Flow seem to be complaining that number and string are incompatible types for the array elements. I attempted to change your arr.push(3) statement to one that is appending a string, and it gave the same error even though it should not have given an error in that case. Neither Flow nor TypeScript are correct in this instance. Neither keep track of the actual array element's value, just the general type of the array…
> Flow doesn't infer That's because the author told Flow explicitly to expect an array of strings and numbers.
Earlier quoted context omitted.
Flow/Typescript both of great but writing from start from scratch both flow and typescript slow me down with all the hassle of needing to define the types of parameters and data structures. Typescript being a bit verbose at time too. When working with another person API then typescript does become a godsend in helping understand what the bloody hell does this callback parameter are required.
>When working with another person API then typescript does become a godsend in helping understand what the bloody hell does this callback parameter are required. Plot twist: While you are cursing at the person who wrote that API, you slowly realize that it was you all along.