Hacker News Reader

Comment by ep103 | Hacker News Reader

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.

View on HN

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.

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.

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.

In the large multi-contributor dynamically-typed codebases I've dealt with, type errors are very rare.

I don't think you understand what "type errors" means if you are making that assertion; or your multi-contributor codebase has such excellent test coverage that your tests are doing for you what a modern type system can do for you.

In a dynamically-typed codebase, it's near impossible to have rare type-error occurrence because you're off-loading the type system into into the programmers head (which is subject to human fallibility - even when countered with excellent unit testing!)

To be specific, I was talking only of a specific sort of errors that the JIT compiler allows e.g. applying numerical operators to strings, or combinations of string and int.

Issues with null are much more common.

In JS, I see things like methods called with incorrect number of parameters, or wrong parameter types, on a reasonably regular basis, especially when things get refactored every now and then.

I frequently see methods incorrectly overidden. For example, the ancestor method effectively has a variadic argument list, but the descendant doesn't have as sophisticated argument handling and doesn't do the appropriate superFunc.apply(this, Array.prototype.slice.call(arguments, 0)) etc.

Absolutely. I used to use hungarian notation in a static language because I was so scared of getting the wrong type. It was a huge revelation that actually this never happens.

However, whilst I never hit on basic type errors such as passing a string when I need an int - I regularly come across object type errors. I'll pass an object with a project_id property to a method that actually expects an id property. Not sure if flow can handle these - if it could it would be pretty amazing.

I do hobby level small js projects, I make type errors quite often, but they are easily found the moment I run the tests/the app. I would prefer to find them at compile time, but it's not a big deal.

Interstingly it's almost always the same kind of type error- accessing nested maps/arrays and forgetting to go deep enough before I call some method on the elements in that collection.

I can't remember one example of type error where I intended to call method on MyClassA and ended up trying to call it on MyClassB. But that may be the effect of my coding style (I'm not big fan of class hierarchies in js).

But JS does not have compile-time - you edit it, and you run it, no steps in between. If set up right you've got your unit tests running automatically whenever something changes.

And in a large app it is hard to know if all relevant code has ran. Finding pieces that uses the code you just changed is much easier in static languages. We might not go to a fully statically typed javascript but supporting optional typing seems like a really good idea.

Yes I know, I mostly work in java these days.

BTW it's funny how many times late binding was reinvented in j2ee ecosystem :)

All the time, in my case.

Today I got the order of parameters to a callback wrong ("error" was the last rather than the first parameter). The documentation didn't say anything about parameters, it only said that the callback would be called with a result. I had to look into the source code to discover the details. I am not sure if Flow would be able to catch this kind of bug but if so, it would certainly save me a lot of time.

I have written a couple of thousand lines in an app the last year and I have already had problems with restructuring my app. Creating new modules and moving "classes" into them or splitting classes and renaming them are very useful things and those things get easier with types. Having tests actually don't help that much with this in my opinion since I have to rewrite the tests also. Also reading old code could get easier with some type information in the code. Just my experience so far.

Misspelled variable names might not be something you'd classify as a "type error" but that can't happen with static typing. "Undefined is not a function" is in essence a type error and i really doubt you've never ever seen that.

Static typing also serve as a documentation, and enables "intellisense-coding" without having to google documentation every 2 minutes. Take this function signature from pythons standard library: subprocess.Popen(args, bufsize=-1, executable=None, stdin=None, stdout=None, stderr=None, preexec_fn=None, close_fds=True, shell=False, cwd=None, env=None, universal_newlines=False, startupinfo=None, creationflags=0, restore_signals=True, start_new_session=False, pass_fds=())

Without documentation, can you answer: what is env? what is stdin? what values are allowed in creationflags? is it obvious that startupinfo should be a STARTUPINFO object?

Compare to a C# equivalent, FileStream Open(string path, FileMode mode, FileAccess access, FileShare share). Here it is obvious that FileAccess can only have one out of 3 available options in the enum since the autocomplete will only give you those three options.

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

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.

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.

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?

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

you should check out sublime text if you haven't already. ST3 reads your js as you type it, and allows you to navigate through the code like you would through visual studio, keeping a dictionary of where the words appear and guessing what they are as. Its not as good as a static languages navigational abilities (you may have to choose between jumping to Increment the function, and Increment the variable), but its still pretty good.

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

"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/) 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).

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.

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.

How does optional typing weaken javascript?

I suppose he was talking about TypeScript and CoffeeScript.

CoffeeScript has no types. I have no clue why people keep including CoffeeScript when they talk about static type alternatives to JavaScript.

My bad

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.

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

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 : /

Try to sell him on type-inference first?

Reply on news.ycombinator.com