Hacker News Reader

HNHacker News

Top New Best Ask Show Jobs

Comment by gfxgirl | Hacker News Reader

Parent Full thread

gfxgirl·

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?

View on HN

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.

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."

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 is so much more usable than Typescript's docs.

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.

Still doesn’t seem like much a difference. If you run into 4a you still file an issue somewhere.

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?

Allows competing implementations and saves TS from MSFT

Reply on news.ycombinator.com