I've made this comment before. It seems to me that there is an almost unsolvable information theoretic problem with the human language spec approach. Browsers n

I've made this comment before. It seems to me that there is an almost unsolvable information theoretic problem with the human language spec approach. Browsers need to have a standard specification for interoperability and one that includes an open source reference implementation of the core parts. Chromium seems to have become that standard. I argue here against pure natural language specifications in favor code based specs. I just don't think human language is nearly precise enough to write an adequate specification. Natural language words are incredibly polysemic and contextual. Look for example, at how many meanings the word "break" has: https://www.merriam-webster.com/dictionary/break https://www.merriam-webster.com/dictionary/break Kolmogrov has long ago suggested that fully specified information distills down to a computer program: https://en.wikipedia.org/wiki/Kolmogorov_complexity https://en.wikipedia.org/wiki/Kolmogorov_complexity, https://en.wikipedia.org/wiki/Minimum_description_length https://en.wikipedia.org/wiki/Minimum_description_length The ideal language for a pure specification might be a mix of natural language and pseudo code with a pseudo test suit. However, if you are writing that, you might as well go one step further and write working testable code. Other technical fields usually go beyond language for specifications, using blueprints and diagrams which are their version of code. There is also an history of trying to tackle the inadequacy of natural language for technical specifications. A pioneer of this is Donald Knuth with his Literate Programming (https://en.wikipedia.org/wiki/Literate_programming https://en.wikipedia.org/wiki/Literate_programming) and the descendant concepts of having code with extractable inline comments that you can use to auto generate documentation. https://en.wikipedia.org/wiki/Documentation_generator https://en.wikipedia.org/wiki/Documentation_generator I would argue that modern platforms with pull request based workflows that tie discussions to version controlled code changes are also the progression of this line of thought. A cleaned up version of these might make sense for a specification. And I get some of the concerns. While natural language under specifies, reference implementations over specify. This is more of a problem with low level languages however. Modern, high level languages are getting fairly close to a form of pseudo code. I fully agree that the reference implementations shouldn't contain or should hide, low level optimizations. I also understand that reference implementations can unduly tie specs to specific hardware, OSs and platforms. But to me, over-specification is less of a problem than under-specification and it can be mitigated by labeling particular functions or blocks of code as implementation specific and not part of the spec. Without spec written in code, the different implementations always have subtle incompatibilities. I see egregious versions of under-specification in government where horrendously vague specs are created in order to issue RFPs for getting software built. They usually end up with non working software at mind blowing cost. People have this weird misconception that they are contracting out to build software. They are not. Building software is really easy. You press the build button or type the compile command. Building software has been fully automated for a while now. What is difficult is designing software and specifying what it must do. This is because there is a vast jungle of protocols, business flows, hardware and software platforms that need to be interacted in different ways for different needs. This is what needs to be specified and only computer code can do it adequately. I wish that Mozilla adopted the chromium core. We really need a well funded non-profit managed release of the reference browser.