here seems to be little or no impact on productivity
initial effort to introduce a checker is low, though (especially true for flow)
but: a type system is a complex thing
My recommendation
* if your project does not live for long: no
* if your project is really simple: no
* if there is a chance you will need to refactor the thing: yes
* if your system is very important or even crucial for the success of your company: yes
* if people enter or leave your team frequently: yes
I don’t agree with the refactoring part as a benefit of typed languages and this is something I’m reading a lot lately. I don’t see much relationship between typed languages and refactoring, after all Smalltalk invented refactoring and it is a non-typed language. (ok, having a well defined type system in the language is helpful for verifying the refactoring output is correct, but not a defining factor).
Anyway, I agree with @DJCordhose that both tools are useful to have in the toolset.
Is also nice to see the tool has been developed in OCaml.
I’ve been working with flowtype for the last year.
In the past 6 months the featureset has reached the point where I can really rely on it for tracking down issues.
For instance, I discovered a JSON endpoint was returning an unexpected format sometimes; I refined the type and automatically found the ~20-30 places which were affected.
I don’t agree with the refactoring part as a benefit of typed languages and this is something I’m reading a lot lately.
I’m not sure what the author meant, but when I talk about this benefit, I mean being able to reliably do “automatic” refactorings. For example, being able to change Person’s name property to fullName without accidentally affecting Company’s name property. In WebStorm with TypeScript, for example, that would take about 2 seconds, and if you have a well-typed codebase, you can be very confident that nothing’s broken.
Really good intro to Flow and how it compares with Typescript. It is refreshing to see how complementary, and non competing both tools are.
Some points, like nullable types will be improved in Typescript, but I really like this slide: Should I use a type checker?:
I don’t agree with the refactoring part as a benefit of typed languages and this is something I’m reading a lot lately. I don’t see much relationship between typed languages and refactoring, after all Smalltalk invented refactoring and it is a non-typed language. (ok, having a well defined type system in the language is helpful for verifying the refactoring output is correct, but not a defining factor).
Anyway, I agree with @DJCordhose that both tools are useful to have in the toolset.
Is also nice to see the tool has been developed in OCaml.
I’ve been working with flowtype for the last year.
In the past 6 months the featureset has reached the point where I can really rely on it for tracking down issues.
For instance, I discovered a JSON endpoint was returning an unexpected format sometimes; I refined the type and automatically found the ~20-30 places which were affected.
I’m not sure what the author meant, but when I talk about this benefit, I mean being able to reliably do “automatic” refactorings. For example, being able to change
Person’snameproperty tofullNamewithout accidentally affectingCompany’snameproperty. In WebStorm with TypeScript, for example, that would take about 2 seconds, and if you have a well-typed codebase, you can be very confident that nothing’s broken.