Hacker News Reader

Comment by PainfullyNormal | Hacker News Reader

> What's more, for a programmer who doesn't get the value of types, the major downsides are already apparent, at least at a basic level.

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.

View on HN

I don't know what to tell you. The downsides are apparent. There is no logic theorem that says the upsides and downsides need to be equally as apparent.

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.

> The trade-off is obvious: you gain confidence about your program but you need to Learn More Stuff

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 you introduce more coupling is a tradeoff.

That’s not inherent in static types.

> That you introduce more coupling is a tradeoff. That the program (sometimes) gets harder to change is a tradeoff.

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.

> You don't introduce more coupling, you don't the coupling that already exists.

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.

> That you introduce more coupling is a tradeoff.

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.

> The trade-off is obvious: you gain confidence about your program but you need to Learn More Stuff.

You still do need to know that stuff if you have no types in your language, but the compiler won't help you.

How can the downsides of having to wear a seatbelt possibly be apparent if the upsides are so mysterious they need an article to spell them out? People have a quick aversion to things all the time. Sometimes the actual benefits need to be carefully explained. (“You are statically likely to be in a car crash. Wearing a seatbelt multiplies your chance of living through it.”)

I think almost everyone understands the benefits of both types and seat belts. The fact that a seat belt keeps you restrained during a crash is pretty intuitively obvious. The idiots who don't wear seat belts either (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.

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.

Replace it with helmets if you want a more controversial option.

How do helmets change the argument?

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.

It does, wearing helmets means you need to carry them around and store them, and it can ruin your hairstyle. People who can balance the tradeoffs make mostly reasonable decisions ("I write large programs with the support of a type system and eschew it for small scripts", "I will probably be OK without a helmet just biking slowly between two buildings at work") but some people will never accept the upsides as being worth it.

> some people will never accept the upsides as being worth it.

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.

They aren't going to learn that in a day or a week or a month. Maybe a year if they're extremely bright or are in a perfect environment for figuring it out, but most people take years. This article is a few minutes out of that hypothetical best-case year. If it gives them food for thought for a week, it'll be time better spent than 99% of what they could read, certainly better than if they read a comprehensive article that went 98% over their heads and got them hung up on things that they weren't yet able to experience and understand.

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.

Reply on news.ycombinator.com