4 ms·

But you can use them as evidence that tsc is not working as it "should". Then go ahead and fix tsc Or spec or both as needed. Without the specs, there is no wa

by rk06 4y ago

But you can use them as evidence that tsc is not working as it "should". Then go ahead and fix tsc Or spec or both as needed. Without the specs, there is no way to tell if tac is behaving as developers intended it

gfxgirl 4y ago
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?
kristiandupont 4y ago
And such a spec can be 1) a reference implementation, 2) written in natural language, or 3) written as formal semantics #1 is the same as the current situation. With #2, you might get a bit closer but natural language has many ambiguities and idiosyncrasies that can render it useless in various situations. You can try to define formal semantics, but that is not only hard to create, it's also hard to translate into an implementation, adding significant overhead in both parts of the process. And there can still be bugs, and there can still be edge cases with undefined behavior.
Kuinox 4y ago
Code, called implementation here, is a specification written in a certain grammar that is executed. You want 'evidence' tsc is not working as it should, by writting a duplicated less specifying specification that would sometimes conflict with the typescript one. It make me remember the people that wanted to specify everything and generate implementation from it: that called a programming language.
- rk06 4y ago
  Code is meant for machine. Specification is meant for compiler author. Writing one of them is easier than otht
  - randomdata 4y ago
    They are not mutually exclusive. Code identifies a class of language. Specification identifies something that is conveyed through language. Specification can be provided in code. In fact, while poorly named, what we call testing is actually specification. A test suite specifies for software authors what a program is intended to do and how it is intended to be used. Of course, as a nice side bonus, because the specification is delivered in code the documentation can be validated for truthfulness against an implementation by machine.

by rk06 4y ago

gfxgirl 4y ago

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?

kristiandupont 4y ago

And such a spec can be 1) a reference implementation, 2) written in natural language, or 3) written as formal semantics #1 is the same as the current situation. With #2, you might get a bit closer but natural language has many ambiguities and idiosyncrasies that can render it useless in various situations. You can try to define formal semantics, but that is not only hard to create, it's also hard to translate into an implementation, adding significant overhead in both parts of the process. And there can still be bugs, and there can still be edge cases with undefined behavior.

Kuinox 4y ago

Code, called implementation here, is a specification written in a certain grammar that is executed. You want 'evidence' tsc is not working as it should, by writting a duplicated less specifying specification that would sometimes conflict with the typescript one. It make me remember the people that wanted to specify everything and generate implementation from it: that called a programming language.

rk06 4y ago
Code is meant for machine. Specification is meant for compiler author. Writing one of them is easier than otht
- randomdata 4y ago
  They are not mutually exclusive. Code identifies a class of language. Specification identifies something that is conveyed through language. Specification can be provided in code. In fact, while poorly named, what we call testing is actually specification. A test suite specifies for software authors what a program is intended to do and how it is intended to be used. Of course, as a nice side bonus, because the specification is delivered in code the documentation can be validated for truthfulness against an implementation by machine.