5 ms·

> 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 downside

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

saagarjha 4y ago
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.”)
- lapcat 4y ago
  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.
  - saagarjha 4y ago
    Replace it with helmets if you want a more controversial option.
    - lapcat 4y ago
      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.
      - saagarjha 4y ago
        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.
        lapcat 4y ago
        > 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.
dkarl 4y ago
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.
howenterprisey 4y ago
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.
- capableweb 4y ago
  > 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.
  - jolux 4y ago
    > That you introduce more coupling is a tradeoff. That’s not inherent in static types.
  - hither_shores 4y ago
    > 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.

saagarjha 4y ago

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.”)

lapcat 4y ago
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.
- saagarjha 4y ago
  Replace it with helmets if you want a more controversial option.
  - lapcat 4y ago
    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.
    - saagarjha 4y ago
      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.
      - lapcat 4y ago
        > 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.

dkarl 4y ago

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.

howenterprisey 4y ago

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.

capableweb 4y ago
> 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.
- jolux 4y ago
  > That you introduce more coupling is a tradeoff. That’s not inherent in static types.
- hither_shores 4y ago
  > 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.