6 ms·

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 underlyi

by ep103 12y ago

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 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.

slashnull 12y ago
So what's wrong with having a tool to automate those practices ; )
- ep103 12y ago
  This is a bit off topic, but I digress.... I specifically didn't send this tool to the team I work on, because my team lead is a sql / java / c# guy who loves static languages, and only touches the front end with a stick if he has to, and then only some basic jQuery or angular. I've sold him on jasmine and requiring front end test coverage, recently. But right before I hit the send button I realized that if I sent him this tool, I'd never be allowed to use dynamic typing or non annotated functions/arguments in js ever again. Hence my question : /
  - a-saleh 12y ago
    Try to sell him on type-inference first?
dested 12y ago
How does optional typing weaken javascript?
- slashnull 12y ago
  I suppose he was talking about TypeScript and CoffeeScript.
  - hmbg 12y ago
    CoffeeScript has no types. I have no clue why people keep including CoffeeScript when they talk about static type alternatives to JavaScript.
    - slashnull 12y ago
      My bad
inglor 12y ago
Well, here are some things that it does that other tools don't: - It type checks JSX - It supports some ES6 features others don't (like destructuring) as the build step - It has union types (TS will get those soon, already in master) - It does a lot more inference and a lot more assumptions. It assumes you won't multiply a string by a number for example (although technically '10' * 5 is legal in JS). So it's opinionated in that it enforces checks that rule out code that is legal but not likely intended in JS (an opinin I agree with). Yes - it is possible to write tests and get good coverage and not use those tools - however static analysis can be very valuable in finding errors early. While I'm not sure I'd bother with explicit typing in this in smaller projects from the examples and unit tests it looks like it could find errors people would not easily notice otherwise. (Think JSHint, on steroids). That said, only time will tell how good the implementation will really get in understanding your code.
- ep103 12y ago
  I digress but... you're not wrong, but out of curiosity, I just genuinely wonder how often modern programmers really hit type errors on smaller projects (obviously not FB size). I don't think I've ever had a type cast bug in my js code, provided we don't include accidental nulls in that statement. So in my experience, if I were ever told that I now had to always use annotations, I would feel like I was losing flexibility in the language for little gain. And I feel like the reason I never hit type issues, is because I write full test coverage, which in turn make it painfully obvious what is and is not expected in each method. For the reasons above, I love the idea of this tool dynamically checking all my code paths, and looking for things that are likely mistakes or result in null exceptions. But I'm afraid to recommend this to my boss, for fear that for now on, everything must be maximum static... everything annotated, no union types, etc. Just my 2 cents.
  - muglug 12y ago
    In the large multi-contributor dynamically-typed codebases I've dealt with, type errors are very rare.
    - 12y ago
cgag 12y ago
This feels like saying airbags and seatbelts add nothing to cars assuming good driving practices. It solves not having to write a bunch of tests that can trivially be caught by a program and never having to update or maintain those tests. It hits every code path automatically, you don't have to think of cases to try to hit edge cases.
coldtea 12y ago
>That said, I am curious what solutions this solves that isn't already solved by enforcing good code coverage. The (supposed) need to have "good code coverage" is itself a problem I'd like solved.
discreteevent 12y ago
The main benefit of types for me is not correctness but documentation and tooling. It's fine not to have types in code I write myself or with one or two others. But if I have to deal with a large codebase that I wasn't involved in writing then types make it so much quicker to understand. Just being able to quickly find all references to a type or all a method's call sites makes it possible to "reverse engineer" the design from the code. This tool claims it can do advanced inference. If it were possible to hook it up to an editor or IDE to analyse existing untyped js in this way it could be invaluable.
- avik 12y ago
  We have some basic editor support, more is coming soon. Flow exposes several commands that are useful through an editor, like type-at-pos (give it a position, it gives you back the inferred type), suggest (give it a file, it dumps out an annotated file), autocomplete (gives you suggestions at a given position), etc. Also, we require annotations at module boundaries, so you're modules are going to have well-typed interfaces that serve well for both documentation and stability.
  - hyp0 12y ago
    I strongly agree with module typing (and being more relaxed within). Because of caller dependence on modules, the difficulty of changing static types becomes a benefit. Plus, they need to be documented anyway; and tooling support helps use they as if they were primitives. As others have said, I love the approach of inference giving static type benefits, for free. If you get tooling support, at no extra work, why not adopt it? But static types can be a hard sell for JS programmers. What sort of reception has it gotten inside facebook?
    - avik 12y ago
      Still early days but the reception has been strongly positive. We may be a biased bunch but we like our code mostly statically typed with the flexibility provided by dynamically typed languages. A large part of this culture is due to the immense internal success of Hack (http://hacklang.org/ http://hacklang.org/).
deleted 12y ago
[deleted]
hyp0 12y ago
Types as documentation is often very helpful for large products, particularly in tooling. From TFA: > code intelligence, which aids code maintenance, navigation, transformation, and optimization I suspect that for facebook, this could be just as important, if not more so, than code quality benefits.
paulddraper 12y ago
"better step in the right direction than the types of tools MS and Google have been putting out" The Google Closure Compiler (https://developers.google.com/closure/compiler/ https://developers.google.com/closure/compiler/) has been around for years and years. It does everything you mentioned (100% optional type annotations, type inference), plus more (dead code removal, inlining, compiler-time constants).
- xixixao 12y ago
  Google Closure: function hello(a){alert("Hello, "+a)}hello(3); Compilation was a success! No warnings No errors + it's not incremental hence unusably slow, requires Java. No, Closure is not the same as Flow even from a brief look at both.
  - Cthulhu_ 12y ago
    That's because it's all valid Javascript - concatenating a string with a number is normal practice even in strongly typed languages (implicit type conversion). So, I don't see your point. If the argument 'a' had an annotation saying it should be a string, then I could understand an error from some checker tool, but then it wouldn't be vanilla JS anymore.
lmm 12y ago
> 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. Typescript (from MS) sounds a lot like what you describe - it doesn't change Javascript, it just adds types to it (and makes some ES6 features available), and it puts a lot of work into playing nice with the wider JS ecosystem (e.g. via the definitelytyped project, which integrates type definitions for most popular "third-party" javascript libraries). > 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. Perfect testing can do everything a type system can. But a type system can do it with less programmer effort, much lower maintenance overhead, and in a standard form that makes it easier to maintain. So you can do the same thing but cheaper - or, more realistically for how software is developed in most companies, you can get better reliability for the same engineering budget.

by ep103 12y ago

slashnull 12y ago

So what's wrong with having a tool to automate those practices ; )

ep103 12y ago
This is a bit off topic, but I digress.... I specifically didn't send this tool to the team I work on, because my team lead is a sql / java / c# guy who loves static languages, and only touches the front end with a stick if he has to, and then only some basic jQuery or angular. I've sold him on jasmine and requiring front end test coverage, recently. But right before I hit the send button I realized that if I sent him this tool, I'd never be allowed to use dynamic typing or non annotated functions/arguments in js ever again. Hence my question : /
- a-saleh 12y ago
  Try to sell him on type-inference first?

dested 12y ago

How does optional typing weaken javascript?

slashnull 12y ago
I suppose he was talking about TypeScript and CoffeeScript.
- hmbg 12y ago
  CoffeeScript has no types. I have no clue why people keep including CoffeeScript when they talk about static type alternatives to JavaScript.
  - slashnull 12y ago
    My bad

inglor 12y ago

Well, here are some things that it does that other tools don't: - It type checks JSX - It supports some ES6 features others don't (like destructuring) as the build step - It has union types (TS will get those soon, already in master) - It does a lot more inference and a lot more assumptions. It assumes you won't multiply a string by a number for example (although technically '10' * 5 is legal in JS). So it's opinionated in that it enforces checks that rule out code that is legal but not likely intended in JS (an opinin I agree with). Yes - it is possible to write tests and get good coverage and not use those tools - however static analysis can be very valuable in finding errors early. While I'm not sure I'd bother with explicit typing in this in smaller projects from the examples and unit tests it looks like it could find errors people would not easily notice otherwise. (Think JSHint, on steroids). That said, only time will tell how good the implementation will really get in understanding your code.

ep103 12y ago
I digress but... you're not wrong, but out of curiosity, I just genuinely wonder how often modern programmers really hit type errors on smaller projects (obviously not FB size). I don't think I've ever had a type cast bug in my js code, provided we don't include accidental nulls in that statement. So in my experience, if I were ever told that I now had to always use annotations, I would feel like I was losing flexibility in the language for little gain. And I feel like the reason I never hit type issues, is because I write full test coverage, which in turn make it painfully obvious what is and is not expected in each method. For the reasons above, I love the idea of this tool dynamically checking all my code paths, and looking for things that are likely mistakes or result in null exceptions. But I'm afraid to recommend this to my boss, for fear that for now on, everything must be maximum static... everything annotated, no union types, etc. Just my 2 cents.
- muglug 12y ago
  In the large multi-contributor dynamically-typed codebases I've dealt with, type errors are very rare.
  - 12y ago

cgag 12y ago

This feels like saying airbags and seatbelts add nothing to cars assuming good driving practices. It solves not having to write a bunch of tests that can trivially be caught by a program and never having to update or maintain those tests. It hits every code path automatically, you don't have to think of cases to try to hit edge cases.

coldtea 12y ago

>That said, I am curious what solutions this solves that isn't already solved by enforcing good code coverage. The (supposed) need to have "good code coverage" is itself a problem I'd like solved.

discreteevent 12y ago

The main benefit of types for me is not correctness but documentation and tooling. It's fine not to have types in code I write myself or with one or two others. But if I have to deal with a large codebase that I wasn't involved in writing then types make it so much quicker to understand. Just being able to quickly find all references to a type or all a method's call sites makes it possible to "reverse engineer" the design from the code. This tool claims it can do advanced inference. If it were possible to hook it up to an editor or IDE to analyse existing untyped js in this way it could be invaluable.

avik 12y ago
We have some basic editor support, more is coming soon. Flow exposes several commands that are useful through an editor, like type-at-pos (give it a position, it gives you back the inferred type), suggest (give it a file, it dumps out an annotated file), autocomplete (gives you suggestions at a given position), etc. Also, we require annotations at module boundaries, so you're modules are going to have well-typed interfaces that serve well for both documentation and stability.
- hyp0 12y ago
  I strongly agree with module typing (and being more relaxed within). Because of caller dependence on modules, the difficulty of changing static types becomes a benefit. Plus, they need to be documented anyway; and tooling support helps use they as if they were primitives. As others have said, I love the approach of inference giving static type benefits, for free. If you get tooling support, at no extra work, why not adopt it? But static types can be a hard sell for JS programmers. What sort of reception has it gotten inside facebook?
  - avik 12y ago
    Still early days but the reception has been strongly positive. We may be a biased bunch but we like our code mostly statically typed with the flexibility provided by dynamically typed languages. A large part of this culture is due to the immense internal success of Hack (http://hacklang.org/ http://hacklang.org/).

deleted 12y ago

[deleted]

hyp0 12y ago

Types as documentation is often very helpful for large products, particularly in tooling. From TFA: > code intelligence, which aids code maintenance, navigation, transformation, and optimization I suspect that for facebook, this could be just as important, if not more so, than code quality benefits.

paulddraper 12y ago

"better step in the right direction than the types of tools MS and Google have been putting out" The Google Closure Compiler (https://developers.google.com/closure/compiler/ https://developers.google.com/closure/compiler/) has been around for years and years. It does everything you mentioned (100% optional type annotations, type inference), plus more (dead code removal, inlining, compiler-time constants).

xixixao 12y ago
Google Closure: function hello(a){alert("Hello, "+a)}hello(3); Compilation was a success! No warnings No errors + it's not incremental hence unusably slow, requires Java. No, Closure is not the same as Flow even from a brief look at both.
- Cthulhu_ 12y ago
  That's because it's all valid Javascript - concatenating a string with a number is normal practice even in strongly typed languages (implicit type conversion). So, I don't see your point. If the argument 'a' had an annotation saying it should be a string, then I could understand an error from some checker tool, but then it wouldn't be vanilla JS anymore.

lmm 12y ago

> 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. Typescript (from MS) sounds a lot like what you describe - it doesn't change Javascript, it just adds types to it (and makes some ES6 features available), and it puts a lot of work into playing nice with the wider JS ecosystem (e.g. via the definitelytyped project, which integrates type definitions for most popular "third-party" javascript libraries). > 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. Perfect testing can do everything a type system can. But a type system can do it with less programmer effort, much lower maintenance overhead, and in a standard form that makes it easier to maintain. So you can do the same thing but cheaper - or, more realistically for how software is developed in most companies, you can get better reliability for the same engineering budget.