8 ms·

Like what? TypeScript is careful to avoid a lot of JS's footguns (implicits, undefineds, etc.)

tkubacki 9y ago
TS has nice features to avoid js bombs but all JS 'bad code' is legit by definition (JS superset). TS is super nice compared to JS but it is NOT excellent Lang.
- johnfn 9y ago
  > all JS 'bad code' is legit by definition (JS superset) That's not true. There's a lot of JS code out there that is certainly not legit in TS. Probably the shortest example is `1 === "a"` which produces a TypeError, but if you use TS at all you'll understand that a lot of bad patterns are made painful or impossible thanks to the strict type system.
legulere 9y ago
== versus === and all the other weak typing wats, undefined type still exists in typescript, no integer type, UTF16 strings are the ones coming to my mind and I don't even program in JS/TS
- johnfn 9y ago
  I'm pretty sure all weak typing warts basically stem from equality checks with ==/===. If you use === all the time you'll never run into them. TS has optionals so undefined is not an issue. The rest is valid.
  - legulere 9y ago
    There are also some JavaScript functions like isNaN that also do type coercion and of course +. How is this handled in typescript?
    - nycdotnet 9y ago
      In a word, "correctly". The result of an expression with + or isNaN() will be of whatever type the JS spec says it should be. This is one of the less frequently touted, but more useful aspects of TypeScript - the lib.d.ts file acts as a partner to explain to you how the built-in JS type system actually works without you having to memorize or look up everything in docs.
  - bcherny 9y ago
    By optionals I assume you mean null and undefined types, not optionals in the Scala or Swift sense.
- bcherny 9y ago
  For == vs === use a linter, same as you would for warts in other languages. What's the issue with undefined - is it that you would use null instead? I don't feel a need for integer type, but maybe that's because I grew up on JS. Integers feel like warts to me in a lot of cases, ie why would 2/3 == 1?
  - ridiculous_fish 9y ago
    2/3 === .666666666666666629659232512495 is probably worse, because it can seduce you into thinking it's accurate. Why is `2 / 3 * 3 === 3`, but `1 / 3 * 3 < 3`? JS's floating-point-or-bust, combined with some weird Math semantics, makes it challenging to write numerically correct functions.
    - bcherny 9y ago
      That's a fair point. Which language do you think does it better, or is there a library you like to use (eg. Haskell's scientific type)?
      - ridiculous_fish 9y ago
        Floating point tends to break all sorts of assumptions. For languages without static types, bignum integers and distinct operators for truncating vs FP division is probably best. This is how Python 3 works, plus Haskell and SML (with static types).
ridiculous_fish 9y ago
TypeScript addresses many of JavaScript's type-related issues but retains other JavaScript insanity: bizarre array semantics, Unicode ignorance, no integer arithmetic, regex facepalms, Math weirdness, etc.
- bcherny 9y ago
  What do you mean by bizarre array semantics? Genuinely curious.
  - ridiculous_fish 9y ago
    Oh man, how much time do you have... The root of the wtf is how Arrays play double-duty as both indexed and associative. The ES spec says that if you modify a property of an array object, the implementation must check if the (necessarily String) key changes after being round-tripped through a UInt32 conversion. If not, the key is a special array index that bumps the length; otherwise the length is unaffected. var arr1 = []; arr1[2147483648]=1; // arr1.length == 0 var arr2 = []; arr2[2147483647]=1; // arr2.length == 2147483648 var arr3 = []; arr3[-1]=1; // arr3.length == 0 Of course strings participate in this nonsense: var arr = []; arr["12345"] = 1; // arr.length == 123456 This is JavaScript so naturally .length is settable: var arr = []; arr.length = 3; // works! But implementations are still required to distinguish between keys that are undefined and keys that outright don't exist: var arr = []; arr.length = 3; arr[0] = arr[2] = undefined; for (key in arr) print(key); // 0, 2 And of course you can set whatever random associative array property you like: var arr = []; arr[1] = true; arr[3.5] = false; // "works", .length is still 2 The intent is that array implementations may use efficient unboxed contiguous storage, but the spec requires that arrays may be sparse so it's still necessary to track which keys are actually set even if values are undefined. Want to iterate an array's keys? There's no requirement that array indexes start at 0, and you may encounter random other keys from the array prototype. TypedArrays are more limited/sane, thankfully.
    - int_19h 9y ago
      Every time I see something like this, I stop and consider just how saner Lua is, even though in many ways it adopted similar approaches (e.g. associative arrays doubling as regular ones).

TS has nice features to avoid js bombs but all JS 'bad code' is legit by definition (JS superset). TS is super nice compared to JS but it is NOT excellent Lang.

johnfn 9y ago
> all JS 'bad code' is legit by definition (JS superset) That's not true. There's a lot of JS code out there that is certainly not legit in TS. Probably the shortest example is `1 === "a"` which produces a TypeError, but if you use TS at all you'll understand that a lot of bad patterns are made painful or impossible thanks to the strict type system.

legulere 9y ago

== versus === and all the other weak typing wats, undefined type still exists in typescript, no integer type, UTF16 strings are the ones coming to my mind and I don't even program in JS/TS

johnfn 9y ago
I'm pretty sure all weak typing warts basically stem from equality checks with ==/===. If you use === all the time you'll never run into them. TS has optionals so undefined is not an issue. The rest is valid.
- legulere 9y ago
  There are also some JavaScript functions like isNaN that also do type coercion and of course +. How is this handled in typescript?
  - nycdotnet 9y ago
    In a word, "correctly". The result of an expression with + or isNaN() will be of whatever type the JS spec says it should be. This is one of the less frequently touted, but more useful aspects of TypeScript - the lib.d.ts file acts as a partner to explain to you how the built-in JS type system actually works without you having to memorize or look up everything in docs.
- bcherny 9y ago
  By optionals I assume you mean null and undefined types, not optionals in the Scala or Swift sense.
bcherny 9y ago
For == vs === use a linter, same as you would for warts in other languages. What's the issue with undefined - is it that you would use null instead? I don't feel a need for integer type, but maybe that's because I grew up on JS. Integers feel like warts to me in a lot of cases, ie why would 2/3 == 1?
- ridiculous_fish 9y ago
  2/3 === .666666666666666629659232512495 is probably worse, because it can seduce you into thinking it's accurate. Why is `2 / 3 * 3 === 3`, but `1 / 3 * 3 < 3`? JS's floating-point-or-bust, combined with some weird Math semantics, makes it challenging to write numerically correct functions.
  - bcherny 9y ago
    That's a fair point. Which language do you think does it better, or is there a library you like to use (eg. Haskell's scientific type)?
    - ridiculous_fish 9y ago
      Floating point tends to break all sorts of assumptions. For languages without static types, bignum integers and distinct operators for truncating vs FP division is probably best. This is how Python 3 works, plus Haskell and SML (with static types).

ridiculous_fish 9y ago

TypeScript addresses many of JavaScript's type-related issues but retains other JavaScript insanity: bizarre array semantics, Unicode ignorance, no integer arithmetic, regex facepalms, Math weirdness, etc.

bcherny 9y ago
What do you mean by bizarre array semantics? Genuinely curious.
- ridiculous_fish 9y ago
  Oh man, how much time do you have... The root of the wtf is how Arrays play double-duty as both indexed and associative. The ES spec says that if you modify a property of an array object, the implementation must check if the (necessarily String) key changes after being round-tripped through a UInt32 conversion. If not, the key is a special array index that bumps the length; otherwise the length is unaffected. var arr1 = []; arr1[2147483648]=1; // arr1.length == 0 var arr2 = []; arr2[2147483647]=1; // arr2.length == 2147483648 var arr3 = []; arr3[-1]=1; // arr3.length == 0 Of course strings participate in this nonsense: var arr = []; arr["12345"] = 1; // arr.length == 123456 This is JavaScript so naturally .length is settable: var arr = []; arr.length = 3; // works! But implementations are still required to distinguish between keys that are undefined and keys that outright don't exist: var arr = []; arr.length = 3; arr[0] = arr[2] = undefined; for (key in arr) print(key); // 0, 2 And of course you can set whatever random associative array property you like: var arr = []; arr[1] = true; arr[3.5] = false; // "works", .length is still 2 The intent is that array implementations may use efficient unboxed contiguous storage, but the spec requires that arrays may be sparse so it's still necessary to track which keys are actually set even if values are undefined. Want to iterate an array's keys? There's no requirement that array indexes start at 0, and you may encounter random other keys from the array prototype. TypedArrays are more limited/sane, thankfully.
  - int_19h 9y ago
    Every time I see something like this, I stop and consider just how saner Lua is, even though in many ways it adopted similar approaches (e.g. associative arrays doubling as regular ones).