4 ms·

> At this point it's beyond a hill I'm willing do die on. I'm not really interested in discussing it. If you don't get it I probably don't want to talk to you a

> At this point it's beyond a hill I'm willing do die on. I'm not really interested in discussing it. If you don't get it I probably don't want to talk to you about it, I might even think less of you as a software developer. That's a pretty strong take! I don't think there are many things that I feel similarly about... maybe if someone suggested that they don't need test environments and can just deploy changes to prod without testing or CI/CD and just see what happens, when it'd be my employment on the line, but even that's a pretty contrived and out there example. > The amount of pre-existing respect for someone I'd need to have before I engage in a good-faith discussion on "are types good" is pretty high. My problem is that not all type systems and the way you use them are equal. When working with back end code, I really like .NET or even Java having a type system there for me. I know that people suggest that they have their own shortcomings (type erasure, NPEs, no multiple inheritance, even smaller things like C# enums not supporting methods) and that there are better options out there, but generally you can turn off the part of your brain that'd worry about the language too much and just deal with the domain problem at hand. Something like JetBrains are also excellent, because with the type system suddenly the tool also can reason about the language constructs you're using and give you all sorts of good suggestions and refactoring options. Whereas with something like TypeScript in combination with React, there are times where you fight the type system instead. That's just the impression that I got working on a few projects for a while, in comparison to React with JS (perhaps the code was also a bit too clever), while with Angular it felt more coherent to me (despite Angular being more complex otherwise and not really my first choice). In the end, I gravitate towards Vue with JS for my personal stuff, but it's not like you can just say no to TypeScript when you need to maintain something long term. I can't actually remember who said that they ditched TypeScript for similar reasons, but the argument was basically that a non-insignificant part of their codebase was there just to satisfy the type system. TypeScript does what it's supposed to... but it feels like it could be easier.

insanitybit 3y ago
> That's a pretty strong take! Not even one of my spicier takes, just one of the few that I simply don't care to engage with further. > My problem is that not all type systems and the way you use them are equal. We agree. Some type systems suck so badly that I can see why people would be tempted to believe that all type systems suck.
- KronisLV 3y ago
  > Some type systems suck so badly that I can see why people would be tempted to believe that all type systems suck. But that's my point: people say that exact thing about Java and .NET, while I find them usable. Meanwhile TypeScript has cool stuff like union types and other stuff to the point where you can get pretty clever with it (https://codegolf.stackexchange.com/questions/237784/tips-for-golfing-in-typescripts-type-system https://codegolf.stackexchange.com/questions/237784/tips-for...), which many would describe as the type system being objectively better, yet it's also more difficult for me to use. In my mind, a good type system would let you do both basic stuff easily without too much work (to make sure that refactoring doesn't make you shoot yourself in the foot) and also encourage you to write the simplest code that you can get away with, while allowing you to get clever in the select few places where that is actually needed. Which is funny, because adjacent to that, Java and .NET (web) frameworks can be a masterclass in incidental complexity, even though for me the type systems don't get in the way too much. Edit: actually, I think I'll migrate a JS project to TS, this time in Vue. Perhaps Vue 3 will be a pleasant experience and if it won't, then I'll have a concrete list of things that caused me to feel this way.
  - satvikpendem 3y ago
    Vue is not too great with TypeScript in my experience. That's one of the reasons why I switched from Vue to React.
    - mcv 3y ago
      I thought Vue 3 was supposed to be native Typescript.
mcv 3y ago
I'm pretty agnostic about the whole thing. The topic has been done to death already. Types are great, but some ways of handling types can get in the way sometimes, and the excessive type declarations in older Java was just painful. Dynamic types can work fine too, but they work better in smaller projects than in bigger ones. Types do give you a lot more to hold onto, even if they're only compile-time types like Typescript. In large, complex projects where you're juggling a lot of different types, you want to know what you've got in your hands. That's pretty much my take. I don't hate anyone for having different ideas about it. But if you're going to use Typescript, don't use 'any'. At all. Unless you really don't know and the next step is figuring out what type you've got.
xxs 3y ago
>maybe if someone suggested that they don't need test environments and can just deploy changes to prod without testing or CI/CD and just see what happens That's actually not hard, you need to be able to run in dry mode, and run the same in an existing instance (in parallel), then compare the results. If you are happy you can continue with the roll up, disabling the dry mode.

insanitybit 3y ago

> That's a pretty strong take! Not even one of my spicier takes, just one of the few that I simply don't care to engage with further. > My problem is that not all type systems and the way you use them are equal. We agree. Some type systems suck so badly that I can see why people would be tempted to believe that all type systems suck.

KronisLV 3y ago
> Some type systems suck so badly that I can see why people would be tempted to believe that all type systems suck. But that's my point: people say that exact thing about Java and .NET, while I find them usable. Meanwhile TypeScript has cool stuff like union types and other stuff to the point where you can get pretty clever with it (https://codegolf.stackexchange.com/questions/237784/tips-for-golfing-in-typescripts-type-system https://codegolf.stackexchange.com/questions/237784/tips-for...), which many would describe as the type system being objectively better, yet it's also more difficult for me to use. In my mind, a good type system would let you do both basic stuff easily without too much work (to make sure that refactoring doesn't make you shoot yourself in the foot) and also encourage you to write the simplest code that you can get away with, while allowing you to get clever in the select few places where that is actually needed. Which is funny, because adjacent to that, Java and .NET (web) frameworks can be a masterclass in incidental complexity, even though for me the type systems don't get in the way too much. Edit: actually, I think I'll migrate a JS project to TS, this time in Vue. Perhaps Vue 3 will be a pleasant experience and if it won't, then I'll have a concrete list of things that caused me to feel this way.
- satvikpendem 3y ago
  Vue is not too great with TypeScript in my experience. That's one of the reasons why I switched from Vue to React.
  - mcv 3y ago
    I thought Vue 3 was supposed to be native Typescript.

mcv 3y ago

I'm pretty agnostic about the whole thing. The topic has been done to death already. Types are great, but some ways of handling types can get in the way sometimes, and the excessive type declarations in older Java was just painful. Dynamic types can work fine too, but they work better in smaller projects than in bigger ones. Types do give you a lot more to hold onto, even if they're only compile-time types like Typescript. In large, complex projects where you're juggling a lot of different types, you want to know what you've got in your hands. That's pretty much my take. I don't hate anyone for having different ideas about it. But if you're going to use Typescript, don't use 'any'. At all. Unless you really don't know and the next step is figuring out what type you've got.

xxs 3y ago

>maybe if someone suggested that they don't need test environments and can just deploy changes to prod without testing or CI/CD and just see what happens That's actually not hard, you need to be able to run in dry mode, and run the same in an existing instance (in parallel), then compare the results. If you are happy you can continue with the roll up, disabling the dry mode.