4 ms·

This thread is going to quickly devolve into the pro-type safety vs. the pro-flexibility camps. Look, if you looooove declaring types and somehow thinks this re

This thread is going to quickly devolve into the pro-type safety vs. the pro-flexibility camps. Look, if you looooove declaring types and somehow thinks this reduces bugs, great. If you just want to focus on the logic of your app and don't feel like managing the minutia of how the computer stores a number or string, great. But if you want to declare one is fundamentally or empirically better, then you need to get a grip. We can all like different things, it's allowed. The one core thing I'd like to stress, however, is that TS is not JS. If you use TypeScript, you are not using JavaScript. They are cousins, sure, or maybe uncle and niece, but they are not the same.

taude 8y ago
I'd say the dynamic vs static should really be about team size/makeup and life expectancy of code base. Basically quickly building up things in a small team that might be around until a mature lifecycle (maybe startup-ish, prototype) vs big corp scenario where people working on code base will cycle through and the product is known to have a 5+ year life cycle from the start....
- russellbeattie 8y ago
  Yes, what you said is the 'generally accepted wisdom' and the cudgel with which the type-safety folk like to use to beat on the dynamic type folk, since pretty much all projects could potentially grow at some point, why not just start with type-safe first? I could argue, but won't, that the accepted wisdom isn't correct, and large code base management is more about code discipline and reviews rather than whether your language requires types or not.
sickcodebruh 8y ago
TO BATTLE! Reducing it to "pro type-safety vs pro-flexibility" doesn't tell the whole story. For me, it's "pro-consistency vs pro-inconsistency" or "pro-tooling-that-makes-sure-I-don't-screw-up-something-trivial vs pro-keeping-absolutely-everything-in-my-head-at-all-times." Of course, that's _also_ pretty superficial and unfair -- plenty of amazing work has and will be done without type safety -- but as a bonafide Kool-Aid-drinking TypeScript Cultist, I feel obligated to share that because it's made my life better.
- irascible 8y ago
  Why aren't you using cross compiled Rust then?
jchw 8y ago
>Look, if you looooove declaring types and somehow thinks this reduces bugs, great. I'm speechless. Do you believe type checking doesn't catch bugs? Because that's what it sounds like you're implying. >But if you want to declare one is fundamentally or empirically better, then you need to get a grip. We can all like different things, it's allowed. This is a ridiculous argument. People make such declarations because they believe them to be true. You're basically saying, "You're insane if you disagree with me that one is not fundamentally better than the other." >The one core thing I'd like to stress, however, is that TS is not JS. If you use TypeScript, you are not using JavaScript. They are cousins, sure, or maybe uncle and niece, but they are not the same. I don't see why this would stop anyone from using TypeScript. Why should we care? (Also: When people say 'TypeScript is just JavaScript,' it's not because they're crazy. It is just saying something else. TypeScript is a strict superset of JavaScript that is compatible and compiles down trivially, which is in contrast to CoffeeScript for example, which was previously popular. Nobody was ever claiming that TypeScript triple equals JavaScript.) ... You start off by implying that type-checking is ineffective ('[somehow think] this reduces bugs') then call for people to not engage in flame wars... what did you expect to happen?!
- russellbeattie 8y ago
  Hmm... the irony! It's almost as if one group constantly has a chip on it's shoulder and I was insinuating they should cut their crap! Huh! :-D
  - jchw 8y ago
    Okay, I don't think you're acting in good faith. Sorry, but thats not the response you get from someone not writing flamebait.
    - russellbeattie 8y ago
      It's not flame bait at all, unless you aren't willing to accept different opinions, or have no real world experience. I believe exactly what I wrote. The discussion is unproductive and we can argue all day about the pros and cons. And TS isn't just JS, that's just marketing. Example: enum Color { red = 1, green = 2, blue = 4 } isn't even close to valid JS. And don't respond with caveats, as I don't care. I apparently know more than you do about it.
atombender 8y ago
There's a very simple rebuttal. Have this function: function greetPerson(name) { ... } Call it in a bunch of places like this: greetPerson(user.name) Now change the signature: function greetPerson(userId) { ... } What code do you need to update to fix the breakage you now caused? A dynamically typed language can't tell you without some serious static analysis, which to my knowledge doesn't exist. TypeScript can know this both when linting in your editor, and at compile time. Old signature: function greetPerson(name: string) New signature: function greetPerson(userId: number) Just write tests, some might say. But you've got your test right there: The type is the test for this particular problem. Unit tests should test behaviour, not types. (Since unit tests should cover failure cases, duck-typed languages arguably require that you test calling your functions with a wide variety of bad inputs.) In practice, large programs will never have enough, or good enough, tests, because they have to be written separately from the code they're testing. Type systems allow us to describe our rules in the code. Note that there are statically typed languages (OCaml and F# being notable examples) where the type inference is sufficiently good that you rarely need to write out the types of signatures, let alone variables or return values: let greetPerson name = ... greetPerson user.name The fact that they can do this invalidates the usual "static typing require lots of unnecessary verbosity" argument, because it's not true.

taude 8y ago

I'd say the dynamic vs static should really be about team size/makeup and life expectancy of code base. Basically quickly building up things in a small team that might be around until a mature lifecycle (maybe startup-ish, prototype) vs big corp scenario where people working on code base will cycle through and the product is known to have a 5+ year life cycle from the start....

russellbeattie 8y ago
Yes, what you said is the 'generally accepted wisdom' and the cudgel with which the type-safety folk like to use to beat on the dynamic type folk, since pretty much all projects could potentially grow at some point, why not just start with type-safe first? I could argue, but won't, that the accepted wisdom isn't correct, and large code base management is more about code discipline and reviews rather than whether your language requires types or not.

sickcodebruh 8y ago

TO BATTLE! Reducing it to "pro type-safety vs pro-flexibility" doesn't tell the whole story. For me, it's "pro-consistency vs pro-inconsistency" or "pro-tooling-that-makes-sure-I-don't-screw-up-something-trivial vs pro-keeping-absolutely-everything-in-my-head-at-all-times." Of course, that's _also_ pretty superficial and unfair -- plenty of amazing work has and will be done without type safety -- but as a bonafide Kool-Aid-drinking TypeScript Cultist, I feel obligated to share that because it's made my life better.

irascible 8y ago
Why aren't you using cross compiled Rust then?

jchw 8y ago

>Look, if you looooove declaring types and somehow thinks this reduces bugs, great. I'm speechless. Do you believe type checking doesn't catch bugs? Because that's what it sounds like you're implying. >But if you want to declare one is fundamentally or empirically better, then you need to get a grip. We can all like different things, it's allowed. This is a ridiculous argument. People make such declarations because they believe them to be true. You're basically saying, "You're insane if you disagree with me that one is not fundamentally better than the other." >The one core thing I'd like to stress, however, is that TS is not JS. If you use TypeScript, you are not using JavaScript. They are cousins, sure, or maybe uncle and niece, but they are not the same. I don't see why this would stop anyone from using TypeScript. Why should we care? (Also: When people say 'TypeScript is just JavaScript,' it's not because they're crazy. It is just saying something else. TypeScript is a strict superset of JavaScript that is compatible and compiles down trivially, which is in contrast to CoffeeScript for example, which was previously popular. Nobody was ever claiming that TypeScript triple equals JavaScript.) ... You start off by implying that type-checking is ineffective ('[somehow think] this reduces bugs') then call for people to not engage in flame wars... what did you expect to happen?!

russellbeattie 8y ago
Hmm... the irony! It's almost as if one group constantly has a chip on it's shoulder and I was insinuating they should cut their crap! Huh! :-D
- jchw 8y ago
  Okay, I don't think you're acting in good faith. Sorry, but thats not the response you get from someone not writing flamebait.
  - russellbeattie 8y ago
    It's not flame bait at all, unless you aren't willing to accept different opinions, or have no real world experience. I believe exactly what I wrote. The discussion is unproductive and we can argue all day about the pros and cons. And TS isn't just JS, that's just marketing. Example: enum Color { red = 1, green = 2, blue = 4 } isn't even close to valid JS. And don't respond with caveats, as I don't care. I apparently know more than you do about it.

atombender 8y ago

There's a very simple rebuttal. Have this function: function greetPerson(name) { ... } Call it in a bunch of places like this: greetPerson(user.name) Now change the signature: function greetPerson(userId) { ... } What code do you need to update to fix the breakage you now caused? A dynamically typed language can't tell you without some serious static analysis, which to my knowledge doesn't exist. TypeScript can know this both when linting in your editor, and at compile time. Old signature: function greetPerson(name: string) New signature: function greetPerson(userId: number) Just write tests, some might say. But you've got your test right there: The type is the test for this particular problem. Unit tests should test behaviour, not types. (Since unit tests should cover failure cases, duck-typed languages arguably require that you test calling your functions with a wide variety of bad inputs.) In practice, large programs will never have enough, or good enough, tests, because they have to be written separately from the code they're testing. Type systems allow us to describe our rules in the code. Note that there are statically typed languages (OCaml and F# being notable examples) where the type inference is sufficiently good that you rarely need to write out the types of signatures, let alone variables or return values: let greetPerson name = ... greetPerson user.name The fact that they can do this invalidates the usual "static typing require lots of unnecessary verbosity" argument, because it's not true.