4 ms·

I used Typescript for 2 years, and I'm happy to report I'm dropping it and encouraging my team to do the same. Types are for compilers, not people, and personal

by IBCNU 6y ago

I used Typescript for 2 years, and I'm happy to report I'm dropping it and encouraging my team to do the same. Types are for compilers, not people, and personally I think there's more disadvantages than advantages re: time.

qayxc 6y ago
> Types are for compilers, not people, and personally I think there's more disadvantages than advantages The Haskell community strongly disagrees...
- verdagon 6y ago
  I dont know Haskell that well, but I thought it had strong static typing? Though, Haskell figures out the types for you, instead of you typing them in, maybe thats a big difference. In Haskell, do you find you have to think about the types anyway, or can you code it like you would clojure?
  - IBCNU 6y ago
    I come from a clojure background, maybe that's why I don't enjoy TS. I find that large projects, so much code is un-necessary, people spend a lot of time troubleshooting types instead of building functionality. Of course it depends on the project. Social security #'s is a different scenario than something like a game or frivolous retail...
jkachmar 6y ago
> Types are for compilers, not people [...] This strikes me as a similar sentiment to “Requirements are for managers, not engineers”
eyerony 6y ago
> Types are for compilers, not people, and personally I think there's more disadvantages than advantages re: time. Hard disagree. Types are for people. They're for people to tell compilers what to tell people. Which is incredibly useful. They are first and foremost a communication and code-navigation/wayfinding tool—for people. As for all this extra time some folks keep complaining about, we must be using TypeScript entirely differently, somehow. I don't get it at all. Its overhead is less than the time it saves me in typo-spotting alone, let alone all the other benefits. Takes 5%, gives back 20-30%. It's not even close. Maybe it's a problem for really, really slow typists? I'm not even some kind of editor wizard and it hardly slows me down. It can't be thinking up the type definitions since you need to do that anyway—right? I hope? And at that point you may as well write them down.
- IBCNU 6y ago
  My experience is by definition anecdotal, but what I've found is as the team grows more and more work seems to focus on defining the types, futzing with the types, talking about the types instead of talking about features. I come from a Clojure/script background so I suppose I'm trying to say if (in building UI's) if you bake in strong immutability and a functional approach (like re-frame... but JS) types, to me, become less and less of a concern. Of course it's highly dependent on the business requirements.

by IBCNU 6y ago

qayxc 6y ago

> Types are for compilers, not people, and personally I think there's more disadvantages than advantages The Haskell community strongly disagrees...

verdagon 6y ago
I dont know Haskell that well, but I thought it had strong static typing? Though, Haskell figures out the types for you, instead of you typing them in, maybe thats a big difference. In Haskell, do you find you have to think about the types anyway, or can you code it like you would clojure?
- IBCNU 6y ago
  I come from a clojure background, maybe that's why I don't enjoy TS. I find that large projects, so much code is un-necessary, people spend a lot of time troubleshooting types instead of building functionality. Of course it depends on the project. Social security #'s is a different scenario than something like a game or frivolous retail...

jkachmar 6y ago

> Types are for compilers, not people [...] This strikes me as a similar sentiment to “Requirements are for managers, not engineers”

eyerony 6y ago

> Types are for compilers, not people, and personally I think there's more disadvantages than advantages re: time. Hard disagree. Types are for people. They're for people to tell compilers what to tell people. Which is incredibly useful. They are first and foremost a communication and code-navigation/wayfinding tool—for people. As for all this extra time some folks keep complaining about, we must be using TypeScript entirely differently, somehow. I don't get it at all. Its overhead is less than the time it saves me in typo-spotting alone, let alone all the other benefits. Takes 5%, gives back 20-30%. It's not even close. Maybe it's a problem for really, really slow typists? I'm not even some kind of editor wizard and it hardly slows me down. It can't be thinking up the type definitions since you need to do that anyway—right? I hope? And at that point you may as well write them down.

IBCNU 6y ago
My experience is by definition anecdotal, but what I've found is as the team grows more and more work seems to focus on defining the types, futzing with the types, talking about the types instead of talking about features. I come from a Clojure/script background so I suppose I'm trying to say if (in building UI's) if you bake in strong immutability and a functional approach (like re-frame... but JS) types, to me, become less and less of a concern. Of course it's highly dependent on the business requirements.