6 ms·

Do you write a lot of library code? I'm genuinely wondering in what kind of environment you would get "marginal upside" from having a good type system.

by ht85 5y ago

riskable 5y ago
I've been coding JavaScript for many, many years. I've never encountered a situation where the lack of typing bit me in the ass. Not even once! Having said that, it might be because when I'm writing JavaScript it's just me. Normally I'm the sole developer. So of course I know my own stuff! I'm not going to experience an error passing the wrong type to a function because I literally wrote all the functions myself. I even have enormous libraries of JS code that I use in my personal and work projects where I wrote everything. This developer is probably in the same sort of situation. Type errors are the kind of thing you run into when you're working with large codebases that were written by lots of different people. It's not the type of thing you experience with your own code. I've also written loads of Python and never experienced an error where the wrong type gets passed to a function (even working in a team). For years I couldn't even fathom how static typing would be a benefit other than maybe it can speed things up by giving a compiler/interpreter the ability to optimize things. Then at work--after nearly 20 years of Python--we finally had an issue where the wrong type was passed (float was inadvertently rounded because the function was made for integers and it wasn't obvious). It was caught before the code was sent to production (and it wouldn't have been a huge deal anyway) and I finally had a real-world situation where type annotations would've prevented an error. It's just not something that happens very often. It's the type of thing that creeps up on you for sure but it's not a common, every day occurrence. Type-related bugs are really super obscure. They're far, far rarer than type-obsessed developers make them out to be.
- Turing_Machine 5y ago
  I've often speculated that strong typing only seems like a win to the kind of developer who makes a lot of type errors, and a waste of time to those who don't (which doesn't mean they don't make other errors, of course).
  - Aldo_MX 5y ago
    Or to the kind of developer that works in a big team for a big project.
  - markstos 5y ago
    Even developers who "don't make type errors" have to deal with bad and unexpected data, which may be in a different type. If you don't validate that all untrusted data is off the appropriate type, security vulns or "garbage in - garbage out" bugs can result. Then if you do manually validate the types of untrusted data, then you have to wonder of having built-in type support might be faster. "Bad data" doesn't just come from the outside world. As teams start to use shared libraries written by other people, it's also valuable adds guards to ensure that shared functions are being called with the expected types. My own experience is that it doesn't feel like type-related bugs come up often on my team, but when they do the problems they cause can be bad enough to make us wish more of our code had been ported to TypeScript. Classic example: a CSV parser parsed numbers as strings because a particular spreadsheet quoted the number column. Result: "2"+"2" = "22"
  - rattlesnakedave 5y ago
    bringing in tooling to eliminate an entire class of potential errors sounds sounds like an easy decision to me.
    - Turing_Machine 5y ago
      Not if the errors are rare and the "tooling" slows down development.
      - frosted-flakes 5y ago
        Why do you think it would slow down development? Serious question.
        scns 5y ago
        I was shocked how slow tsc is. Got spoiled by using ReasonML before.
- TN1ck 5y ago
  > I've never encountered a situation where the lack of typing bit me in the ass Quite the claim! For me the moment I never want to look back to is to refactor a substantial part of the architecture of a JS app with more than 20k lines of code (And I did write most of it myself). If you don't do large scale refactorings or work mostly on smaller apps, then indeed, types won't be much of an issue. But you should become aware about how often you see "undefined is not an object" and similar, that's a type error that is almost gone when using TypeScript.
- Aldo_MX 5y ago
  > I've never encountered a situation where the lack of typing bit me in the ass. Not even once! Maybe you just see the "cannot find property of undefined" type of errors as usual business, but this is the #1 kind of error I see in the logs of big applications, and TypeScript really helps to mitigate them.
- slewis 5y ago
  Refactoring is much easier in a well typed codebase. When refactoring is easier, it happens more often, which means code quality and readability are higher, which reduces the likelihood of every other kind of error.
- discreteevent 5y ago
  Agreed on both counts. For me types are not very useful for catching errors. What they are extremely useful for is documentation and navigation of code. Primarily other people's code of course but also for my own code once a certain amount of time has passed.
- jakelazaroff 5y ago
  It’s never “just you”, though: it’s present you and past you. When I come back to code I wrote months or years ago, static types are super helpful as I try to remember what the heck I was doing. They’re at least as valuable for documentation as they are for catching errors.
- matthewmacleod 5y ago
  I've never encountered a situation where the lack of typing bit me in the ass. Not even once! You absolutely have. At some point in your career, you've accidentally got the arguments to a function in the wrong order and had to debug what was happening. Or ended up with a `null` where you didn't expect it. Or used an invalid value for a string enumeration, made an inobvious typo in a field name of an options object, accidentally added brackets and called a function when you meant to pass a reference to it, failed to deal with the return type of a promise, or any number of other examples of mistakes that everybody makes all of the time. These are all examples of common errors that can be caught by a type checker. It's totally valid to debate whether the cost of a type system is worth paying in the context of different environments, but if you're starting from the not-really-credible position of "I have never made a type error, ever", then it suggests that you're working with a set of faulty assumptions about what they offer. (For my own part, as a Javascript user of some 20+ years now, picking up TypeScript has been the best boost to productivity and code quality I've had in my career. It's got to the point that I'd just point-blank refuse to work with a Javascript codebase now, because it's not worth it.)
- sanitycheck 5y ago
  I've got (too many) years of JS experience too, and I started a project in TS last November to see what the fuss is all about. I have to say I'm a convert. Not so much because it's catching a ton of errors for me, more that it brings such a massive improvement in IDE autocomplete behaviour. TypeScript in VS Code starts to feel almost like C# in 'real' visual studio. (The errors it does catch in my code are usually potential null references which would probably have been fine, but I'm sure it's avoided a few bugs.) The most interesting thing for me is that it allows me to feel safe doing things I would avoid in plain JS, like using literal union types (which would be magic numbers/strings without the typing). I still write JS for small stuff, but when you're next starting a new project that'll go over a few thousand lines of code I definitely recommend giving it a try.
  - claytongulick 5y ago
    Have you tried type annotations in jsdoc? Inline /* @type */ statements and jsdoc type declarations coupled with .d.ts files for complex types achieves the same thing for me without the extra compilation step.
    - LAC-Tech 5y ago
      Yeah that's what I do as well. I actually find TS uglier now. It ends up being full of really long lines like: const myFunction(a: Long<TypeName>, b: Another<LongType>): FooBar
- pier25 5y ago
  This reflects my experience when working alone, but when working on a team the experience is drastically different.
- pwdisswordfish9 5y ago
  > I've been coding JavaScript for many, many years. I've never encountered a situation where the lack of typing bit me in the ass. Not even once! Okay, well, here's an example of it leading to a CVE: https://www.mozilla.org/en-US/security/advisories/mfsa2012-72/ https://www.mozilla.org/en-US/security/advisories/mfsa2012-7... The way-and-how of it is that the then-new devtools team working on the then-new JS console lost track of what objects they were passing into a polymorphic function, which resulted in untrusted, content-supplied objects being treated the same as DOM nodes that were supposed to originate from within the JS console implementation itself (for its UI), which resulted in browser-level privileges being given to content authors of ordinary web pages.
- danny_taco 5y ago
  > Having said that, it might be because when I'm writing JavaScript it's just me. Well, you don't need types because you only look at your own code. The advantage of having my IDE tell me what to expect when I'm refactoring a piece of code someone else wrote is a few orders of magnitude more useful and informative than having to jump through various functions and files to understand what's happening. Years of writing code do not equate to proficiency and expertise. You may have been writing code for many years but I would go so far as to assume that you experience is actually very limited.
- deleted 5y ago
  [deleted]

Do you write a lot of library code? I'm genuinely wondering in what kind of environment you would get "marginal upside" from having a good type system.

by ht85 5y ago

Do you write a lot of library code? I'm genuinely wondering in what kind of environment you would get "marginal upside" from having a good type system.

riskable 5y ago

I've been coding JavaScript for many, many years. I've never encountered a situation where the lack of typing bit me in the ass. Not even once! Having said that, it might be because when I'm writing JavaScript it's just me. Normally I'm the sole developer. So of course I know my own stuff! I'm not going to experience an error passing the wrong type to a function because I literally wrote all the functions myself. I even have enormous libraries of JS code that I use in my personal and work projects where I wrote everything. This developer is probably in the same sort of situation. Type errors are the kind of thing you run into when you're working with large codebases that were written by lots of different people. It's not the type of thing you experience with your own code. I've also written loads of Python and never experienced an error where the wrong type gets passed to a function (even working in a team). For years I couldn't even fathom how static typing would be a benefit other than maybe it can speed things up by giving a compiler/interpreter the ability to optimize things. Then at work--after nearly 20 years of Python--we finally had an issue where the wrong type was passed (float was inadvertently rounded because the function was made for integers and it wasn't obvious). It was caught before the code was sent to production (and it wouldn't have been a huge deal anyway) and I finally had a real-world situation where type annotations would've prevented an error. It's just not something that happens very often. It's the type of thing that creeps up on you for sure but it's not a common, every day occurrence. Type-related bugs are really super obscure. They're far, far rarer than type-obsessed developers make them out to be.

Turing_Machine 5y ago
I've often speculated that strong typing only seems like a win to the kind of developer who makes a lot of type errors, and a waste of time to those who don't (which doesn't mean they don't make other errors, of course).
- Aldo_MX 5y ago
  Or to the kind of developer that works in a big team for a big project.
- markstos 5y ago
  Even developers who "don't make type errors" have to deal with bad and unexpected data, which may be in a different type. If you don't validate that all untrusted data is off the appropriate type, security vulns or "garbage in - garbage out" bugs can result. Then if you do manually validate the types of untrusted data, then you have to wonder of having built-in type support might be faster. "Bad data" doesn't just come from the outside world. As teams start to use shared libraries written by other people, it's also valuable adds guards to ensure that shared functions are being called with the expected types. My own experience is that it doesn't feel like type-related bugs come up often on my team, but when they do the problems they cause can be bad enough to make us wish more of our code had been ported to TypeScript. Classic example: a CSV parser parsed numbers as strings because a particular spreadsheet quoted the number column. Result: "2"+"2" = "22"
- rattlesnakedave 5y ago
  bringing in tooling to eliminate an entire class of potential errors sounds sounds like an easy decision to me.
  - Turing_Machine 5y ago
    Not if the errors are rare and the "tooling" slows down development.
    - frosted-flakes 5y ago
      Why do you think it would slow down development? Serious question.
      - scns 5y ago
        I was shocked how slow tsc is. Got spoiled by using ReasonML before.
TN1ck 5y ago
> I've never encountered a situation where the lack of typing bit me in the ass Quite the claim! For me the moment I never want to look back to is to refactor a substantial part of the architecture of a JS app with more than 20k lines of code (And I did write most of it myself). If you don't do large scale refactorings or work mostly on smaller apps, then indeed, types won't be much of an issue. But you should become aware about how often you see "undefined is not an object" and similar, that's a type error that is almost gone when using TypeScript.
Aldo_MX 5y ago
> I've never encountered a situation where the lack of typing bit me in the ass. Not even once! Maybe you just see the "cannot find property of undefined" type of errors as usual business, but this is the #1 kind of error I see in the logs of big applications, and TypeScript really helps to mitigate them.
slewis 5y ago
Refactoring is much easier in a well typed codebase. When refactoring is easier, it happens more often, which means code quality and readability are higher, which reduces the likelihood of every other kind of error.
discreteevent 5y ago
Agreed on both counts. For me types are not very useful for catching errors. What they are extremely useful for is documentation and navigation of code. Primarily other people's code of course but also for my own code once a certain amount of time has passed.
jakelazaroff 5y ago
It’s never “just you”, though: it’s present you and past you. When I come back to code I wrote months or years ago, static types are super helpful as I try to remember what the heck I was doing. They’re at least as valuable for documentation as they are for catching errors.
matthewmacleod 5y ago
I've never encountered a situation where the lack of typing bit me in the ass. Not even once! You absolutely have. At some point in your career, you've accidentally got the arguments to a function in the wrong order and had to debug what was happening. Or ended up with a `null` where you didn't expect it. Or used an invalid value for a string enumeration, made an inobvious typo in a field name of an options object, accidentally added brackets and called a function when you meant to pass a reference to it, failed to deal with the return type of a promise, or any number of other examples of mistakes that everybody makes all of the time. These are all examples of common errors that can be caught by a type checker. It's totally valid to debate whether the cost of a type system is worth paying in the context of different environments, but if you're starting from the not-really-credible position of "I have never made a type error, ever", then it suggests that you're working with a set of faulty assumptions about what they offer. (For my own part, as a Javascript user of some 20+ years now, picking up TypeScript has been the best boost to productivity and code quality I've had in my career. It's got to the point that I'd just point-blank refuse to work with a Javascript codebase now, because it's not worth it.)
sanitycheck 5y ago
I've got (too many) years of JS experience too, and I started a project in TS last November to see what the fuss is all about. I have to say I'm a convert. Not so much because it's catching a ton of errors for me, more that it brings such a massive improvement in IDE autocomplete behaviour. TypeScript in VS Code starts to feel almost like C# in 'real' visual studio. (The errors it does catch in my code are usually potential null references which would probably have been fine, but I'm sure it's avoided a few bugs.) The most interesting thing for me is that it allows me to feel safe doing things I would avoid in plain JS, like using literal union types (which would be magic numbers/strings without the typing). I still write JS for small stuff, but when you're next starting a new project that'll go over a few thousand lines of code I definitely recommend giving it a try.
- claytongulick 5y ago
  Have you tried type annotations in jsdoc? Inline /* @type */ statements and jsdoc type declarations coupled with .d.ts files for complex types achieves the same thing for me without the extra compilation step.
  - LAC-Tech 5y ago
    Yeah that's what I do as well. I actually find TS uglier now. It ends up being full of really long lines like: const myFunction(a: Long<TypeName>, b: Another<LongType>): FooBar
pier25 5y ago
This reflects my experience when working alone, but when working on a team the experience is drastically different.
pwdisswordfish9 5y ago
> I've been coding JavaScript for many, many years. I've never encountered a situation where the lack of typing bit me in the ass. Not even once! Okay, well, here's an example of it leading to a CVE: https://www.mozilla.org/en-US/security/advisories/mfsa2012-72/ https://www.mozilla.org/en-US/security/advisories/mfsa2012-7... The way-and-how of it is that the then-new devtools team working on the then-new JS console lost track of what objects they were passing into a polymorphic function, which resulted in untrusted, content-supplied objects being treated the same as DOM nodes that were supposed to originate from within the JS console implementation itself (for its UI), which resulted in browser-level privileges being given to content authors of ordinary web pages.
danny_taco 5y ago
> Having said that, it might be because when I'm writing JavaScript it's just me. Well, you don't need types because you only look at your own code. The advantage of having my IDE tell me what to expect when I'm refactoring a piece of code someone else wrote is a few orders of magnitude more useful and informative than having to jump through various functions and files to understand what's happening. Years of writing code do not equate to proficiency and expertise. You may have been writing code for many years but I would go so far as to assume that you experience is actually very limited.
deleted 5y ago
[deleted]