4 ms·

Code is the highest level of specification, my RE teacher always told me.

supahfly_remix 11y ago
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.
- throwaway1967 11y ago
  ...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.
  - dadrian 11y ago
    Case in point: OpenSSL. More of a TLS specification than the RFC is, nowadays.
  - supahfly_remix 11y ago
    it's more specific, yes, but those differences don't matter if they aren't requirements.
    - candu 11y ago
      Those differences definitely matter if people come to depend on them. This is really a debate between prescriptive and descriptive schools of specification ;)
- UK-AL 11y ago
  Requirements are ambiguous, don't include all the detail etc. Code is the most rigorous documentation there is.
  - msandford 11y ago
    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). The differences are staggering.
    - Fargren 11y ago
      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.
      - msandford 11y ago
        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.
- deleted 11y ago
  [deleted]

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.

throwaway1967 11y ago
...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.
- dadrian 11y ago
  Case in point: OpenSSL. More of a TLS specification than the RFC is, nowadays.
- supahfly_remix 11y ago
  it's more specific, yes, but those differences don't matter if they aren't requirements.
  - candu 11y ago
    Those differences definitely matter if people come to depend on them. This is really a debate between prescriptive and descriptive schools of specification ;)
UK-AL 11y ago
Requirements are ambiguous, don't include all the detail etc. Code is the most rigorous documentation there is.
- msandford 11y ago
  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). The differences are staggering.
  - Fargren 11y ago
    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.
    - msandford 11y ago
      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.
deleted 11y ago
[deleted]