[_0w8t]

The verbosity of TypeScript types can be attributed to poor choice of syntax and names that became obvious retrospectively.

Still even with TypeScript if types makes your functions ugly, then it shows the complexity of the code. Often it also suggests sensible refactoring that without types would not be apparent.

[DogLover_]

Typscript: "function area(left: number, top: number, right: number, bottom: number): number {"

Javascript: "function area(left, top, right, bottom)"

In an editor the typescript function would likely be split into five separate lines.

"function area(

left: number,

top: number,

right: number,

bottom: number)

: number {"

None of the functions are complex but the the typescript function with the formatter creates a lot of noise.

[dleslie]

It's not noise, it's informative content.

It also means it's not going to explode when fed the wrong types, because that's not possible.

[BigJono]

The only way it can not be noise is if you have no idea what your types are. That's a terrible way to code.

If I'm working on a function foo(bar, baz), I know exactly what bar and baz are before looking at a single line of it, I've been tracing the code through to that function, how could I not know what the data types are at that point?

[dleslie]

It's normal not to be aware of the types when encountering code for the first time, or after a long absence.

Your described experience is the rare exception when working with third party vendors, on long lived projects, or with teams that are not trivially small.

[hbrn]

So the benefits are only available once or twice, but the code is going to be verbose forever.

If I were to come up with environment where it is guaranteed to be a net positive it would be a company with lack of boundaries between teams and a lot of churn.

Essentially TS averages out engineers in your team. You're going to be slower, but more predictable. Your 10x engineers will become 5x, but 1x will become 2x.

[zarzavat]

> Essentially TS averages out engineers in your team. You're going to be slower, but more predictable. Your 10x engineers will become 5x, but 1x will become 2x.

It’s the other way around. For more experienced engineers TypeScript is a huge productivity multiplier: you can fly around a large code base with ease, making changes all over.

More experienced engineers also probably have some history with other statically types languages (perhaps Java, Swift or C++) so the concept of static typing is likely to be familiar to them.

For less experienced engineers, there are more drawbacks such as 1) additional language complexity and 2) possible unfamiliarity with static typing. Although TypeScript still a productivity boost because they are likely to have a higher error rate.

[dleslie]

The verbosity is not a meaningful performance impediment. It takes a trivial amount of time to write, and a trivial amount of time to read.

If the a team can distinguish between an average and excellent programmer's performance by the time it takes to read or write type information then I expect the skill and experience breadth within the team was already narrow.

[atom_arranger]

The other people on/joining your team probably don’t know.