Respectfully, that's incorrect. The requirements (ideally, in a document) are the specification, the code is an implementation of the specification. For example, you might want to software to take the FFT of something. Whether you choose to code it as decimation-in-time or frequency is up to you if the requirements do not specify.
...And once implemented, the implementation is more specific than the "specification" (a document detailing the requirements).
That's why the OP said, correctly, that code is the highest level of specification, because nothing can be more specialized than code (as you said correctly, an implementation is less specialized than code).
Also cf. Operational Semantics (no, not denotational), which is literally the highest level of specification, and is runnable code.
It is both the documentation and the thing, almost always at 100% fidelity. That's unusual, actually.
When you make a machine part, first you make a solid model. Then you use that solid model to make manufacturing drawings (where the tolerances and details are called out). This comprises the "intent". Then you use the solid model and the manufacturing drawings to create one or more gcode programs that runs on the CNC machines. Then the programs along with tool specifications and clamping setups are all used together to try and make the part. During machining many checks are performed and once the part is done, it's usually checked again on a computerized measurement device. If you did everything just right and everyone was careful, hopefully the part you produced is within the tolerances and your part is to spec. This is the artifact.
By contrast the code is (apart from bugs in the compiler or bit errors in the RAM) perfectly translated from the intent (the code) to the artifact (the executable).
No, the thing is the program, not the code. This is an important distinciton: code that isn't compiled, consumed is not a thing, except perhaps as a subject of study. Programmers' job is to create running programs, not code.
If the translation from code to program is perfect then while you're technically correct, the distinction is meaningless.
The whole point of my comment is that it's incredibly rare to have such accurate translation from the intent to the artifact and once the translation becomes good enough, they're indistinguishable at least from some perspectives. This is in great contrast to the majority of other things which are made, like machine parts, sheet metal parts, 3d printed parts, injection molded parts, extruded parts, cut and welded parts, etc.
Obviously there are also categories of things which are both the intent and artifact at once like written documents and the like, but often even with those there are various translation layers that take place. For example, an author has ideas for a book in their head, but their ideas cannot be published, only their written work. Similarly a business might agree to buy something from another business over many years and they ask their counsel to draft a contract that "prevents us from getting screwed" but the contract as written may not do so perfectly.
Most software is poorly defined to begin with and so the programmer is responsible for figuring out what the program should do in the absence of a spec. That's one class of bug.
Another is when the spec says to do a particular thing, but that thing is wrong relative to what is actually desired by the people writing the spec.
Another is a correct spec but wrong interpretation on the part of the programmer and so the code does what the programmer wanted it to, but not what the spec said it should do.
Another is correct spec and correct interpretation, but an error in the translation from programmer's brain to code.
Another is correct spec and correct interpretation and correct translation to code but some kind of particular underlying problem with the compiler, architecture, OS, whatever that by using a different (but supposedly equivalent) incantation the problem disappears.
The last class of bug I mentioned is incredibly rare, though, so in many cases what you write is what you get. That's not at all the case with many, many other things.
In most engineering you design a thing and the design is as perfect as you care to make it. And then all the quality leaks out translating the design from theory to practice. That's because the physical world is messy relative to mathematical designs. I can specify the length of a part as 1.0000000000" but it's very difficult to make a part that's accurate to more than 1.000", trying to make one that's 1.0000" long means that you have to specify the temperature!
In software engineering or programming, there's rarely an actual design and that's why the quality isn't there. Once you have a "design" (the source code of the program) it gets translated with near absolute fidelity into the "product" (the binary executable). If you design it wrong, well, sorry.
If I make a program and I say that a number should be 1 and I specify it as an int, it's exactly 1.
> Most software is poorly defined to begin with and so the programmer is responsible for figuring out what the program should do in the absence of a spec. That's one class of bug.
This is exactly my point. The fact that the programmer knows what the program should do implies that there exists knowledge outside of the program of what it should do. This knowledge consititutes the requirements, whether they be written or not.
To all who disagree with my statement that there is an independent document (or notion) that specifies requirements and program != specification, how do you define a bug?
I say that a bug is where a program violates a requirement. If you say there is no independent source of requirements than the code, then I don't see what can be bug as the program is self-consistent.
