3 ms·
Foregoing types isn't like other escape hatches. Sometimes you'll get odd, hard-to-understand errors from the typescript compiler. On my team, we just use Babel
by JMTQp8lwXL 7y ago
Foregoing types isn't like other escape hatches. Sometimes you'll get odd, hard-to-understand errors from the typescript compiler. On my team, we just use Babel, so we can write TypeScript (and get the benefits of types) without have 100% statically-correct code. Getting from 99% to 100% statically correct is time spent detracting from other more valuable contributions to the business, that don't have a meaningful impact on code quality. Diminishing returns.
- tluyben2 7y agoThe OP mentioned this in the context of ‘why not a fully statically typed language’, aka a language that, unlike typescript, does not return hard-to-understand errors; given such a language, what is an example that falls in that 99-100% 1%? I do not know of such an example and I am curious.
- Aeolun 7y agoOne example is that TS does not enjoy you going from string enum keys to an actually typed enum, but you can fake it by casting to ‘any’ first and then to the new type.
- tluyben2 7y agoSorry, but that was not the question; the question was about examples on a statically typed language like Java (or Kotlin, C# etc), which is what the OP mentioned. Statically typed languages do not 'enjoy' going from strings to enums, which is excellent news by the way, but you can convert them Enum.TryParse() to handle them properly. I cannot really see how it is 'more work' to do that; the 'any' solution seems not much easier compared to C# TryParse or even the TS one; var color : Color = Color[green as keyof typeof Color];
- deleted 7y ago[deleted]