4 ms·

I mean you seem to discredit "incrementally adding annotations" as a feature. You're correct that anyone that would like to statically analyze a part of their

I mean you seem to discredit "incrementally adding annotations" as a feature. You're correct that anyone that would like to statically analyze a part of their code would want all of it analyzed. However, you're totally disregarding the biggest problem. Large existing code bases. I'm not sure if you've ever had to deal with a large, deployed to production code base, but it doesn't seem like you have. I can tell you there is no way to refactor all of it at once. The only realistic way forward is to refactor a single function, perhaps full file, one at a time.

antiuniverse 12y ago
Like skybrian's reply mentioned, I don't think this is actually an area where Flow is much stronger than TypeScript, if at all. AFAIK, virtually all vanilla JavaScript should also readily compile as TypeScript. In my mind the difference is that TypeScript doesn't purport to analyze the correctness of regions of code that lack type annotations. Meanwhile, Facebook claims that "Flow understands the control flow through the program."[0] That's great in theory, and maybe their control flow analysis is really quite sophisticated, but ultimately isn't this isomorphic to the halting problem? [0]: https://code.facebook.com/posts/1505962329687926/flow-a-new-static-type-checker-for-javascript/ https://code.facebook.com/posts/1505962329687926/flow-a-new-...
- xjia 12y ago
  > but ultimately isn't this isomorphic to the halting problem? Take a look at http://matt.might.net/articles/intro-static-analysis/ http://matt.might.net/articles/intro-static-analysis/
  - antiuniverse 12y ago
    Well, it's kind of uncanny how precisely that article addresses my misconceptions at the outset. Thanks for an awesome link (and the related k-CFA article at the bottom).
- jvilk 12y ago
  > ...TypeScript doesn't purport to analyze the correctness of regions of code that lack type annotations. TypeScript infers the types of local variables. For example, the following unannotated code would cause the TypeScript type checker to fail: // error TS2345: Argument of type 'number' is not assignable to parameter of type 'string'. [1, 2, 3].join(4); However, even when the TypeScript typechecker fails, TypeScript still produces JavaScript output. As a result, you can use TypeScript to incrementally type your program, and simply choose to ignore type checking errors. TypeScript only fails to produce output if there's a syntax error, or if you are using TypeScript import statements without specifying a module type.
skybrian 12y ago
Typescript does support incremental conversion, at least according to the talk I saw about it. Most JavaScript files are also valid TypeScript (they say), so starting to use the compiler for your project isn't hard. Also, external libraries can be described with .d.ts files. It didn't sound like migrating a large codebase would be that hard, assuming you have a consensus about doing it.
- spion 12y ago
  Yes, we converted about 16KLoc from JS to TS in ~1 week. The project was working the entire time during the process (the compiler both reported errors and generated JS files)

antiuniverse 12y ago

Like skybrian's reply mentioned, I don't think this is actually an area where Flow is much stronger than TypeScript, if at all. AFAIK, virtually all vanilla JavaScript should also readily compile as TypeScript. In my mind the difference is that TypeScript doesn't purport to analyze the correctness of regions of code that lack type annotations. Meanwhile, Facebook claims that "Flow understands the control flow through the program."[0] That's great in theory, and maybe their control flow analysis is really quite sophisticated, but ultimately isn't this isomorphic to the halting problem? [0]: https://code.facebook.com/posts/1505962329687926/flow-a-new-static-type-checker-for-javascript/ https://code.facebook.com/posts/1505962329687926/flow-a-new-...

xjia 12y ago
> but ultimately isn't this isomorphic to the halting problem? Take a look at http://matt.might.net/articles/intro-static-analysis/ http://matt.might.net/articles/intro-static-analysis/
- antiuniverse 12y ago
  Well, it's kind of uncanny how precisely that article addresses my misconceptions at the outset. Thanks for an awesome link (and the related k-CFA article at the bottom).
jvilk 12y ago
> ...TypeScript doesn't purport to analyze the correctness of regions of code that lack type annotations. TypeScript infers the types of local variables. For example, the following unannotated code would cause the TypeScript type checker to fail: // error TS2345: Argument of type 'number' is not assignable to parameter of type 'string'. [1, 2, 3].join(4); However, even when the TypeScript typechecker fails, TypeScript still produces JavaScript output. As a result, you can use TypeScript to incrementally type your program, and simply choose to ignore type checking errors. TypeScript only fails to produce output if there's a syntax error, or if you are using TypeScript import statements without specifying a module type.

skybrian 12y ago

Typescript does support incremental conversion, at least according to the talk I saw about it. Most JavaScript files are also valid TypeScript (they say), so starting to use the compiler for your project isn't hard. Also, external libraries can be described with .d.ts files. It didn't sound like migrating a large codebase would be that hard, assuming you have a consensus about doing it.

spion 12y ago
Yes, we converted about 16KLoc from JS to TS in ~1 week. The project was working the entire time during the process (the compiler both reported errors and generated JS files)