5 ms·

> But there's a problem. Rewriting a library like TypeScript is extremely challenging. First, "absence of [a] specification" for TypeScript's behaviour. Donny's

by Tade0 4y ago

> But there's a problem. Rewriting a library like TypeScript is extremely challenging. First, "absence of [a] specification" for TypeScript's behaviour. Donny's had to infer TypeScript's behaviour mostly test cases alone. IIRC the TypeScirpt leadership is of the position that the implementation is the specification, which is unfortunate, because it means that the bugs in the implementation are necessarily part of the specification as well.

Kuinox 4y ago
Specification are not immune to bugs.
- 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.
- remexre 4y ago
  But at least formal methods tools can be applied directly to the specification, to show properties like "well, if you carve out this subset of TypeScript, you have something you can safely eval()" or "you can never have type errors with this usage of this construct in this way."
  - zokier 4y ago
    > But at least formal methods tools can be applied directly to the specification What makes you think that? For example for C language it has been significant effort to translate the specification to something analyzable by tools
  - brundolf 4y ago
    > "well, if you carve out this subset of TypeScript, you have something you can safely eval()" or "you can never have type errors with this usage of this construct in this way." This kind of certainty is very at odds with TypeScript's design philosophy and the way it (necessarily) works. Because it's overlaid on JavaScript, and JavaScript is wildly dynamic (Proxies, prototype modification, etc), almost nothing is known with absolute certainty. To deal with that, TypeScript makes a lot of "optimistic" assumptions, but holds them lightly (i.e. its assumptions may cause type checks to pass when they shouldn't, but it's not going to lean on them for anything that could really blow up if they're wrong) IMO it strikes a very good balance given the constraints - not criticizing the designers at all - but TypeScript has to be treated differently than other statically typed languages might be, because nearly everything it knows/says is just a "probably"
- namuol 4y ago
  Neither are programs, tests, or type definitions, but these are generally still valuable things to have.
ape4 4y ago
Maybe the first step should be writing down a spec of TypeScript.
- progx 4y ago
  Boring! That is the problem, nobody want to do such boring things.
  - yencabulator 4y ago
    Nobody except Microsoft is able to write a spec for Typescript. Microsoft has already declared that the implementation is it, any spec a random person writes will just be ignored.
  - ansraliant 4y ago
  - epolanski 4y ago
    It's not about boredom, it's simply an implementation derived language as are Haskell or PHP or Python. Having a spec is really valuable only if you intend to target different environments, that's a non-goal for TS it simply transpiles, rather than compiles, into another programming language. It's also bound to follow each new JS feature and change.
    - randomdata 4y ago
      The value of a spec is having something that resolves how to deal with quirks discovered in an implementation. Absent of a spec, any implementation quirks become a part of the language. Which is okay as long as you only ever have one implementation, but when you want to, say, reimplement Typescript in Rust then you have to duplicate all of the quirks that came before, even in cases where nobody has yet realized that the quirk exists. Failure to do so means that your implementation won't be compatible with the canonical implementation. At the other end of the spectrum, the Go project maintains two independent compiler implementations to ensure that the spec is implementable and to see that a single implementation, with all of its quirks, doesn't end up defining the language. That puts a lot of confidence in the spec to guide additional implementations, but, of course, is a lot of added work. Tradeoffs, as always.
miohtama 4y ago
For the sake of being fair for other programming languages, what are the languages with proper specification? C, C++, JavaScript, others?
- randomdata 4y ago
  Go is staunch about its specification. To the point that the Go team maintains two independent compiler implementations to ensure that "features"/bugs in one implementation doesn't end up defining the standard and to ensure that a compiler can be implemented from the spec.
  - tristan957 4y ago
    Is the other compiler you are referring to gcc-go?
  - recov 4y ago
    There's actually 3 now from google afaik - gc - gccgo - gollvm [0] [0] https://go.googlesource.com/gollvm/ https://go.googlesource.com/gollvm/
- munificent 4y ago
  Dart has a complete specification. It tends to lag somewhat behind the most recent features (which are documented in separate language proposals), but we keep it as current as we can. Maintaining a language specification is a lot more work than people realize, and a job that few have the skills to do well.
- xchkr1337 4y ago
  In my opinion the presence of undefined behavior in the C/C++ specification makes it no better than the "specification by implementation" approach
  - spac 4y ago
    without a specification you can never tell with certainty if there's a bug
the_gipsy 4y ago
That's one way to keep tight control.

by Tade0 4y ago

Kuinox 4y ago

Specification are not immune to bugs.

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.
remexre 4y ago
But at least formal methods tools can be applied directly to the specification, to show properties like "well, if you carve out this subset of TypeScript, you have something you can safely eval()" or "you can never have type errors with this usage of this construct in this way."
- zokier 4y ago
  > But at least formal methods tools can be applied directly to the specification What makes you think that? For example for C language it has been significant effort to translate the specification to something analyzable by tools
- brundolf 4y ago
  > "well, if you carve out this subset of TypeScript, you have something you can safely eval()" or "you can never have type errors with this usage of this construct in this way." This kind of certainty is very at odds with TypeScript's design philosophy and the way it (necessarily) works. Because it's overlaid on JavaScript, and JavaScript is wildly dynamic (Proxies, prototype modification, etc), almost nothing is known with absolute certainty. To deal with that, TypeScript makes a lot of "optimistic" assumptions, but holds them lightly (i.e. its assumptions may cause type checks to pass when they shouldn't, but it's not going to lean on them for anything that could really blow up if they're wrong) IMO it strikes a very good balance given the constraints - not criticizing the designers at all - but TypeScript has to be treated differently than other statically typed languages might be, because nearly everything it knows/says is just a "probably"
namuol 4y ago
Neither are programs, tests, or type definitions, but these are generally still valuable things to have.

ape4 4y ago

Maybe the first step should be writing down a spec of TypeScript.

progx 4y ago
Boring! That is the problem, nobody want to do such boring things.
- yencabulator 4y ago
  Nobody except Microsoft is able to write a spec for Typescript. Microsoft has already declared that the implementation is it, any spec a random person writes will just be ignored.
- ansraliant 4y ago
- epolanski 4y ago
  It's not about boredom, it's simply an implementation derived language as are Haskell or PHP or Python. Having a spec is really valuable only if you intend to target different environments, that's a non-goal for TS it simply transpiles, rather than compiles, into another programming language. It's also bound to follow each new JS feature and change.
  - randomdata 4y ago
    The value of a spec is having something that resolves how to deal with quirks discovered in an implementation. Absent of a spec, any implementation quirks become a part of the language. Which is okay as long as you only ever have one implementation, but when you want to, say, reimplement Typescript in Rust then you have to duplicate all of the quirks that came before, even in cases where nobody has yet realized that the quirk exists. Failure to do so means that your implementation won't be compatible with the canonical implementation. At the other end of the spectrum, the Go project maintains two independent compiler implementations to ensure that the spec is implementable and to see that a single implementation, with all of its quirks, doesn't end up defining the language. That puts a lot of confidence in the spec to guide additional implementations, but, of course, is a lot of added work. Tradeoffs, as always.

miohtama 4y ago

For the sake of being fair for other programming languages, what are the languages with proper specification? C, C++, JavaScript, others?

randomdata 4y ago
Go is staunch about its specification. To the point that the Go team maintains two independent compiler implementations to ensure that "features"/bugs in one implementation doesn't end up defining the standard and to ensure that a compiler can be implemented from the spec.
- tristan957 4y ago
  Is the other compiler you are referring to gcc-go?
- recov 4y ago
  There's actually 3 now from google afaik - gc - gccgo - gollvm [0] [0] https://go.googlesource.com/gollvm/ https://go.googlesource.com/gollvm/
munificent 4y ago
Dart has a complete specification. It tends to lag somewhat behind the most recent features (which are documented in separate language proposals), but we keep it as current as we can. Maintaining a language specification is a lot more work than people realize, and a job that few have the skills to do well.
xchkr1337 4y ago
In my opinion the presence of undefined behavior in the C/C++ specification makes it no better than the "specification by implementation" approach
- spac 4y ago
  without a specification you can never tell with certainty if there's a bug

the_gipsy 4y ago

That's one way to keep tight control.