4 ms·

I find it interesting that people in this thread seem to have absolute certainty that "types good" is true, while to me those two words together are largely non

I find it interesting that people in this thread seem to have absolute certainty that "types good" is true, while to me those two words together are largely non-sensical, just like "bytes good" wouldn't make much sense to debate.

prewett 3y ago
After you repeatedly waste a bunch of time debugging things that static typing would have caught on the first compile, and you start developing a "types good" attitude. If you just do simple React development, you might not ever run into the problem. But once your programs get to a couple thousand lines, you start occasionally forgetting what your function takes and passing in the wrong things, which then get passed around for a while and throw an exception long after the problem happened. This results in very unfun print-debugging, particularly in a recursive descent parser or an algorithm that processes a lot of data.
- leptons 3y ago
  >But once your programs get to a couple thousand lines, you start occasionally forgetting what your function takes and passing in the wrong things, which then get passed around for a while and throw an exception long after the problem happened. I've been writing code for 40 years, I can't estimate how many loc I've written, but likely over a million. One of my personal projects is currently over 65k loc vanilla js, and I never once had a problem with not knowing what type a function took. If you're so bad at naming things and knowing what a function does, I guess maybe types can help you. But not everyone needs it.
  - optymizer 3y ago
    I'll take the time to reply to both of you, because you seem to have opposing views. I think such a debate is largely unproductive. Like anything else, types have value (ha) and successfully capitalizing on that value depends on the context of the project, which includes things like developer experience, tooling, project complexity, requirements, deadlines etc. The only productive outcome of these debates is that each developer gets to slowly and frustratingly build a list of pros and cons as they go through the arguments presented by either side debating this topic. In addition, developers who completely disregard either the cons or the pros are necessarily making subjective decisions with incomplete data, and the project gets to pay the price. Just because the developer is personally OK with all of their projects paying that price, doesn't mean it's the best decision for a project. My experience has been that when starting out, projects get the most value out of not having types, and as they grow in scope and size, and the cons of not having types start creeping up, that's the point when gradually transitioning the code to being strongly typed allows the project to maintain its velocity _and_ quality.

prewett 3y ago

After you repeatedly waste a bunch of time debugging things that static typing would have caught on the first compile, and you start developing a "types good" attitude. If you just do simple React development, you might not ever run into the problem. But once your programs get to a couple thousand lines, you start occasionally forgetting what your function takes and passing in the wrong things, which then get passed around for a while and throw an exception long after the problem happened. This results in very unfun print-debugging, particularly in a recursive descent parser or an algorithm that processes a lot of data.

leptons 3y ago
>But once your programs get to a couple thousand lines, you start occasionally forgetting what your function takes and passing in the wrong things, which then get passed around for a while and throw an exception long after the problem happened. I've been writing code for 40 years, I can't estimate how many loc I've written, but likely over a million. One of my personal projects is currently over 65k loc vanilla js, and I never once had a problem with not knowing what type a function took. If you're so bad at naming things and knowing what a function does, I guess maybe types can help you. But not everyone needs it.
- optymizer 3y ago
  I'll take the time to reply to both of you, because you seem to have opposing views. I think such a debate is largely unproductive. Like anything else, types have value (ha) and successfully capitalizing on that value depends on the context of the project, which includes things like developer experience, tooling, project complexity, requirements, deadlines etc. The only productive outcome of these debates is that each developer gets to slowly and frustratingly build a list of pros and cons as they go through the arguments presented by either side debating this topic. In addition, developers who completely disregard either the cons or the pros are necessarily making subjective decisions with incomplete data, and the project gets to pay the price. Just because the developer is personally OK with all of their projects paying that price, doesn't mean it's the best decision for a project. My experience has been that when starting out, projects get the most value out of not having types, and as they grow in scope and size, and the cons of not having types start creeping up, that's the point when gradually transitioning the code to being strongly typed allows the project to maintain its velocity _and_ quality.