Hacker News Reader

Comment by asark | Hacker News Reader

> Consequently, in his point-based model, he assigned that particular feature of the language +0.1 points.

That's because his stupid chart is comparing a bunch of different things to TS instead of just comparing it to JS. In that case he's putting it up against TDD + code reviews, for reasons that I entirely do not understand. His numbers are so wildly incommensurate that they don't even make sense for any sort of informal water-cooler analysis.

[EDIT] if... if I'm reading his reasoning for that 0.1 score correctly, he'd still give it a -3.9 ROI if it caught 100-friggin-percent of bugs that would otherwise reach production, unaided by any other tools or practices. WTF.

[EDIT EDIT] for reference, that means he rates the overhead of noting one's types at 3x as bad as the benefit of magically catching 100% of bugs would be good. This is what I mean by these individual values being ZOMGWTF incommensurate.

View on HN

> In that case he's putting it up against TDD + code reviews

Not to mention that TypeScript makes it easier to do both. Code reviews are easier when you can read the types instead of trying to infer them by reading the code, writing tests is easier when you have type-safe test data.

The reasons you don't understand are clearly explained in the article (you can't skip them because 80% of bugs are not detectable by TypeScript), and if TypeScript actually could catch 100% of bugs, I'd rate it a perfect 10 on that point and the ROI would be game over. TypeScript would win because you could skip the other quality controls and save a ton of time.

I wish.

No, I read it. It's nonsense and your numbers are bad beyond any excuse of napkin-math. They're plain ol' down-home gibberish.

[edit] let me demonstrate: the most basic problem is that your numbers in various categories do not measure up to one another in any way that makes sense. -3 for writing typings, +0.1 for catching 10-20% of bugs that would reach production. Either you're having way more trouble writing types than you should or you have so few bugs that catching 10-20% of them isn't very valuable. Plus, read the thread. You just ignore all kinds of benefits of TypeScript (mostly benefits of having any, even half-assed, static type system on top of JS, period). If you like something else, propose it and compare TS to that. You're saying it's 1/10 better than vanilla JS with TDD + code review but 30x worse in terms of that benefit than JS when it comes to time spent adding types. 30. Times. That's just one example, the whole chart's a wreck in a similar fashion. Plus I bet if you ask on this thread folks will be happy to suggest + entries you simply omitted. See the ones suggesting (correctly) that static types make both TDD and code review, which you like, a hell of a lot faster.

In the worst case if some little thing you want to do won't work well in TS or is too expensive to type properly, write that piece in JS. Yes, that's terrible. [pause; significant look; raised eyebrows]. But it's not worse than JS. Obviously. And you can do that in TS. It's part of what makes it such an incredibly easy sell.

First of all, you're wildly over-stating the difference. The scale based on percent of time spent or saved. It's impossible on this scale to even say that TypeScript is three times worse than no types, let alone thirty times.

As for the bug reducing benefit, yes it's up to 20% if you do nothing but TypeScript. As explained in the article, 80% of bugs can't be addressed by static types at all, so you can't skip the other measures safely. The zero point includes the other measures, which easily cover 90%+ reductions, combined.

Since other measures catch type errors, too, we apply the TypeScript reduction after discounting the other errors caught. Even with the maximum benefit of the doubt, assuming TypeScript catches 20% of the remainder, it's still a small percent of a small percent. You get exponentially diminishing returns with each bug prevention measure you apply, and TypeScript can't catch the lion's share of bugs, so it's the only one that makes sense to leave out as a quality control measure.

Eric, my problem with this analysis is that 15% figure for bugs that would have been caught by TS only applies to the "public" bugs, bugs the programmer committed because apparently the code appeared to be working (to him).

But the majority of my bugs aren't "public", because I see that things aren't working when I run the code and don't commit it. With the combo of IDE just-in-time help/suggestions/reminders/enforcement, a lot of mistakes that I will catch at some point later by the "other means" you compare to, before I commit and push (which is the majority of my bugs) are prevented or immediately pointed out. Stopping them before they start instead of having them cause write-run-debug cycles, which will stop them before they are committed, is a huge advantage to me that won't show up at all in the "public" bug analysis.

"Immediately tells me things that I will eventually discover later by other means after wasting time" is a big, fuzzy category in which most of the value I get from several typed languages seems to hide from many analyses, even those that mention IDE features.

This is exactly my problem with the article. Public data is the worst data to rely your assumptions on in this subject. The whole point of the type-checker is to find problems and bugs before commiting the code and we will never have access to the real data because this happens all the time and people just fix the issues and move on with their lives

Reply on news.ycombinator.com