3 ms·

It's not doing what I expect. Oh? Change the spec It's not doing what I expect. Oh? Change the code How is that different from now?

htkibar 4y ago
Allows competing implementations and saves TS from MSFT
rk06 4y ago
Right now: 1.It's not doing what I expect. 2.Is it intentional behavior or a bug? 3. Let's ask on github/reddit etc With Special: 1. It is not doing what I expect 2. Is this a spec issue or code issue? 3. Let's check spec. 4a. "Working as specified". Shit. Hope spec improves in future versions 4b. It is not working as spec says. Let's file a bug on tsc. And that is the difference.
- steveklabnik 4y ago
  The real rub is in step 4: it is not always easy to determine what the spec means. And then you're basically back to "let's ask on github/reddit etc."
  - yencabulator 4y ago
    Just because the comprehensiveness of something is on a spectrum is not a reason to just not bother and have none at all. Also, when done well a spec is a great way to learn & understand the language too. http://golang.org/ref/spec http://golang.org/ref/spec is so much more usable than Typescript's docs.
    - steveklabnik 4y ago
      I agree that specifications are useful. I also think they're often presented as a panacea. It is important to acknowledge that they're a tool, with pros and cons, like any tool. The existence of a specification does not immediately mean that any and all ambiguities are resolved.
- tshaddox 4y ago
  Still doesn’t seem like much a difference. If you run into 4a you still file an issue somewhere.
randomdata 4y ago
If an implementation isn't doing what you expect, is it just an issue with that single implementation? A problem with all implementations? A problem with what you expect? If another implementation does do what you expect is it correct or just lucky? A spec resolves such discrepancies. Indeed, the spec may be where the problem is, but once the spec is corrected then implementations know what they must do. Absent of a spec, who knows?

htkibar 4y ago

Allows competing implementations and saves TS from MSFT

rk06 4y ago

Right now: 1.It's not doing what I expect. 2.Is it intentional behavior or a bug? 3. Let's ask on github/reddit etc With Special: 1. It is not doing what I expect 2. Is this a spec issue or code issue? 3. Let's check spec. 4a. "Working as specified". Shit. Hope spec improves in future versions 4b. It is not working as spec says. Let's file a bug on tsc. And that is the difference.

steveklabnik 4y ago
The real rub is in step 4: it is not always easy to determine what the spec means. And then you're basically back to "let's ask on github/reddit etc."
- yencabulator 4y ago
  Just because the comprehensiveness of something is on a spectrum is not a reason to just not bother and have none at all. Also, when done well a spec is a great way to learn & understand the language too. http://golang.org/ref/spec http://golang.org/ref/spec is so much more usable than Typescript's docs.
  - steveklabnik 4y ago
    I agree that specifications are useful. I also think they're often presented as a panacea. It is important to acknowledge that they're a tool, with pros and cons, like any tool. The existence of a specification does not immediately mean that any and all ambiguities are resolved.
tshaddox 4y ago
Still doesn’t seem like much a difference. If you run into 4a you still file an issue somewhere.

randomdata 4y ago

If an implementation isn't doing what you expect, is it just an issue with that single implementation? A problem with all implementations? A problem with what you expect? If another implementation does do what you expect is it correct or just lucky? A spec resolves such discrepancies. Indeed, the spec may be where the problem is, but once the spec is corrected then implementations know what they must do. Absent of a spec, who knows?