11 ms·

There's been some discussion regarding what these Javascript devs are calling "The Typescript Tax" ( Presumably the perceived increased cost of development in a

• marcinzm 8y ago
  >What greater 'tax' could you possibly conceive of than a whopping 38% of your development time on an enterprise product being spent debugging problems caused by type inference/coercion? Is there a link where they say they spent 38% of their development time on this? The slide just says 38% of bugs and fixing bugs is not the only way development time is spent and not all bugs are equal in terms of time to debug.
  • macintux 8y ago
    You’re correct, but it’s also true that debugging is often a greater percentage of time/effort than the original coding, so 38% of bugs is nothing to sniff at.
    • shhehebehdh 8y ago
      Although typing bugs are often the simpler type of bugs to fix.
      • Operyl 8y ago
        Until they’re not. I’ve had some codebases where it took 3-4 hours to figure out that some really bizarre issue was really just a type bug. And I don’t consider myself a terrible debugger.
        • shhehebehdh 8y ago
          Obviously. Any distribution will have some exemplars toward the tail.
      • smt88 8y ago
        This is only true if the bug is caught by the runtime checker. Lots of type bugs aren't, especially in languages with type coercion.
      • ajxs 8y ago
        The bigger problem is that "Simple fix" !== "Simple ramifications". Runtime issues caused by missing very simple typing bugs can bring down critical systems in Node. I worked at a company where a payment batching system built ( not by me ) with a MongoDB database failed to work correctly because the aggregation query was checking a field was `null`, without checking if it was there in the first place... No one even noticed for several weeks until someone finally investigated the low volumes. That's a very kind example too, just because they're simple to debug when they pop up doesn't mean that they won't cause massive destruction in prod.
      • root_axis 8y ago
        I don't think that's really true as a general rule. Passing a variable of an unexpected type or nullable could have completely unpredictable behavior depending on what assumptions the code makes about the incoming parameter. It could have no effect or a catastrophic one, there's really no way to know without reading actual code.
      • baroffoos 8y ago
        Not at all. Typing bugs often leave code looking perfectly fine until you discover that one of the variables you expected to be y was actually x. And the only way to find out is to just print out everything
        • jondubois 8y ago
          Can happen with TypeScript too. There is no runtime type checking so if you parsed a JSON object and cast some unknown property `const result = someRemoteObject.someUnknownPropertyWhichIsAString as number`, it doesn't guarantee that the result is actually a number. You still need to do actual schema validation just like with old school JavaScript.
          • baroffoos 8y ago
            Better languages solve this. In haskell you define a datatype for json before you parse it.
      • jondubois 8y ago
        So true and simpler to detect too. The kinds of bugs which TypeScript prevents are those which could have been caught by the simplest of integration tests using the simplest inputs. Every time I rename or change something in TypeScript, I have to change it in so many different places. In JavaScript, changes where much more localized.
  • brlewis 8y ago
    > Is there a link where they say they spent 38% of their development time on this? No there is not. The comment you're replying to has no factual basis for this claim. Nor is there a basis in the article for 'what these Javascript devs are calling "The Typescript Tax"'. In the article there's one comment that refers to such a tax, but the commenter doesn't claim to agree, and every reply disagrees. Nor is there a basis in the article for "Surely Node.js is going to be looked back upon as one of the worst mistakes in the history of 21st century programming." The article says nothing about the total quantity of bugs, bugs per line of code, or other comparable metric. The comment you're replying to seems to have a predetermined agenda tangentially related to the article.
    • ajxs 8y ago
      My apologies, I was commenting very generally regarding attitudes typical of Javascript developers I have encountered in my professional life, rather than addressing the article directly. Also, you're right. 38% of development time is not the same as 38% of bugs, mea culpa, but there is an overall point to my statement about the productivity cost that I believe remains correct regardless.
      • brlewis 8y ago
        You gained more reputation by owning your mistake than you lost by making it.
  • deleted 8y ago
    [deleted]
• jasonkillian 8y ago
  > Surely Node.js is going to be looked back upon as one of the worst mistakes in the history of 21st century programming. Why is that? There were dynamically-typed backend languages long before Node.js became popular. And you now can easily have a TypeScript-based Node.js backend, which gives you the nice benefit of having the exact same language and types for both your backend and frontend. I'm not saying the Node runtime is perfect, but I don't understand why having a runtime that lets you use JS/TS as a backend or local language is quite such a bad thing.
  • regularfry 8y ago
    I have absolutely no way to back this up, but my gut feeling is that the node ecosystem's tendency towards small modules, coupled with a lack of explicit interfaces in the language, increases the number of places where a developer is likely to introduce a type error.
    • austincheney 8y ago
      It is a bad idea to intermingle the problems of dependency management with the concerns of a type system as though these are somehow related concepts. If you are not managing your dependencies sloppy things will follow regardless of the type system in place. There is an unrealistic expectation that JavaScript developers shouldn't have to write code because somebody has already written it for them in an NPM package.
      • regularfry 8y ago
        I don't just mean external dependencies. The culture of "small modules" also means internal modules are vulnerable to this. Edit to add: on further thought, I think it would be a mistake not to look at dependency management and type-safety at the same time. If my external dependency exposes a defined interface, that gives me more information about that dependency which I can use to manage it (replacing it, for instance) than without.
      • scarface74 8y ago
        If I import a Nuget package into my C# code that changed a signature behind my back or even one that correctly versioned the package as “we have breaking changes”, I’ll know at compile time. With an NPM package I won’t know until runtime.
• deleted 8y ago
  [deleted]
• deleted 8y ago
  [deleted]
• josephg 8y ago
  > What greater 'tax' could you possibly conceive of than a whopping 38% I always find it fascinating looking at the number of lines of code which do the same thing in different languages. Foundationdb maintains official bindings in Java, Go, Ruby and Python. The implementations have almost complete feature parity. They're all maintained by the same team, and as far as I can tell they all follow best practices in their respective languages. The sizes (minus comments and blank lines) are[1]: Python: 4053 Ruby: 2397 Go: 3968 Java: 10077 38% seems like a lot but language expressiveness dominates that. If ruby and java code were equally difficult to write, you'd be paying a 320% tax moving from ruby to java for an equivalent program. I'd love to see a "programming language benchmark game" that only allowed idiomatic code and compared languages based on code length. I have no idea what the equivalent size ratio is for javascript and typescript, but having worked with both, I find typescript projects end up bigger. I write more typescript because the type system and the tooling encourages verbose and explicit over terse and clever. (In typescript I end up with more classes, longer function names and fewer polymorphic higher order functions). The typescript tax is real. That said, I believe the defect rate increases by 38% too. Depending on what you're doing the tax might be worth it. [1] Measured from commit 48d84faa3 using tokei "code lines". Includes JNI binding code and makefiles, but not documentation
  • threeseed 8y ago
    Java size has nothing to do with types and everything to do with the language. Look at a file like this: https://github.com/apple/foundationdb/blob/master/bindings/java/src/main/com/apple/foundationdb/Range.java https://github.com/apple/foundationdb/blob/master/bindings/j... You have equals, hashCode, toString which are all uncommon in other languages.
    • josephg 8y ago
      > Java size has nothing to do with types and everything to do with the language. Yes. I'm making two claims. First to disagree with the GP's claim that a 38% difference between languages was 'whopping': > What greater 'tax' could you possibly conceive of than a whopping 38% The fact that the type system isn't entirely to blame is also clear looking at the ruby and python sizes. Ruby and python have very similar type systems, but the ruby code is only about half the size of its python equivalent. My second claim is that if we did the same comparison with javascript and typescript, typescript would be bigger. I don't have any stats for this though - just lots of experience. The type system seems to push code in a bit more of a classical OO direction because there aren't higher kinded types, associated types, or any of that fun stuff. As others have said it'd be fascinating to compare typescript and purescript / elm codebases. I'd expect the haskell-derived languages would come out way ahead on expressiveness. Its constantly surprising to me that we don't have any actual numbers.
• anonytrary 8y ago
  There's a hidden tradeoff. For example, if you have to spend 1000 extra cumulative hours to use types, and you've spent an extra 500 cumulative hours fixing all of the bugs associated with not using types, then, from a business perspective, it would have been worth it to not use types (and vice-versa).
  • cellularmitosis 8y ago
    This completely ignores the fact that bugs which make it into production erode the reputation of the company in the eyes of their customers. Lost reputation is much, much worse than being wasteful with dev hours.
    • scarface74 8y ago
      I use to believe that to always be the case. But then I worked for a company that didn’t really care about quality they just wanted to add features to mark off a checklist in a pursuit to either get more funding or get acquired That can work - see Twitter.
      • cellularmitosis 8y ago
        Right, but when customers are putting up with a crappy product, they are just waiting for a better alternative to come along. That's a huge liability to be sitting on -- just ask MySpace.
        • scarface74 8y ago
          That actually proves my point. The original founder sold to News Corp just as Facebook was taking over in 2009. The strategy was a success depending on where you stand....
          • cellularmitosis 8y ago
            Our difference of opinion hinges on the ambiguity of “success”. Here you use “success” strictly in the sense of making a financial gain, while MySpace’s users would have called it a failure.
• colordrops 8y ago
  Are you implying that dynamically typed programming languages are a mistake?
  • fosk 8y ago
    Like everything else, there are pros and cons. It’s not like dynamic languages are worse or better per-se, but they surely make it harder to scale a team or a codebase 10x the original size without introducing what effectively is some sort of typed system (or strict “typed” conventions that the team agrees upon) in place. Which may be done right, or disastrously wrong. A typed language generally doesn’t leave this step up for interpretation later on, since everybody agrees on it since day one.
    • cellularmitosis 8y ago
      As a newbie to clojure, I’m very curious to see what a large codebase looks and feels like. The clojure attitude seems to be that types come at the cost of reduced code reuse, which I tend to agree with. After a decade spent in strongly-typed OO, it is starting to feel like a bunch of sound and fury which seems to end up eventually just getting in my way. I’m definitely open to new ideas in this area, and am looking forward to taking a deeper dive into clojure this year.
    • jondubois 8y ago
      Alternatively, you can break the project up into modules; each of which are maintained my smaller teams. I think that is a cleaner approach.
  • int_19h 8y ago
    IMO, dynamically typed languages made more sense when type systems in mainstream statically language languages were much more primitive, and that limited what you could do - and it was often verbose when you could. But the kind of type systems your average dev has to deal with improved a lot in their expressiveness since 90s. Type inference is basically mainstream, too. There are still things that cannot be described nicely, but they tend to be a lot more "magic" - the kind of stuff that lets you write code faster, but not necessarily write more readable and understandable code.
• AnaniasAnanas 8y ago
  > debugging problems caused by type inference Type-inference has never been the cause for bugs in any languae.
• GhostVII 8y ago
  I wouldn't be surprised if it is actually faster to develop in statically typed languages once projects reach a certain size. It makes refactoring so much easier, and it's a lot easier to reason about what a functions arguments could be. I've had cases before where the easiest way to tell what a function accepted as an argument was to just run the program and print out the input. If it was statically typed, I know exactly what the arguments are, and can easily see the effects of modifying one of those arguments. With dynamic typing, I spend a lot of time just looking at how a function is used elsewhere in the code to make sure I don't break anything.
• TeMPOraL 8y ago
  "Tax" may indeed be the right word. You pay something up front, and in return you get benefits that tend to outweigh the costs, and which would be even more expensive to pay for directly. I say that as a seasoned dynamic typer, who finds himself wishing frequently that the X3J13 standardized optional typing in Common Lisp a bit more.
• austincheney 8y ago
  > Surely Node.js is going to be looked back upon as one of the worst mistakes in the history of 21st century programming. Why? You did not elaborate on this.
• nathan_f77 8y ago
  I might be wrong, but I think you have misunderstood this, or we've come to wildly different conclusions. My understanding is that they were using a dynamic language without types, and 38% of these bugs would have been prevented if they were using static types. My conclusion is that developers would spend at least 38% less time debugging type issues. This is because code editors (e.g. VS Code) have really good TypeScript support, such as autocomplete, and you get instant feedback if you ever make a mistake. You seem to have arrived at the opposite conclusion, which is that developers would require the same (or more) effort to prevent and fix these bugs while using TypeScript. I think you've missed the fact that most type issues don't take that much effort in the first place. Once you set up the "guard rails" by making a decision about types (or just assigning a value to a variable), writing the rest of the code is pretty effortless. I would take it a step further and say that TypeScript development is actually more productive than plain JavaScript. (Again because of the better autocompletion and instant type checking in my editor.) I make far fewer mistakes, but I also write code faster.
  • Brometheus 8y ago
    This, and also: You don't want to deploy errors to production ;D
• deleted 8y ago
  [deleted]
• drugme 8y ago
  What greater 'tax' could you possibly conceive of than a whopping 38% of your development time on an enterprise product being spent debugging problems caused by type inference/coercion? Y As opposed to 86 percent of all statistics, which are basically made up. (Or presented grossly out of context, which is pretty much just as bad as "made up"). Seriously, it takes a lot more to trigger an assessment of "whopping" significance in my mind than a side-angle photo of some random slide presented with no background context whatsoever. Surely Node.js is going to be looked back upon as one of the worst mistakes in the history of 21st century programming. Wholehearted agreement with you there, at least.