The trade-off is obvious: you gain confidence about your program but you need to Learn More Stuff. Nobody's talking about the downsides of type systems except to the extent that they're worth talking about: see the comments here every time someone compares the type systems of Python and Rust.
This is why engineering/software articles in general (this one included) needs to bring up tradeoffs more often. No, "learning more stuff" is not a downside or a tradeoff, it's just a fact of learning anything.
That you introduce more coupling is a tradeoff. That the program (sometimes) gets harder to change is a tradeoff. That is becomes easier to write large, messy programs because programmers feel more safe in the future to refactor, is a tradeoff. Trying to fix each one of those tradeoffs also come with their own tradeoffs, and so on.
These are "apparent" for me, when talking about languages using static types vs dynamic languages, but it is not apparent for everyone. So when bringing up these "obvious" upsides, also bring up the "obvious" downsides, as it seems quite a lot of people don't see it as "obvious" as we do.
That’s not inherent in static types.
You don't introduce more coupling, you document the coupling that already exists. If your program is hard to change with types, it would be hard to change without types - but easier to change incorrectly.
> That is becomes easier to write large, messy programs because programmers feel more safe in the future to refactor, is a tradeoff
Sure, I guess this is true in principle - but you could say the same about IDEs, or version control, or grep. The effect size is small.
This is true at the code level. But at the system-design level, this documentation is the extra coupling.
I feel like it's important to understand this. I agree with the original commenter; in engineering, nothing is truly free. In many cases, this extra coupling helps keep a system strong and stable, like extra nails holding planks of wood together. In other cases, you may find that part of a system's spec actually missed the mark and now needs to be ripped up and redone. That extra coupling might now work against you!
Again, that doesn't mean that it wasn't worth having it. It is just important to understand tradeoffs in engineering.
No, the coupling (i.e. assumptions about what type this thing can be) is implicitly there in a typeless language. If you pass in the wrong thing it'll blow up. But it'll happen in production.
The coupling is always there, it's just a matter whether you make it explicit (this allowing errors to be caught early) or you pretend it's not there and let things crash in production.
You still do need to know that stuff if you have no types in your language, but the compiler won't help you.
In any case, though, wearing a seat belt or not is a choice one can make independently of all other factors. The cars come with seat belts, it's the same car either way. You click or not, nothing else changes about the car.
With types, however, that's not how it works. The tradeoff is... you may have to change your entire programming language, change your IDE, change your frameworks, rewrite existing code, etc. It's not analogous to seat belts at all. Do programmers want the compiler to catch mistakes? Of course they do, in an ideal world. Why wouldn't they? But there are a lot of tradeoffs here that don't exist in the case of seat belts.
Like seat belts, you can choose to wear or not wear a helmet independent of all other factors. The motorcycle or bicycle is exactly the same regardless of whether you're wearing a helmet. Also, everyone understands the benefits of a helmet. The benefits don't make everyone wear a helmet, but everyone is clear about why there are helmets.
How is this any different from the selt belt case? "(1) believe they'll beat the statistics, and thus no statistical argument will convince them or (2) value their "freedom" a lot more than they value their own lives"
Would you really expect an article "The helmet is a biker's best friend" to convince them?
Everyone knows that a helmet helps prevent head injuries. That doesn't need to be explained. Whether the tradeoff of messing up your hair or whatever is worth it is up to the individual to decide, but there's nothing complex about the decision that needs an academic discussion.
Besides, they aren't going print this article out and take it to a cave in the mountains to learn about type systems for a year. They're going to read other stuff along the way.
How could the downsides possibly be apparent if the upsides are so mysterious they need an article to spell them out?
> It's an article design to help certain programmers learn a particular thing
Have they actually learned that particular thing if they don't know the tradeoffs they're making? I would argue they haven't. You need to know what you're getting and what you're giving up before you can decide whether something is worth using at all. There are too many articles hyping the upsides of technology X, but nobody asking what the downsides are.