Code implements specification66.7%
Code is specification33.3%
12 votes \ poll ended
1266 sats \ 2 replies \ @petertodd 2 Oct
Writing clear specifications in English is incredibly difficult, essentially impossible. That's why the Ethereum yellow paper – an attempt at doing just that – was an utterly unreadable mess.
If your specification is code on the other hand, you have the enormous advantage of being able to leverage highly sophisticated tooling to help you understand what exactly that specification means, and actually implement it: compilers.
And yes, even a code specification isn't actually an implementation. You still need a compiler (or interpreter) to actually turn that specification into the actual opcodes that the CPU actually runs – the implementation.
This question is one of those things that distinguishes competent people who actually understand how Bitcoin and consensus systems work, and the incompetent blowhards. No-one who has actually worked on this stuff in detail thinks human readable specifications are sufficient. You're always going to end up referencing code specifications to really nail down what you are actually specifying. You can write pseudo-specifications that aid in understanding the real spec. But they'll always be just an explanatory aid.
reply
100 sats \ 1 reply \ @zuspotirko OP 2 Oct
Bitcoin is a good example. But what about other stuff?
example 1: the behavior of an assembly instruction set must be incredibly rigid.
example 2: the TCP/IP protocol. The paper specifications are insane. And describing bit-length blocks in headers should be unambiguous, no?
example 3: the L-mount alliance in cameras has dozens of camera manufacturers and camera lens manufacturers. Since they claim to be equal partners in this alliance the master should be the specification instead of one camera manufacturers code.
Don't you see a point for both sides of the argument here? Or are still deeply on the "code is specification" side?
reply
1136 sats \ 0 replies \ @petertodd 2 Oct
OpenTimestamps uses the "code is specification" model.
Also, the OPUS audio codec includes a C implementation: https://datatracker.ietf.org/doc/html/rfc6716#appendix-A A lot of cryptography standards do this too.
TCP/IP is a lot simpler to implement correctly than Bitcoin. Unlike Bitcoin, it's not a consensus protocol... and a full implementation of Bitcoin mostly requires TCP/IP anyway! But even then, TCP/IP isn't actually defined in RFCs the way you think it is. In reality it's defined by running code. When push comes to shove, the running code wins. That's why early networking development relied on "testing parties", where multiple manufacturers got together to verify that their stuff actually worked.
L-mount is an even simpler standard. And again, it's not a consensus protocol, making everything a lot simpler. It's ok if two different cameras/lenses aren't bug-for-bug compatible. And again, like TCP/IP, I can guarantee you that camera and lens manufacturers maintain big libraries of lenses/cameras to test against.
Sorry. All your examples are things that are a lot easier to get right than Bitcoin. Which is why standards for them can get away with lose English language specs. Though as I explained with TCP/IP, in reality the English language specs aren't actually good enough.
reply
131 sats \ 5 replies \ @k00b 2 Oct
Both. Specifications are rarely complete, so the implementation usually specifies the last mile.
reply
141 sats \ 4 replies \ @zuspotirko OP 2 Oct
Imagine an imaginary image format - lets call it ".jpgXL2" - has hundreds of pdf pages of documentation and been widespread in the Linux world for years.
Now Microsoft or Apple implement compability with jpgXL2. It follows the pdf perfectly to the letter. But files aren't really compatible with files converted on an Ubuntu computer.
Where is the bug. Insufficient specification? Bug in Linux? Bug in the Windows specification?
reply
5 sats \ 1 reply \ @k00b 2 Oct
Bug in Linux. Linux isn't following the spec or forgot to update it after improving on it in their implementation.
reply
0 sats \ 0 replies \ @jerrybature 3 Oct
Agreed.
reply
0 sats \ 1 reply \ @037447d9ca 2 Oct
Linux does not handle any image formats, that is userland's libraries job.
reply
0 sats \ 0 replies \ @zuspotirko OP 2 Oct
You're right. I wrote "Linux world" to include the wider landscape of open source dependencies, programs etc that are popular in the community. Forgot that in the last paragraph.
reply