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

71–80 of 120 posts

Re: The TypeScript Tax

#71

Post by kevinsd »

Put aside the scoring and conclusion parts, the author has a couple interesting observations that resonate with me:

> ... but conscientious developers will be interested in doing things right. They’ll spend hours Googling for examples, trying to learn how to type things that TypeScript simply can’t type properly.

> ... if you only need to hire one or two developers, using TypeScript may make your opening more attractive to almost half the candidate pool.

On the other hand, it seems that the author worked on a few medium-size projects and then moved on:

> All projects for which impact was judged were >50k LOC with several collaborators working over several months.

So I wonder if he was able to evaluate the impacts from a longer term perspective, which shall include refactoring experience, iteration speed, developer morale, etc.

Re: The TypeScript Tax

#72

Post by pgrizzay »

asark wrote: post #14

> Missing Features — HOFs, Composition Uh... I'm pretty sure I've used both in TypeScript projects.

This was the most infuriating part. He either doesn't understand what a hof is, is actively lying, or just hasn't even used typescript long enough to understand this is incorrect.

Re: The TypeScript Tax

#73

Post by ericelliott »

uxp wrote: post #69
seattle_spring wrote: post #23

Earlier quoted context omitted.

> Pages and pages of beautifully worded, perfectly structured arguments about absolutely nothing. I don't know Eric Elliot, but this sentence captures my perception of most "influencers" perfectly.

I've personally been hired to clean up at least two of his codebases after he finds the next shiny object. Much like his prose, they flow beautifully and end up doing very little substantive work. I'd rather someone that knows that their shit stinks for X number of reasons than one that thought theirs was a work of art. My favorite question to ask a mid to senior interviewee is what do they hate or what would they ch…

Hello. Eric Elliott here. Which codebases were those, exactly?

Re: The TypeScript Tax

#74

Post by ericelliott »

asark wrote: post #40
int_19h wrote: post #27

Let me save a few minutes of your time. The author of the article believes that static typing is mostly a waste of time. Consequently, in his point-based model, he assigned that particular feature of the language +0.1 points. "Typing overhead", on the other hand, got -3 points. And then, after adding all the points, he unsurprisingly concluded that the overall score is negative. If you agree with the premise that sta…

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

Re: The TypeScript Tax

#75

Post by ericelliott »

cloverich wrote: post #11

I don't think the author adequately addresses the positives of development velocity with Typescript. I find I'm able to read and write code much more quickly with Typescript than without, especially once I am beyond 50-100 loc. I doubt I _ship_ fewer bugs to production, but I certainly catch and fix my own mistakes much more quickly _as I go_, and am able to make more ambitious changes much faster when I have types o…

I get the same benefits from my other tooling. Lint and type inference provide real-time feedback similar to TypeScript, and TDD gives me continuous test feedback every time I hit save. That's the zero point on the ROI scale, and while I admit that well annotated TypeScript code does it a little better, it's not better enough to justify the cost.

Re: The TypeScript Tax

#76

Post by ericelliott »

AgentME wrote: post #53
ng12 wrote: post #39

Earlier quoted context omitted.

Yup. He didn't address the biggest winner for me -- the ease of refactoring code you wrote 6+ months ago without breaking everything.

I'm on a large codebase that transitioned from Javascript to Flow a few years ago (which is very similar to TypeScript, though nowadays I'd recommend TypeScript over it). Before we started using Flow, big refactors were extremely painful. It was practically guaranteed that we'd have to spend a week manually double-checking things, and then spend at least a few days finding and fixing bugs after deploying the refactor…

I have all those benefits already. The zero point includes inference, lint, design review, spec review, code review, and TDD -- and you can't leave those out safely because 80% of bugs are not type errors.

Re: The TypeScript Tax

#77

Post by ericelliott »

kevintb wrote: post #41

I generally wasn't impressed by his work, but learning that Eric Elliot changed his citations to suit his false claims for his article on TDD [1] has made me lose any form of respect for him [1] https://twitter.com/Hillelogram/status/1084991487702691840

I had not seen that before. I will fix the mistake.

Re: The TypeScript Tax

#78

Post by ericelliott »

brianberns wrote: post #51
ng12 wrote: post #10

> Type correctness does not guarantee program correctness. Yeah, obviously. Think about it -- when you write the code you still think about the "types", you're just not writing them down. Typescript's virtues are completely related to developer productivity. Documenting your code with types, better autocompletion, catching silly mistakes before needing to run it in a browser, getting new people up to speed, etc.

Actually, one of the benefits of strong typing (without side effects) is that the correct implementation is sometimes the only one that compiles. For example, if you know that a function takes a generic list and returns an integer, then the list’s length is pretty much the only non-trivial computation it can perform.

I've seen this happen for a handful of functions, but implementation correctness proofs for general applications are far beyond the expressive capabilities of TypeScript.

Re: The TypeScript Tax

#79

Post by ng12 »

ericelliott wrote: post #76
AgentME wrote: post #53

Earlier quoted context omitted.

I'm on a large codebase that transitioned from Javascript to Flow a few years ago (which is very similar to TypeScript, though nowadays I'd recommend TypeScript over it). Before we started using Flow, big refactors were extremely painful. It was practically guaranteed that we'd have to spend a week manually double-checking things, and then spend at least a few days finding and fixing bugs after deploying the refactor…

I have all those benefits already. The zero point includes inference, lint, design review, spec review, code review, and TDD -- and you can't leave those out safely because 80% of bugs are not type errors.

With TypeScript I can make a change and immediately get a list of every single line I need to update. None of those replace that very key functionality.

> and you can't leave those out safely

Who's advocating for the replacement of code review, specs, and tests with TypeScript? TypeScript makes these things better, it doesn't replace them.

Re: The TypeScript Tax

#80

Post by ericelliott »

seanwilson wrote: post #7

> Type safety doesn’t seem to make a big difference. TypeScript proponents frequently talk about the benefits of type safety, but there is little evidence that type safety makes a big difference in production bug density. This is important because code review and TDD make a very big difference (40% — 80% for TDD alone)... > TypeScript is only capable of addressing a theoretical maximum of 15% of “public bugs”, where…

The trouble is most projects are NOT employing the other reviews properly. The study made no effort to determine the quality of the test and review process, and instead assumed that they had been done by virtue of the bugs being merged to the master branch.

The study then finds that about 80% of the bugs they found were not simply ts-undetectable, but not type errors at all. Instead, they're things like the wrong URLs being used (sting errors), wrong branching logic, wrong predicate logic, etc.

That means the maximum effect must be less than 20%, but the authors couldn't detect 20% even knowing exactly what the bug and fix was, down to the line numbers and exact code used to fix the bug.

Even being extremely generous and assuming they could fix 20% of remaining bugs, it's too far down the ladder of exponentially diminishing returns to make much difference at that stage.

Post reply on HN