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

[hbrn]

> TypeScript is a huge productivity multiplier

See, I've heard it multiple times. And yet nobody is able to provide evidence. Surely if effects are so huge it's should be easy to prove. We're commenting on the article that says TS is 10 years old. Where is the hard evidence?

When you ask about real examples of productivity boost, TS folks shift focus to bugs (why not talk about bugs in the first place?). When you ask about critical bugs, TS folks shift focus to IDE autocompletion. When you press for evidence, goal post is constantly being moved.

Whenever you see bold claims and no evidence other than personal stories for several years, you should immediately attribute it to placebo (or other biases).

> you can fly around a large code base with ease, making changes all over

Not really, unless you're talking about bloated codebases. Huge codebases are huge due to domain complexity, you can't be making changes all over without extensive testing. What does help is having a modular codebase with good boundaries. If you already have it, TS benefits are tiny. If you don't, you're better off spending time making it modular than switching to TypeScript.

> TypeScript still a productivity boost

And yet if you talk to popular library maintainers in Python/JS community, a lot of them say that types have slowed them down. Some of them still believe it was worth it, because it helps users of those libraries. But again, see how the goalpost is being moved?

[dleslie]

The strong evidence in support of static typing for productivity and security is well known and a trivial Google search away.

[hbrn]

Which you conveniently not linking because you know it's going to be controversial at best.

Get off the high horse, static vs dynamic has been a never ending debate since the dawn of time.

Just because you side with one religion doesn't automatically make it "well known". Learn to recognize your own biases.

[dleslie]

Nah, I was on mobile and linking was cumbersome.

Here, enjoy the trivial search and read through links and their references:

https://www.google.com/search?q=Evidence+for+productivity+an...

TLDR: for productivity, there's basically no measurable impact detected in studies, positive or negative. For security and bugs, the impact is as expected: dynamic languages are as safe as strictly typed languages if they are paired with exhaustive test suites which enforce type safety. You can either write the type information alongside the application code, or write the test suite to enforce it.

Folks who think Dynamic Typing frees them of having to consider types are just fooling themselves; in this thread, even, the argument is that because they know what the types are then stating them is just unnecessary "noise". Which is all well and good, in the here and now, but provides no value when the code is foreign or forgotten; and with just a little additional syntax both the information is available to the programmer and the compiler can perform performance and security analysis with greater ease.

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