Hacker News Reader

Comment by gridlockd | Hacker News Reader

Always write an implementation first - and make it a good one. Then derive a standard from it.

"Oh, but the implementation details will leak through!"

So what? This is an ivory-tower concern. When you are designing a standard, you must have your mind on possible implementations, which is far more difficult without having created an actual implementation. You can't design in a total vacuum, otherwise your standard can't be implemented properly at all.

View on HN

The ECMAScript 4 standard was on the right track: evolve a standard and a liberally-licensed reference implementation in a language with high-quality formal semantics. Ambiguities in the textual standard should be resolved by looking at the reference implementation. Contradictions between the text and the reference implementation should be regarded as bugs in the standard.

People complained the ES 4 was too much, too quickly, but I think we're slowly getting something equally complex, but less cohesive and more ad-hoc.

That's how we got the open version of MS Word. For small values of 'open', because 'do it like Word '95 did it' is not a very good way of describing a standard.

I just checked and was somewhat surprised to learn that AutoSpaceLikeWord95’s behavior is actually pretty well specified:

https://docs.microsoft.com/en-us/dotnet/api/documentformat.o...

I’m sure there are still gaps in the specification overall; I don’t actually know much about it, but I believe competing implementations have trouble reproducing the exact layout of Word documents, which should be possible with a good specification, and is mostly possible with HTML.

But I don’t see anything wrong with that particular attribute. Backwards compatibility is important.

Reply on news.ycombinator.com