7 ms·

> Interesting. So it's as much an x86 legacy issue as JS and presumably JS followed x86 because it was more efficient to do so (or maybe by default). Most lang

> Interesting. So it's as much an x86 legacy issue as JS and presumably JS followed x86 because it was more efficient to do so (or maybe by default). Most languages don't start with a spec, so the semantics of a lot of these get later specced as "uhhhhh whatever the C compiler did by default on the systems we initially built this on".

brundolf 6y ago
Seeing as JavaScript was designed and implemented in two weeks, I'm betting this is the answer
- tekromancr 6y ago
  Today's JavaScript is so divorced, so radically different from the the original implementation to be considered a different language, though.
  - monocasa 6y ago
    Rounding mode was defined then and hasn't changed since though.
  - goatlover 6y ago
    Isn’t modern JS backward compatible with 1.1?
    - domenicd 6y ago
      Mostly. See https://tc39.es/ecma262/#sec-additions-and-changes-that-introduce-incompatibilities-with-prior-editions https://tc39.es/ecma262/#sec-additions-and-changes-that-intr... for a comprehensive list of backward-incompatible changes in the spec. Using that list to answer your question is a bit tricky, since it also includes backward-compatibility breaks with newer features. But, e.g., > In ECMAScript 2015, ToNumber applied to a String value now recognizes and converts BinaryIntegerLiteral and OctalIntegerLiteral numeric strings. In previous editions such strings were converted to NaN. and > In ECMAScript 2015, the Date prototype object is not a Date instance. In previous editions it was a Date instance whose TimeValue was NaN. sound like backward-incompatible changes to a JS 1.1 behavior. Another notable example is the formalization of function-in-block semantics, which broke compatibility with various implementations in order to find a least-bad compromise everyone could interop on. I'm not sure if JS 1.1 even had blocks though, much less functions in blocks...
      - asddubs 6y ago
        >Another notable example is the formalization of function-in-block semantics, which broke compatibility with various implementations in order to find a least-bad compromise everyone could interop on. I'm not sure if JS 1.1 even had blocks though, much less functions in blocks... can you explain what you mean? Did early js implementations not have functions inheriting the block scope?
        olliej 6y ago
        If they’re referring to lexical block scope then indeed, js historically did not have block scoping, it was function and global scoped. There are also differences in how eval works, etc
    - pwdisswordfish4 6y ago
      Modern JS really isn't even compatible with JavaScript. When people talk about "modern JS" it usually includes TypeScript and a bunch of NodeJS-isms, none of which are compatible with TC-39. It's only by proximity (and perversity) that it even gets to be considered JS.
    - leptons 6y ago
      No. Modern javascript engines are compatible with 1.1, but the syntax of modern javascript is not.
olliej 6y ago
It was 100% [ed] due to [/ed] the default wintel behavior. All other architectures have to produce the same value for that conversion.
aidenn0 6y ago
Your comment made me realize this is true now. Through the 80s it was the other way around. You counted as having a language with a spec, even if there was no implementation, but an implementation without a spec was a "toy"
- tatersolid 6y ago
  > Through the 80s it was the other way around. You counted as having a language with a spec, even if there was no implementation, but an implementation without a spec was a "toy" Not to my recollection. I don’t recall anyone at uni discussing a C standard until 1989, and even by 2000 few compilers were fully compliant with that C89 spec. There were so many incompatible dialects of FORTRAN 77 that most code had to be modified at least a bit for a new compiler or hardware platform. All of the BASIC and Pascal variants were incompatible with each other. They were defined by “what this implementation does” and not a formal specification.
  - aidenn0 6y ago
    C was specified by K&R in 1978. Pascal had a specification for the core language, and BASIC was largely seen as a toy.
    - tatersolid 6y ago
      > C was specified by K&R in 1978. No it wasn’t. K&R was far removed from many C implementations of the time, wasn’t ever written as a formal spec, and had gaping holes of undefined behavior. An educational textbook isn’t a formal language specification.
      - aidenn0 6y ago
        C was the K&R book, PASCAL was the User manual and Report. These were the platonic ideals of the languages. The specification was the language, the fact that there was an implementation was a bonus. I never once in my comments above said "formal" so perhaps we are meaning two very different things by "specification." No version of Cs specification since K&R has done away with undefined, nor implementation defined behavior.

brundolf 6y ago

Seeing as JavaScript was designed and implemented in two weeks, I'm betting this is the answer

tekromancr 6y ago
Today's JavaScript is so divorced, so radically different from the the original implementation to be considered a different language, though.
- monocasa 6y ago
  Rounding mode was defined then and hasn't changed since though.
- goatlover 6y ago
  Isn’t modern JS backward compatible with 1.1?
  - domenicd 6y ago
    Mostly. See https://tc39.es/ecma262/#sec-additions-and-changes-that-introduce-incompatibilities-with-prior-editions https://tc39.es/ecma262/#sec-additions-and-changes-that-intr... for a comprehensive list of backward-incompatible changes in the spec. Using that list to answer your question is a bit tricky, since it also includes backward-compatibility breaks with newer features. But, e.g., > In ECMAScript 2015, ToNumber applied to a String value now recognizes and converts BinaryIntegerLiteral and OctalIntegerLiteral numeric strings. In previous editions such strings were converted to NaN. and > In ECMAScript 2015, the Date prototype object is not a Date instance. In previous editions it was a Date instance whose TimeValue was NaN. sound like backward-incompatible changes to a JS 1.1 behavior. Another notable example is the formalization of function-in-block semantics, which broke compatibility with various implementations in order to find a least-bad compromise everyone could interop on. I'm not sure if JS 1.1 even had blocks though, much less functions in blocks...
    - asddubs 6y ago
      >Another notable example is the formalization of function-in-block semantics, which broke compatibility with various implementations in order to find a least-bad compromise everyone could interop on. I'm not sure if JS 1.1 even had blocks though, much less functions in blocks... can you explain what you mean? Did early js implementations not have functions inheriting the block scope?
      - olliej 6y ago
        If they’re referring to lexical block scope then indeed, js historically did not have block scoping, it was function and global scoped. There are also differences in how eval works, etc
  - pwdisswordfish4 6y ago
    Modern JS really isn't even compatible with JavaScript. When people talk about "modern JS" it usually includes TypeScript and a bunch of NodeJS-isms, none of which are compatible with TC-39. It's only by proximity (and perversity) that it even gets to be considered JS.
  - leptons 6y ago
    No. Modern javascript engines are compatible with 1.1, but the syntax of modern javascript is not.

olliej 6y ago

It was 100% [ed] due to [/ed] the default wintel behavior. All other architectures have to produce the same value for that conversion.

aidenn0 6y ago

Your comment made me realize this is true now. Through the 80s it was the other way around. You counted as having a language with a spec, even if there was no implementation, but an implementation without a spec was a "toy"

tatersolid 6y ago
> Through the 80s it was the other way around. You counted as having a language with a spec, even if there was no implementation, but an implementation without a spec was a "toy" Not to my recollection. I don’t recall anyone at uni discussing a C standard until 1989, and even by 2000 few compilers were fully compliant with that C89 spec. There were so many incompatible dialects of FORTRAN 77 that most code had to be modified at least a bit for a new compiler or hardware platform. All of the BASIC and Pascal variants were incompatible with each other. They were defined by “what this implementation does” and not a formal specification.
- aidenn0 6y ago
  C was specified by K&R in 1978. Pascal had a specification for the core language, and BASIC was largely seen as a toy.
  - tatersolid 6y ago
    > C was specified by K&R in 1978. No it wasn’t. K&R was far removed from many C implementations of the time, wasn’t ever written as a formal spec, and had gaping holes of undefined behavior. An educational textbook isn’t a formal language specification.
    - aidenn0 6y ago
      C was the K&R book, PASCAL was the User manual and Report. These were the platonic ideals of the languages. The specification was the language, the fact that there was an implementation was a bonus. I never once in my comments above said "formal" so perhaps we are meaning two very different things by "specification." No version of Cs specification since K&R has done away with undefined, nor implementation defined behavior.