3 ms·

First point: "I found a bug but can't give an example." Second point: "It adds a feature that's different from a similar language." These are not persuasive a

First point: "I found a bug but can't give an example." Second point: "It adds a feature that's different from a similar language." These are not persuasive arguments. I'm not trying to be unkind, but the first point is totally unsupported and the second doesn't elaborate on what's bad about classes besides that another language also has classes.

daviesgeek 9y ago
Definitely agree on the first, that's a good point. I probably should've been better about how I presented the data. "TypeScript still compiles down to JavaScript. It has no way of actually checking types." That's my point. Maybe I should make it more obvious in the article :) I'm not complaining about the fact that TS has classes or types, it's that TS compiles down to a language that has neither.
- dpratt71 9y ago
  TypeScript is certainly not flawless and there are tradeoffs. But this is not a good argument against TypeScript. The point of TypeScript and any other statically typed programming language is to have type checking performed statically, that is before the code is actually translated into machine instructions and run.
- nkohari 9y ago
  That argument doesn't really make sense. The type system is a feature of the compiler, so why would the output of the compiler need to be aware of it? Lots of typed languages compile to machine language, which has no inherent type system. Compilers which do add type information into the output are usually paired with a runtime that uses it for things like late binding or dynamic dispatch, but JavaScript doesn't support anything like that. Could you give a concrete example of a scenario in which the flexibility of the JavaScript type system would break the TypeScript type system?
  - daviesgeek 9y ago
    All fair points and totally valid. My concern is the facade/promise of type security.
    - rfw 9y ago
      Forgive me if I misunderstand, I still don't understand your concern – TypeScript has type safety because it can check types at compile time (vs. JavaScript which has very limited type safety at run time). I don't think it's fair to call it a facade, because it is definitely commonly accepted as type safe.
    - anderskaseorg 9y ago
      Your quarrel is not with JavaScript (as everyone else has pointed out, there’s no reason one can’t build a secure compile-time type system on top of JavaScript), but with some of the specific design decisions made by TypeScript that open soundness holes, such as “programmers are too stupid to understand the difference between covariance and contravariance, so we’ll pretend everything is bivariant”. See https://www.typescriptlang.org/docs/handbook/type-compatibility.html https://www.typescriptlang.org/docs/handbook/type-compatibil... for a less cynical presentation of these design decisions.
      - nkohari 9y ago
        This gives an explanation of why they made the choice: https://github.com/Microsoft/TypeScript/wiki/FAQ#why-are-function-parameters-bivariant https://github.com/Microsoft/TypeScript/wiki/FAQ#why-are-fun... Also, FWIW, in my experience, I don't think I've ever actually run into a problem with this in real code.
- revelation 9y ago
  Hello, at the end of the day it's all wildly swinging voltages imperfectly mapped to ones and zeroes. There are no types in any of this. It's all a huge number of abstractions stacked on top of each other. The implication that because TypeScript compiles to JS which has no types and is therefore wrong is pure drivel.
- mcphage 9y ago
  > it's that TS compiles down to a language that has neither What languages compile down to a language that has either? Most languages compile down to either machine code, or virtual machine code.
ctvo 9y ago
Conclusion: > TypeScript brings some great features, but, in my opinion, it comes with some significant pitfalls that need to be addressed and realized before jumping in with both feet. While listing none of the pitfalls unless the significant pitfall is classes mentioned a few paragraphs above. This reads like it had much grander aspirations and ended up being published 30% through.

daviesgeek 9y ago

Definitely agree on the first, that's a good point. I probably should've been better about how I presented the data. "TypeScript still compiles down to JavaScript. It has no way of actually checking types." That's my point. Maybe I should make it more obvious in the article :) I'm not complaining about the fact that TS has classes or types, it's that TS compiles down to a language that has neither.

dpratt71 9y ago
TypeScript is certainly not flawless and there are tradeoffs. But this is not a good argument against TypeScript. The point of TypeScript and any other statically typed programming language is to have type checking performed statically, that is before the code is actually translated into machine instructions and run.
nkohari 9y ago
That argument doesn't really make sense. The type system is a feature of the compiler, so why would the output of the compiler need to be aware of it? Lots of typed languages compile to machine language, which has no inherent type system. Compilers which do add type information into the output are usually paired with a runtime that uses it for things like late binding or dynamic dispatch, but JavaScript doesn't support anything like that. Could you give a concrete example of a scenario in which the flexibility of the JavaScript type system would break the TypeScript type system?
- daviesgeek 9y ago
  All fair points and totally valid. My concern is the facade/promise of type security.
  - rfw 9y ago
    Forgive me if I misunderstand, I still don't understand your concern – TypeScript has type safety because it can check types at compile time (vs. JavaScript which has very limited type safety at run time). I don't think it's fair to call it a facade, because it is definitely commonly accepted as type safe.
  - anderskaseorg 9y ago
    Your quarrel is not with JavaScript (as everyone else has pointed out, there’s no reason one can’t build a secure compile-time type system on top of JavaScript), but with some of the specific design decisions made by TypeScript that open soundness holes, such as “programmers are too stupid to understand the difference between covariance and contravariance, so we’ll pretend everything is bivariant”. See https://www.typescriptlang.org/docs/handbook/type-compatibility.html https://www.typescriptlang.org/docs/handbook/type-compatibil... for a less cynical presentation of these design decisions.
    - nkohari 9y ago
      This gives an explanation of why they made the choice: https://github.com/Microsoft/TypeScript/wiki/FAQ#why-are-function-parameters-bivariant https://github.com/Microsoft/TypeScript/wiki/FAQ#why-are-fun... Also, FWIW, in my experience, I don't think I've ever actually run into a problem with this in real code.
revelation 9y ago
Hello, at the end of the day it's all wildly swinging voltages imperfectly mapped to ones and zeroes. There are no types in any of this. It's all a huge number of abstractions stacked on top of each other. The implication that because TypeScript compiles to JS which has no types and is therefore wrong is pure drivel.
mcphage 9y ago
> it's that TS compiles down to a language that has neither What languages compile down to a language that has either? Most languages compile down to either machine code, or virtual machine code.

ctvo 9y ago

Conclusion: > TypeScript brings some great features, but, in my opinion, it comes with some significant pitfalls that need to be addressed and realized before jumping in with both feet. While listing none of the pitfalls unless the significant pitfall is classes mentioned a few paragraphs above. This reads like it had much grander aspirations and ended up being published 30% through.