4 ms·

> it's not the right thing to do 100% of the time. What is an example of this in your experience? I am trying to think of one, but after 25 years of programmin

> it's not the right thing to do 100% of the time. What is an example of this in your experience? I am trying to think of one, but after 25 years of programming, I cannot say I have ever encountered a case where it was worth using ‘an escape hatch’ that did not bite us later on. Maybe it is the type of software/clients I work with, but ‘the trouble’ is not really something I have seem before I think.

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 ago
  The 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 ago
    One 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 ago
      Sorry, 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]
edem 7y ago
The case is when you are lazy and choose to introduce technical debt into your codebase by using the escape hatch.

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 ago
The 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 ago
  One 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 ago
    Sorry, 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]

edem 7y ago

The case is when you are lazy and choose to introduce technical debt into your codebase by using the escape hatch.