[ng12]

> Type correctness does not guarantee program correctness.

Yeah, obviously. Think about it -- when you write the code you still think about the "types", you're just not writing them down.

Typescript's virtues are completely related to developer productivity. Documenting your code with types, better autocompletion, catching silly mistakes before needing to run it in a browser, getting new people up to speed, etc.

[brianberns]

Actually, one of the benefits of strong typing (without side effects) is that the correct implementation is sometimes the only one that compiles.

For example, if you know that a function takes a generic list and returns an integer, then the list’s length is pretty much the only non-trivial computation it can perform.

[ericelliott]

I've seen this happen for a handful of functions, but implementation correctness proofs for general applications are far beyond the expressive capabilities of TypeScript.

[z3t4]

One thing I like about JS is that you dont have to think about types. It's an old convention in JS that you should be able to pass anything in and it will figure out what to do - instead of complain. JS has always had a test driven approach - test-code-test-code so you would detect if something is off. But the strictness do of course have trade-offs, for example being fast, easy and forgiving, vs forcing the developer to think hard and give errors if it's not exactly right. For example writing flight control software where an error can mean life or death. Or writing a web game that can be patched in less then five minutes. Maintainability and refactor-ability is all about developer process, it's possible to build a buggy unmanageable mess in a strong/ strictly statistically typed language, just like it's possible to write a fail proof distributed system in plain JavaScript (it's possible but hard in any language and JS might not be the best option).

[ng12]

> One thing I like about JS is that you dont have to think about types

This is patently wrong. You _are_ thinking about types. Every object, function, variable you write has a type you store in your head. The question is about how easy it is to remember those types in 6 months, or how hard it would be for a new developer to figure them out.

> JS has always had a test driven approach

Yes, and you should keep that test-driven approach with TypeScript. I'm not sure why anyone would assert otherwise.

[z3t4]

For both good and bad it doesn't matter if you give me an apple or orange, they are about the same size so, but you might have problems giving me an banana. Example:

const len = x => x.length;