61–70 of 282 posts
Very nice. I wonder how hard this would be to throw into Jasmine/QUnit type scenarios.
What 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…
It's hard for me to give appreciation but while Google have traditionally been tech leaders in web technologies: Facebook are doing really awesome stuff lately. It's not just React and this - it's also FLUX, HHVM, Hack, Haxl (Their Haskell libraries), contributing to writing a spec for PHP and other ventures. I'm interested in who is the driving force behind this open source change in Facebook, I don't recall faceboo…
Static 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,…
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…
At last! This all seem extremely cool. I went straight from hacking Scala and Haskell as a hobbyist to doing (mostly) front-end JS job, and I've always found that my code, and a lot of good libraries I read, naturally emulate something close to Hindley-Milner typing, by using objects as tuples/records and arrays as (hopefully well-typed) lists, as well as the natural flexibility of objects as a poor substitute for Ei…
Haskell-style sum types are a generic type with multiple values describing the alternatives.
Since the goal of Flow is to typecheck existing JS semantics, the addition of wrapper types and objects to support such sum types makes very little sense while the addition of "anonymous" union types makes a lot of sense. Dialyzer took the exact same path (except even more so as its type unions can contain values) as it tried to encode Erlang's existing semantics.
Earlier quoted context omitted.
Strongly typed JS is actually pretty hard - probably not by Haskell and Scala standards - but if you take promises for example the signature of `then` is: Promise -> ((A -> (Promise | B)),(E -> (Promise | C))) -> Promise That is - a promise's then - takes the promise (as this) and executes either a `.then` fulfillment handler or a catch handler. If the `fulfill` handler executes the value is unwrapped and either a ne…
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…
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 clear on what they take and return.
The problem is that even something people use every day like a Promise or an event handler creates very complex types (like the example above). I think any viable solution that expects to be type safe needs to be able to express that.
If your code does not expose any callbacks, or anything async I'd say it's simply not very typical JS code.
The alternative of course is to be _less_ safe about our type. We could say that we treat a promise as:
Promise -> A -> Promise -> Promise
(just a `bind` from Haskell) - this would let us maintain _some_ type safety which is better than nothing.
Earlier quoted context omitted.
EDIT: looks like it supports type annotations similar to closure compiler's (in docs) https://github.com/facebook/flow/blob/master/tests/docblock/... Try running an annotated file in the browser - it's simply not valid ECMAScript syntax and no JavaScript runtime will run it 'as is'. If the code requires transformation by a compiler aware of the language semantics and syntax - it's transpiling in my book. Just like Ty…
> Try running an annotated file in the browser - it's simply not valid ECMAScript syntax and no JavaScript runtime will run it 'as is'. Of course not, but the point was that it's not a different language, it simply adds type annotations. If you strip out the type annotations, it should be a valid JS file.
That is quite impressive. No type annotations needed, and control flow is taken intro consideration (hence the name I guess). If I am not mistaken, this tech could be used to build IDEs roughly similar to whats available for Java, couldn't it?
It looks like it's designed for the IDE use case - on cursory inspection of the code, it contains an autocomplete database and a client-server architecture designed for editor plugins (with useful interfaces like "type at character index"). I'm surprised that they don't seem to have launched with a public editor plugin and that the documentation doesn't seem to mention it.
That said, I am curious what solutions this solves that isn't already solved by enforcing good code coverage. Full disclaimer, the largest js projects I've worked on were in the tens of thousands of lines, not hundreds of thousands, but type checking just seemed completely unnecessary provided a good coding guide and test coverage were maintained and enforced.
This is really cool. Does anyone have pointers to relevant papers that inspired/influenced their type system?
This looks like such a better step in the right direction than than the types of tools MS and Google have been putting out. Dynamically discerning the underlying code, and allowing optional type annotation works _with_ javascript, as opposed to attempting to turn js into a completely different (and weakened) language. That said, I am curious what solutions this solves that isn't already solved by enforcing good code…