It is something abstract. It is some "document" that establishes rules to be followed, what is expected from possible implementations. These rules may require some things and prohibit others. It’s a formalization of how something should proceed. It’s the law. Roughly it’s the recipe.
It’s something concrete. It’s how it’s actually made. It’s what’s there to use. It’s law enforcement. It’s the cake made by someone attending to what the recipe says.
It is possible to vary the recipe, but if you modify its fundamental points, you will be hurting the dish and it can no longer receive that name. Obviously in cooking causes less problem than in computing :P.
Relationship between them
It is obvious that if the implementation does not do something that the specification requires, who will use that, which should be a standard, will have problems. If the implementation does something extra that the specification does not prohibit there will be no problems. But if you’re going to use what was created on top of this implementation to take advantage of the extras, you obviously can’t port to a different implementation that is more narrowly focused on the specification.
In the context described the implementation is being made on top of the specification, meeting all rules established by it. The implementation can, in theory, do anything that is not prohibited by the specification, but this can bring difficulties, even future in a review of the specification.
Within the rules the implementation can and should do its best to meet the needs of its users.
If the implementation breaks a specification rule it cannot be considered to adhere to that standard.
The specification can be more detailed or more superficial, giving more rigidity or flexibility to what the implementation can do. Can also give more ambiguity and bring problems. Specification may have bug :).
It is often more difficult to make a good specification than a good implementation, although the amount of work may be the reverse.
A bad specification can make it difficult or even make it impossible for a good implementation to exist.
Usually the specification should be simple to understand. The implementation should be good to use.
Some domains work best with an existing clear and formal specification. Others may be just an unnecessary and undesirable complicator.
Planning how you will implement is not specification, at least not in the sense described.
Some implementations are considered as specification. Are informal specifications and other implementations should be compatible with this, until the bugs, because there is no clarity when it is a bug and when it isn’t. There are pros and cons to doing this.
Specification for programming language.
In the general context or in the context of java/garbage collector?
– rray
Overall, I used the garbage collector as an example.
– Bruno Brito