4 ms·

You're treating this specific case as a fundamental issue, when it's a specific and superficial one that can be reasonably addressed in a future TS release: Se

You're treating this specific case as a fundamental issue, when it's a specific and superficial one that can be reasonably addressed in a future TS release: See for example: - Nominal types proposal https://github.com/Microsoft/TypeScript/issues/202 https://github.com/Microsoft/TypeScript/issues/202 - Co/contravariance annotations proposal https://github.com/Microsoft/TypeScript/issues/10717 https://github.com/Microsoft/TypeScript/issues/10717

bad_user 9y ago
These choices are fundamental to the language as it was designed. There's nothing more fundamental than how variance works. Want to bet that in 2 years from now we are still going to talk about the same language with the same issues, and that those two proposals are going to be rejected?
- bcherny 9y ago
  I'm not sure I understand why you think that. TypeScript explicitly prefers real world usability to theoretical soundness, so if the community is vocal about the need for these features, I don't see why TS would turn them down.
  - bad_user 9y ago
    > real world usability to theoretical soundness The soundness we are talking about in this case isn't theoretical at all and in fact such an argument is anti-intellectual. This is anti-intellectualism. As for the "community", we are talking about one where the majority has never worked in sane static languages.
    - bcherny 9y ago
      You are misunderstanding what I said. Either one of the 2 issues I linked would fix the specific problems you outlined. You don't need a globally sound type system, H-M inference, or anything like that to fix those specific problems; local inference and opt-in nominal typing would work just as well. Having used TS daily for a few years, I can vouch that your cases are pathological, and don't come up in practice often, if at all.
  - shados 9y ago
    Even if they enable it, it might be through a switch like strict nulls (which was a huge mistake to implement so late). That's not great.
    - bcherny 9y ago
      I agree they waited too long for strict nulls! However, both features I linked at currently proposed seem to be backwards compatible, so hopefully no switch.
      - shados 9y ago
        For sure that's great. The issue are still: - it's not there today - it still has to be bolted on (eg: adding new keywords, as opposed to, let say, Flow automatically doing nominal typing for Classes, which was the right move). - The ecosystem did not get to take advantage of it for years, so existing types, libraries, etc, are not written that way. That's a lot of tech debt. That's why new languages keep popping up all the time. The later you bring in critical features, the more bloated you force the system to be. I will admit TypeScript has been doing a decent job at containing the bloat (most of the crap features were actually what they implemented super early on, like the namespaces, enums, etc...the new stuff is really cool). But I think having proper competition enabled that: see the original strict null issue, where people were all but saying it was not possible/practical. Good thing we had Flow as a counterargument. Now with Flow dying a slow death, we'll have less fragmentation (great!), but less competition (possibly stagnating language. Boo!)
        bcherny 9y ago
        I agree on both points. An interesting facet of your 1st point is Stroustrup's Rule [0], which gives more context for an explicit `nominal` keyword. [0] https://thefeedbackloop.xyz/stroustrups-rule-and-layering-over-time/ https://thefeedbackloop.xyz/stroustrups-rule-and-layering-ov...
        shados 9y ago

bad_user 9y ago

These choices are fundamental to the language as it was designed. There's nothing more fundamental than how variance works. Want to bet that in 2 years from now we are still going to talk about the same language with the same issues, and that those two proposals are going to be rejected?

bcherny 9y ago
I'm not sure I understand why you think that. TypeScript explicitly prefers real world usability to theoretical soundness, so if the community is vocal about the need for these features, I don't see why TS would turn them down.
- bad_user 9y ago
  > real world usability to theoretical soundness The soundness we are talking about in this case isn't theoretical at all and in fact such an argument is anti-intellectual. This is anti-intellectualism. As for the "community", we are talking about one where the majority has never worked in sane static languages.
  - bcherny 9y ago
    You are misunderstanding what I said. Either one of the 2 issues I linked would fix the specific problems you outlined. You don't need a globally sound type system, H-M inference, or anything like that to fix those specific problems; local inference and opt-in nominal typing would work just as well. Having used TS daily for a few years, I can vouch that your cases are pathological, and don't come up in practice often, if at all.
- shados 9y ago
  Even if they enable it, it might be through a switch like strict nulls (which was a huge mistake to implement so late). That's not great.
  - bcherny 9y ago
    I agree they waited too long for strict nulls! However, both features I linked at currently proposed seem to be backwards compatible, so hopefully no switch.
    - shados 9y ago
      For sure that's great. The issue are still: - it's not there today - it still has to be bolted on (eg: adding new keywords, as opposed to, let say, Flow automatically doing nominal typing for Classes, which was the right move). - The ecosystem did not get to take advantage of it for years, so existing types, libraries, etc, are not written that way. That's a lot of tech debt. That's why new languages keep popping up all the time. The later you bring in critical features, the more bloated you force the system to be. I will admit TypeScript has been doing a decent job at containing the bloat (most of the crap features were actually what they implemented super early on, like the namespaces, enums, etc...the new stuff is really cool). But I think having proper competition enabled that: see the original strict null issue, where people were all but saying it was not possible/practical. Good thing we had Flow as a counterargument. Now with Flow dying a slow death, we'll have less fragmentation (great!), but less competition (possibly stagnating language. Boo!)
      - bcherny 9y ago
        I agree on both points. An interesting facet of your 1st point is Stroustrup's Rule [0], which gives more context for an explicit `nominal` keyword. [0] https://thefeedbackloop.xyz/stroustrups-rule-and-layering-over-time/ https://thefeedbackloop.xyz/stroustrups-rule-and-layering-ov...
        shados 9y ago