19 ms·

That’s not my experience. If anything, I think the Typescript experience improves with each release: typings get more precise, the type system becomes more expr

by thiht 4y ago

That’s not my experience. If anything, I think the Typescript experience improves with each release: typings get more precise, the type system becomes more expressive and allows to simplify the type declarations that used to be more complex, and best of all, what worked before still works. And in most cases, you’re good to go with the basics, you just know that if you need to declare a complicated type, Typescript got your back.

esperent 4y ago
I agree that Typescript improves with each release as I and the people I work closely with use it, because we use the KISS approach to typing so we rarely do use new features, but when we do need them they're useful. But then I find some third party code which seems to use the kitchen sink approach to typing, AKA the "look at how smart we are" approach, and it's a nightmare to understand. A type system is supposed to make code easier to work with, by the time you're spending more time understanding the types than the actual code there's something wrong. In these cases I wish Typescript was more limited and I would gladly give up a lot of the new stuff to enforce simple types across the ecosystem. That said, I don't really have an opinion on who is at fault here - coders for writing overly elaborate types, or Typescript for allowing them.
- citrons 4y ago
  Also agree, with each release I get an "Eureka effect" that now I can solve the type issue I strugled couple months ago trying to create to just make some highly used function safer/easier to use for the developers. Example the new satisfies and some upcomign "as const" features to generics I'm looking forward to
- goto11 4y ago
  > That said, I don't really have an opinion on who is at fault here - coders for writing overly elaborate types, or Typescript for allowing them. Backwards compatibility is to blame. Typescript was designed to support a number of patterns which was already used in JavaScript. For example events are registered in the DOM like `element.addEventListener("click", (ev) => ...)`. The type of the callback will depend on the string passed as the first argument, so the type system need to support literal strings as type discriminators which is a weird feature not necessary in most other languages. If the API had been designed with static typing in mind from the beginning, it would have been designed differently and wouldn't need such a complex type system.
  - madeofpalk 4y ago
    Weird - using constant string discriminators feel very natural and normal to me in Typescript. What do other languages do without them?
    - refulgentis 4y ago
      Most model it as an actual enum, if backed by strings. Typescript, by comparison, requires being able to indicate a type just from a string argument
      - esprehn 4y ago
        Allowing literal strings and type aliases of unions of strings to represent enums doesn't seem unreasonable. It's the same concept as many other languages with some extra quotes, ex. https://ocaml.org/docs/data-types#a-simple-custom-type https://ocaml.org/docs/data-types#a-simple-custom-type
        deleted 4y ago
        [deleted]
      - wruza 4y ago
        This doesn’t change anything: foo(get_some_myenum_value(), …) {type:get_another(), …} These are as unguessable as if myenum was a string.
      - madeofpalk 4y ago
        Hmm. That doesn't feel like much of a difference to me?
        refulgentis 4y ago
        It's huge? I'm really confused lol. I write in Dart/Java/C++/ObjC/TS regularly to maintain a cross-platform library and this is a massive difference from every typechecker in any other language, much less the narrower thing of if the idea of reifying random strings into an enum is a novel feature. I get a very strong sense from the thread that people are talking past eachother, somehow.
- Aeolun 4y ago
  > A type system is supposed to make code easier to work with, by the time you're spending more time understanding the types than the actual code there's something wrong This may be true in a lot of cases, but certainly not all. I’ve spent a ton of time on the types that validate that the input/output schema of my request handler function matches the defined schemas, and that was hell, but now any other of our developers will see delightfully red squiggles when they do something wrong. That’s a force multiplier and absolutely worth the effort.
- solarkraft 4y ago
  What's bad about using clever types? My (limited) experience is that if they're done well they just work. I don't know why React-Query's types work the way they do, but I quite like that they do. Developing an intuition for it was a bit hard, but I believe this might rather be a failure of the documentation.
  - wruza 4y ago
    And if they aren’t, good luck debugging it. I remember recently some typing issue in a webpack config where a correct key was marked as a type error in a presence of another construct, despite being documented and having an effect. Also try exploring npm/telegraf classes (auto-documented) by looking at their type definitions. The whole bot api could have been written as simple repeated definitions, but someone chose the clever way of multi-level type mutations and derivatives. Typescript will soon need secondary community-maintained type contracts that are human-readable and cross-checked with those in libraries. Something like @humane-types/*.

by thiht 4y ago

esperent 4y ago

I agree that Typescript improves with each release as I and the people I work closely with use it, because we use the KISS approach to typing so we rarely do use new features, but when we do need them they're useful. But then I find some third party code which seems to use the kitchen sink approach to typing, AKA the "look at how smart we are" approach, and it's a nightmare to understand. A type system is supposed to make code easier to work with, by the time you're spending more time understanding the types than the actual code there's something wrong. In these cases I wish Typescript was more limited and I would gladly give up a lot of the new stuff to enforce simple types across the ecosystem. That said, I don't really have an opinion on who is at fault here - coders for writing overly elaborate types, or Typescript for allowing them.

citrons 4y ago
Also agree, with each release I get an "Eureka effect" that now I can solve the type issue I strugled couple months ago trying to create to just make some highly used function safer/easier to use for the developers. Example the new satisfies and some upcomign "as const" features to generics I'm looking forward to
goto11 4y ago
> That said, I don't really have an opinion on who is at fault here - coders for writing overly elaborate types, or Typescript for allowing them. Backwards compatibility is to blame. Typescript was designed to support a number of patterns which was already used in JavaScript. For example events are registered in the DOM like `element.addEventListener("click", (ev) => ...)`. The type of the callback will depend on the string passed as the first argument, so the type system need to support literal strings as type discriminators which is a weird feature not necessary in most other languages. If the API had been designed with static typing in mind from the beginning, it would have been designed differently and wouldn't need such a complex type system.
- madeofpalk 4y ago
  Weird - using constant string discriminators feel very natural and normal to me in Typescript. What do other languages do without them?
  - refulgentis 4y ago
    Most model it as an actual enum, if backed by strings. Typescript, by comparison, requires being able to indicate a type just from a string argument
    - esprehn 4y ago
      Allowing literal strings and type aliases of unions of strings to represent enums doesn't seem unreasonable. It's the same concept as many other languages with some extra quotes, ex. https://ocaml.org/docs/data-types#a-simple-custom-type https://ocaml.org/docs/data-types#a-simple-custom-type
      - deleted 4y ago
        [deleted]
    - wruza 4y ago
      This doesn’t change anything: foo(get_some_myenum_value(), …) {type:get_another(), …} These are as unguessable as if myenum was a string.
    - madeofpalk 4y ago
      Hmm. That doesn't feel like much of a difference to me?
      - refulgentis 4y ago
        It's huge? I'm really confused lol. I write in Dart/Java/C++/ObjC/TS regularly to maintain a cross-platform library and this is a massive difference from every typechecker in any other language, much less the narrower thing of if the idea of reifying random strings into an enum is a novel feature. I get a very strong sense from the thread that people are talking past eachother, somehow.
Aeolun 4y ago
> A type system is supposed to make code easier to work with, by the time you're spending more time understanding the types than the actual code there's something wrong This may be true in a lot of cases, but certainly not all. I’ve spent a ton of time on the types that validate that the input/output schema of my request handler function matches the defined schemas, and that was hell, but now any other of our developers will see delightfully red squiggles when they do something wrong. That’s a force multiplier and absolutely worth the effort.
solarkraft 4y ago
What's bad about using clever types? My (limited) experience is that if they're done well they just work. I don't know why React-Query's types work the way they do, but I quite like that they do. Developing an intuition for it was a bit hard, but I believe this might rather be a failure of the documentation.
- wruza 4y ago
  And if they aren’t, good luck debugging it. I remember recently some typing issue in a webpack config where a correct key was marked as a type error in a presence of another construct, despite being documented and having an effect. Also try exploring npm/telegraf classes (auto-documented) by looking at their type definitions. The whole bot api could have been written as simple repeated definitions, but someone chose the clever way of multi-level type mutations and derivatives. Typescript will soon need secondary community-maintained type contracts that are human-readable and cross-checked with those in libraries. Something like @humane-types/*.