3 ms·

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 de

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.

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.