3 ms·

>That source code is 12-15 million lines of code. Exactly, it's impossible to describe that in human language which doesn't have precise enough semantics. That

>That source code is 12-15 million lines of code. Exactly, it's impossible to describe that in human language which doesn't have precise enough semantics. That's why the spec has to be in code, in the form of a reference implementation and/or test suit. The goal should be to move chromium away from being controlled too much by Google.

dmitriid 5y ago
> Exactly, it's impossible to describe that in human language which doesn't have precise enough semantics. On the contrary, this implements specs that are defined in a human language. For example, the full semantics of rendering HTML were standardised with HTML5, and now all browsers render HTML the same way. The problem isn't the human language. The problem is the sheer number of these specs. Hundreds, if not thousands. However, good luck understanding these specs by reading code or unit tests (and yes, there's a multitude of tests [1]). How do you know what a piece of code encodes? Or a test tests? You really propose to reverse engineer behaviour from code? Example: here's a test: https://github.com/web-platform-tests/wpt/blob/master/html/semantics/forms/the-datalist-element/datalistoptions.html https://github.com/web-platform-tests/wpt/blob/master/html/s... What exactly does it test? Why? Is this a correct test for this behaviour? Care to pinpoint the exact precise location of this spec in Google Chrome's code? [2] It's only 12 or so million lines of code, should be easy to find. > The goal should be to move chromium away from being controlled too much by Google. By doing what exactly? [1] https://web-platform-tests.org https://web-platform-tests.org [2] https://github.com/chromium/chromium https://github.com/chromium/chromium
- BenoitEssiambre 5y ago
  >now all browsers render HTML the same way. Is this sarcasm? Writing web apps that work the same across browsers is still the most painful part of web development. The underspecified natural language specs lead to subtly different behaviors in different browsers. Full specs of a complex systems are very complex.
  - dmitriid 5y ago
    > Is this sarcasm? It's not. How HTML is rendered was literally not defined between browsers until mid-00s. Hence the difference in the boxing model, for example. Bt yes, besides HTML there are hundreds of other specs, and those may or may not be implemented across browsers. > The underspecified natural language specs lead to subtly different behaviors in different browsers. You keep saying this, and I don't think you even understand what you're saying. > Full specs of a complex systems are very complex. Yes, they are. What you keep proposing though, is to reverse engineer behaviour from millions of lines of code. I'm still waiting for an answer to my question about datalistoptions test.
    - BenoitEssiambre 5y ago
      No, not to reverse engineer behavior, to _define_ behavior in a well commented codebase with a well commented test suite. The technical blueprints are as important than the natural language notes in the blueprints. In software, code is blueprint.

dmitriid 5y ago

> Exactly, it's impossible to describe that in human language which doesn't have precise enough semantics. On the contrary, this implements specs that are defined in a human language. For example, the full semantics of rendering HTML were standardised with HTML5, and now all browsers render HTML the same way. The problem isn't the human language. The problem is the sheer number of these specs. Hundreds, if not thousands. However, good luck understanding these specs by reading code or unit tests (and yes, there's a multitude of tests [1]). How do you know what a piece of code encodes? Or a test tests? You really propose to reverse engineer behaviour from code? Example: here's a test: https://github.com/web-platform-tests/wpt/blob/master/html/semantics/forms/the-datalist-element/datalistoptions.html https://github.com/web-platform-tests/wpt/blob/master/html/s... What exactly does it test? Why? Is this a correct test for this behaviour? Care to pinpoint the exact precise location of this spec in Google Chrome's code? [2] It's only 12 or so million lines of code, should be easy to find. > The goal should be to move chromium away from being controlled too much by Google. By doing what exactly? [1] https://web-platform-tests.org https://web-platform-tests.org [2] https://github.com/chromium/chromium https://github.com/chromium/chromium

BenoitEssiambre 5y ago
>now all browsers render HTML the same way. Is this sarcasm? Writing web apps that work the same across browsers is still the most painful part of web development. The underspecified natural language specs lead to subtly different behaviors in different browsers. Full specs of a complex systems are very complex.
- dmitriid 5y ago
  > Is this sarcasm? It's not. How HTML is rendered was literally not defined between browsers until mid-00s. Hence the difference in the boxing model, for example. Bt yes, besides HTML there are hundreds of other specs, and those may or may not be implemented across browsers. > The underspecified natural language specs lead to subtly different behaviors in different browsers. You keep saying this, and I don't think you even understand what you're saying. > Full specs of a complex systems are very complex. Yes, they are. What you keep proposing though, is to reverse engineer behaviour from millions of lines of code. I'm still waiting for an answer to my question about datalistoptions test.
  - BenoitEssiambre 5y ago
    No, not to reverse engineer behavior, to _define_ behavior in a well commented codebase with a well commented test suite. The technical blueprints are as important than the natural language notes in the blueprints. In software, code is blueprint.