Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The TypeScript Tax

medium.com

Post reply on HN
Print view View original

111–120 of 120 posts

Re: The TypeScript Tax

#111

Post by ericelliott »

seanwilson wrote: post #108
ericelliott wrote: post #99

Earlier quoted context omitted.

I get the same real-time error detection and refactoring help from type inference, lint, and TDD. Lint and inference gives me real-time editor feedback, TDD runs automatically on file save. I do consider TDD and code reviews are costly but you can't skip them with TypeScript because at least 80% of bugs are not detectable with TypeScript.

> because at least 80% of bugs are not detectable with TypeScript. I give up. You're repeatedly using this figure in this thread in a misleading way to make it sound like what you're saying is more legitimate that just an opinion. The abstract of the study you cite explicitly mentions this is a conservative estimate of effectiveness and ignores bugs detected in private: > Evaluating static type systems against public…

The number they consider conservative is that TypeScript can address up to 15% of public bugs. That's a different number than the proportion of public bugs found ts-undetectable because they're not type errors at all.

Re: The TypeScript Tax

#112

Post by SiVal »

ericelliott wrote: post #74
asark wrote: post #40

Earlier quoted context omitted.

> 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 in…

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.

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.

Re: The TypeScript Tax

#113

Post by z3t4 »

ng12 wrote: post #110
z3t4 wrote: post #101

Earlier quoted context omitted.

One thing I like about JS is that you dont have to think about types. It's an old convention in JS that you should be able to pass anything in and it will figure out what to do - instead of complain. JS has always had a test driven approach - test-code-test-code so you would detect if something is off. But the strictness do of course have trade-offs, for example being fast, easy and forgiving, vs forcing the develope…

> One thing I like about JS is that you dont have to think about types This is patently wrong. You _are_ thinking about types. Every object, function, variable you write has a type you store in your head. The question is about how easy it is to remember those types in 6 months, or how hard it would be for a new developer to figure them out. > JS has always had a test driven approach Yes, and you should keep that test…

For both good and bad it doesn't matter if you give me an apple or orange, they are about the same size so, but you might have problems giving me an banana. Example:

const len = x => x.length;

Re: The TypeScript Tax

#114

Post by z3t4 »

ng12 wrote: post #109
z3t4 wrote: post #105

Earlier quoted context omitted.

There's more to maintainability then just adding types. Maintainability is a process not a language.

Yes, and TypeScript is an incredibly powerful tool to make that process easier.

It's like using a bandage to prevent an injury. Yes it's good to have, but it doesn't prevent anyone from writing unmanageable code. Contrary it can make it even easier to write unmaintainable code.

Re: The TypeScript Tax

#115

Post by black-alert »

ng12 wrote: post #97
wanted2 wrote: post #62

Earlier quoted context omitted.

Typescript projects definitely give me the most pain. You regularly end up to the point you have to resort to 'any' after hours of looking for a stupid type definition. IMAO it's just one big waste of time, just landed a job with a good old JS codebase, what a relief. TS might help for junior and medior developers so they make less mistakes. But I'm pretty sure if you can code Javascript well Typescript only stands i…

> But I'm pretty sure if you can code Javascript well Typescript only stands in your way when you want to create something. You and the author are both overly concerned about writing code and completely ignoring maintainability. If you write your code once and never touch it again, sure, use plain JS. If you're going to come back in six months month and refactor it or hand it off to a co-worker and expect him to writ…

you mean Python and Ruby like languages are unmaintainable and therefore deprecated? I rarely have a problem with maintainability in JS because of types, but I do have problems with poor constructs, poor readability, dependency issues and so on. It's a typical illusion of TS proponents that code becomes magically maintainable.

JS developers moving to TS should at least do a few weeks of Assembly and C programming to first understand the origin of types. I've spoken too many front-end devs who don't have a clue what a type actually is and at the same time promote TS. It's a godsend we don't need them in scripting languages. Use tooling to catch issues, that's the future, TS is just a whim.

Re: The TypeScript Tax

#116

Post by seanwilson »

ericelliott wrote: post #111
seanwilson wrote: post #108

Earlier quoted context omitted.

> because at least 80% of bugs are not detectable with TypeScript. I give up. You're repeatedly using this figure in this thread in a misleading way to make it sound like what you're saying is more legitimate that just an opinion. The abstract of the study you cite explicitly mentions this is a conservative estimate of effectiveness and ignores bugs detected in private: > Evaluating static type systems against public…

The number they consider conservative is that TypeScript can address up to 15% of public bugs. That's a different number than the proportion of public bugs found ts-undetectable because they're not type errors at all.

There are so many important details about what this figure means and how accurate it is.

Would it make a difference if TypeScript was used before the code was committed? How does the subject domain of the project impact this figure? How do other testing and review approaches impact this number? Are public bugs of certain kinds more likely to be reported for certain projects?

It's highly misleading to quote this figure in such a simplistic manner without caveats.

Re: The TypeScript Tax

#117

Post by ng12 »

z3t4 wrote: post #114
ng12 wrote: post #109

Earlier quoted context omitted.

Yes, and TypeScript is an incredibly powerful tool to make that process easier.

It's like using a bandage to prevent an injury. Yes it's good to have, but it doesn't prevent anyone from writing unmanageable code. Contrary it can make it even easier to write unmaintainable code.

You can say that about literally any technology. Nobody's claiming TypeScript will fix all your problems and discover all the secrets of the universe: it's just a useful tool that well outweighs the overhead it adds.

Re: The TypeScript Tax

#118

Post by pietrofxq »

SiVal wrote: post #112
ericelliott wrote: post #74

Earlier quoted context omitted.

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.

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/enforce…

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

Re: The TypeScript Tax

#119

Post by robocat »

qwer wrote: post #54
steadicat wrote: post #36

Earlier quoted context omitted.

Yes. As a matter of fact, I'm currently working on a large JS codebase that is a decade old. We switched over all the code to TypeScript in one go, and we are gradually fixing the type errors over time. VSCode does an excellent job of showing you type annotations and type errors inline, so the typing is very useful even if you have thousands of errors elsewhere in the project and never even run the type checker globa…

I just finished something similar: http://caines.ca/blog/2018/12/11/a-javascript-to-typescript-... We opted to keep it strict (no implicit `any`) through the entire transition but only apply it to ts files, so we are indeed completely free of type errors now. We only have 50 cases of (explicit) `any` in 85K+ LOC and they're in type def files. Let me be the first person you've met to doubt the value of the type system…

So how many errors were uncovered, and how serious could they have been?

Re: The TypeScript Tax

#120

Post by qwer »

robocat wrote: post #119
qwer wrote: post #54

Earlier quoted context omitted.

I just finished something similar: http://caines.ca/blog/2018/12/11/a-javascript-to-typescript-... We opted to keep it strict (no implicit `any`) through the entire transition but only apply it to ts files, so we are indeed completely free of type errors now. We only have 50 cases of (explicit) `any` in 85K+ LOC and they're in type def files. Let me be the first person you've met to doubt the value of the type system…

So how many errors were uncovered, and how serious could they have been?

It's in the blog post, but more were created by the transition than removed. There were less than 10 issues found and none were anything that users were concerned about.
Post reply on HN