In terms of layering a static type system on top of JavaScript, how does this interact with Coffeescript and other languages that compile to JavaScript?
Facebook Launches Flow, Static Type Checker for JavaScript
91–100 of 282 posts
Re: Facebook Launches Flow, Static Type Checker for JavaScript
#92Static analysis is definitely preferable to cross-compilation and this looks like a great tool. That said, the idea that static type checking makes developers more productive and prevents tons of errors is overstated imho. Type inference is supposed to make coding simpler and more productive (particularly in functional languages) - even C++11 has added it. I'm sure static type checking can benefit some organizations,…
I just ran flow on our js constraint solver and it caught a bug. The dirty checker used && instead of & to check the dirty variables bitflag against the interested propagators bitflag so it was silently doing more work than it had to. I wouldn't even have noticed that there was a problem.
We've had plenty of other bugs in the past months that tooks hours to track down but would have been caught in seconds in a sensible language. A lot of them won't be caught by flow either, unfortunately. What I really want is for operations like key lookup to fail instead of just returning me gibberish.
Typecasting is at least explicit. In js every single operation is a timebomb.
Re: Facebook Launches Flow, Static Type Checker for JavaScript
#93Earlier quoted context omitted.
JavaScript is a bit special in this respect, I think. Because of the weird type coercion rules, and how it treats null, undefined and because of the presence of NaN many common coding mistakes end up producing mysterious errors pointing somewhere far away from the place in the code that actually produced the problem in the first place. Basically JavaScript continues propagating null/undefined/NaN in many situations w…
I just use asserts for this. If code is sensitive to a type I assert it as the top of the function. No analysis needed.
But in a rare code path, that may not to be triggered. And if you write a unit test solely to catch the fact that the type is necessary, then obviously using a static type would be better because you get the benefit without the extra code for the test.
Having optional typing does save you the trouble of overly complicated types for things where you aren't particularly concerned.
Re: Facebook Launches Flow, Static Type Checker for JavaScript
#94Does someone know how these types of projects come to fruition in a big company like Facebook? Are people working on them full time (with no other workload)? Do engineers build them on the weekend? How do they get 'funded'?
Re: Facebook Launches Flow, Static Type Checker for JavaScript
#95In terms of layering a static type system on top of JavaScript, how does this interact with Coffeescript and other languages that compile to JavaScript?
It doesn't, at least not any more than TypeScript or other compile-to-js languages interact with each other.
If CoffeeScript is to support these annotations one day - it would require the CoffeeScript compiler to support them itself in order to generate correct annotated JavaScript for Flow.
Re: Facebook Launches Flow, Static Type Checker for JavaScript
#96What a great tool. Facebook are absolutely killing with the last year or so with all of their open source contributions and releases. First HHVM, Haxl, React.js (amongst other things) and now Flow, this is fantastic. I am really liking how companies like Facebook & Google are concentrating their efforts on the web language of the future: Javascript. The support for JSX alone is a MASSIVE feature (expected given React…
[deleted]
Re: Facebook Launches Flow, Static Type Checker for JavaScript
#97Great work, no doubt.
My personal preference is to have annotations because it helps future readers and maintainers understand the code better. Instead of looking through the function to see that the variable is in-fact a number, I'd rather just read "@param x {number}". And at that point, one may as well as use closure.
Re: Facebook Launches Flow, Static Type Checker for JavaScript
#98I wonder, how does this compare to Google's Dart.js? Like Dart, it introduces a type system into JS and like Dart, it requires a compile step between Flow code and JS that will run in a browser. What does Flow do differently than Dart?
Re: Facebook Launches Flow, Static Type Checker for JavaScript
#99Static analysis is definitely preferable to cross-compilation and this looks like a great tool. That said, the idea that static type checking makes developers more productive and prevents tons of errors is overstated imho. Type inference is supposed to make coding simpler and more productive (particularly in functional languages) - even C++11 has added it. I'm sure static type checking can benefit some organizations,…
> the idea that static type checking makes developers more productive and prevents tons of errors is overstated Then perhaps you are understating the importance of software correctness. While type systems can be an almost religious topic, the benefits of type checking are real -- a whole class of bugs to disregard, less testing code, and a more maintainable codebase for other developers. Moreover, for languages with…
No, software correctness is paramount. I see your point (speaking as a c/c++ dev of realtime software)...but, software correctness is independent of static vs dynamic type checking or implicit type conversion, wouldn't you say? I see companies who feel they don't need automated testing because of TypeScript, or whatever, which concerns me a bit. A trickier problem in JS with completely compatible number types is floating point arithmetic, for example. Anyway, that's why I'm glad this tool is a static code analyzer; it can benefit both the strict typing folks as well as those who want to leverage dynamic types.
Re: Facebook Launches Flow, Static Type Checker for JavaScript
#100Earlier quoted context omitted.
I don't want to say what I'm about to say, but... I don't care about the type signature of promises. I actually don't care about the type of anything which has a complicated type; I think it's just incredibly winning that I will now be able to describe the shape of the raw data circulating in my code. I've always found really annoying, in Haskell, to see incredibly complex type idioms emerging to allow stuff that doe…
You make some good points here, I've also experienced the same with Haskell web frameworks. I think we can agree that the most important things to annotate are points of interaction. If I'm part of a 5 developer team working on a code base, or I'm using a library someone made - I want the functions I'm calling to be very explicit about what they take and return and I want the functions I provide others to be very cle…
I agree that the facilities to express function composition are woefully insufficient in nearly all languages besides ML derivatives, and that nearly all of the recent frameworks and techniques to express concurrency rely heavily on function composition.