Hacker News Reader

Comment by bcherny | Hacker News Reader

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

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.

> 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.

== 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

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.

There are also some JavaScript functions like isNaN that also do type coercion and of course +. How is this handled in typescript?

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.

By optionals I assume you mean null and undefined types, not optionals in the Scala or Swift sense.

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?

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.

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)?

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).

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.

What do you mean by bizarre array semantics? Genuinely curious.

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.

>32bit number indices not affecting length is crazy - I didn't know about that (I don't think I've knowingly dealt with an array that big).

TypeScript thankfully prevents all of these errors except for the one I mentioned.

Do you work on the spec or a JS implementation? That's some pretty impressive knowledge.

I have not implemented Array, but I know the poor soul who did!

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).

Reply on news.ycombinator.com