[DogLover_]

I have to disagree. Adding the types will increase the number of the characters/lines of code which with a 80-char formatter limit can make functions look almost gibberish at a glance. Do that on a whole codebase and it becomes a mess to look at.

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

[atom_arranger]

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

[eyelidlessness]

And I have to disagree in turn. Those additional characters and lines of code are documentation, and turn gibberish into not only human-readable clarity about the code you’re reading, but a machine-traversable dependency graph as well.

[hbrn]

The problem is that they are forced documentation. You can't choose to skip it after you became familiar with it.

[eyelidlessness]

That sounds like a VSCode extension I could write on a Saturday morning but whatever.

[dleslie]

Character input time is a vanishingly small concern for overall productivity. If it's a concern then you'll probably catch more bugs by slowing down to think.

[DogLover_]

Typing it is not the problem. It is reading at a glance that becomes much harder since lines oftentimes get split into multilines. I get less of an overview.

[dleslie]

It's all still there, except with even more helpful information.

If there are so many parameters that it falls out of mental context then there's too many parameters.