4 ms·

> I've found that the kinds of errors that static typing guards against are often things that would have been trivial to debug and fix in the first place (mostl

by koolba 7y ago

> I've found that the kinds of errors that static typing guards against are often things that would have been trivial to debug and fix in the first place (mostly things like typos). Sure but unless you have coverage of all error cases, it’s nice to have that check at build time vs some untested corner case in production. > Given that you have a good system for monitoring errors in production ... Runtime errors are a totally different beast. > ... and a low friction deploy process so you can quickly and easily fix errors when you discover them, I feel these kinds of errors are honestly not worth guarding against in most contexts outside of those where getting everything perfectly right the first time is a hard requirement (health, fintech, other safety-critical industries, etc). Of course, most companies lack either or both of these ( a good system for monitoring errors in production and a low friction deploy process), so they use static typing as a clutch to try to reduce the chance of errors making it into prod simply because they know they'd be slow to fix/detect those errors. That's a poor reason to choose static typing IMO, but I think that's by far the most common reason. Fixing things earlier is cost effective regardless of your deploy speed. Sure it’s worth more the longer the cycle, but not having to run unit tests because the compiler knows “foo” is not “fo0” saves time as well.

lewisl9029 7y ago
That's totally fair. I'm not saying detecting errors earlier through static typing has no value of course. Just that there is a spectrum of value a team can derive from static typing that scales based on the length of their deploy and error detection cycle, and at the lower ends of that scale it's not always clear that static typing provides enough of value to justify its costs. And that if a team doesn't already have them, investing to minimize the deployment and error detection cycle is often much more valuable than investing in static typing because it's an effective tool for both dealing with runtime errors as well as errors that could have been statically determined.
- hderms 7y ago
  I've worked in a number of languages and fwiw I've never written such error-free code as I have in Scala when embracing the type system (to a reasonable degree) and embracing immutability/fp patterns. We write only the tests that truly matter, something I've never felt is possible in a dynamic language as I personally feel you need lots of tests which are more or less provided for free by the type checker.
- BigJono 7y ago
  One thing nobody likes to mention much is that the value of a type system also scales pretty heavily with the quality (or lack thereof) of developers using it. For a small team full of talented engineers (e.g. a startup) it's not unreasonable at all to just... not make typing errors. I've put 5+ large apps into production in the last decade and could probably count on one hand the number of times I've really struggled with something type related. There's certain anti-patterns that make up the majority of type-related problems in JS. Things like inconsistently mix 'n matching falsey types, adding or removing properties from objects in unpredictable ways, or leaking stringified numbers and bools everywhere. Other classes of type problems can be solved in dynamic languages by structuring code in more self-documenting ways and properly augmenting any remaining ambiguity with comments. If your team is naturally coding in a way that respects the dynamic typing of the language then your benefits from TS are going to be much more marginal, and that needs to be taken into account when comparing the costs and benefits of it. My guess is that we'll see a harder split in the JS community in the next few years. Most people are going to drift towards only taking on TS or JS roles in much the same way most JS programmers wouldn't take a lisp or C# job at the moment.
lenkite 7y ago
I have found the main advantage of static typing being easy, convenient refactoring. I never get my design or code to be just "right" the first time. I get the naming wrong, the functions too big, the design a bit skewed. I need to do a couple of passes, refactoring to get it in a tight shape. And statically typed languages give you tools to refactor with confidence. This is one of the advantages of typescript over a language like clojurescript.

by koolba 7y ago

lewisl9029 7y ago

That's totally fair. I'm not saying detecting errors earlier through static typing has no value of course. Just that there is a spectrum of value a team can derive from static typing that scales based on the length of their deploy and error detection cycle, and at the lower ends of that scale it's not always clear that static typing provides enough of value to justify its costs. And that if a team doesn't already have them, investing to minimize the deployment and error detection cycle is often much more valuable than investing in static typing because it's an effective tool for both dealing with runtime errors as well as errors that could have been statically determined.

hderms 7y ago
I've worked in a number of languages and fwiw I've never written such error-free code as I have in Scala when embracing the type system (to a reasonable degree) and embracing immutability/fp patterns. We write only the tests that truly matter, something I've never felt is possible in a dynamic language as I personally feel you need lots of tests which are more or less provided for free by the type checker.
BigJono 7y ago
One thing nobody likes to mention much is that the value of a type system also scales pretty heavily with the quality (or lack thereof) of developers using it. For a small team full of talented engineers (e.g. a startup) it's not unreasonable at all to just... not make typing errors. I've put 5+ large apps into production in the last decade and could probably count on one hand the number of times I've really struggled with something type related. There's certain anti-patterns that make up the majority of type-related problems in JS. Things like inconsistently mix 'n matching falsey types, adding or removing properties from objects in unpredictable ways, or leaking stringified numbers and bools everywhere. Other classes of type problems can be solved in dynamic languages by structuring code in more self-documenting ways and properly augmenting any remaining ambiguity with comments. If your team is naturally coding in a way that respects the dynamic typing of the language then your benefits from TS are going to be much more marginal, and that needs to be taken into account when comparing the costs and benefits of it. My guess is that we'll see a harder split in the JS community in the next few years. Most people are going to drift towards only taking on TS or JS roles in much the same way most JS programmers wouldn't take a lisp or C# job at the moment.

lenkite 7y ago

I have found the main advantage of static typing being easy, convenient refactoring. I never get my design or code to be just "right" the first time. I get the naming wrong, the functions too big, the design a bit skewed. I need to do a couple of passes, refactoring to get it in a tight shape. And statically typed languages give you tools to refactor with confidence. This is one of the advantages of typescript over a language like clojurescript.