4 ms·

But a specification could be ambiguous, with the need for human intervention to resolve ambiguity through the 'compilation' process. And I'm not sure that I'm

by gdp 17y ago

But a specification could be ambiguous, with the need for human intervention to resolve ambiguity through the 'compilation' process. And I'm not sure that I'm aware of any production-grade systems that use declarative English as a specification mechanism. Most of the systems that I am familiar with use ASCII-friendly logic notation or mathematical notation in the style of LaTeX or similar. I'm not necessarily suggesting that this is how software should be developed, rather I'm just pointing out that your experience and knowledge of what might pass as a specification is different to mine.

philwelch 17y ago
Here's my point. "You should be able to compile spec" is a useless argument, because anything we can compile would either be English (which we shouldn't compile) or a formal language (and a formal language that can be compiled is a programming language). Useful things to say include "here's a good high-level language that makes it easier to program" or "here's a language and a compiler for it that allows the compiler to ask intelligent questions about ambiguity in the code". "I want to be able to push a button and turn a specification into a program" is too vague to be useful--interpreted literally it already describes the compilers we have today, and interpreted liberally it could mean anything from "languages aren't high level enough" to "programming is too hard" to "I want to express programs with pretty pictures and by answering questionnaires" to "I want to compile English". Now, if we rule out "I want to compile English" as a very bad and stupid idea, we're left with things that, quite frankly, we've been researching the whole time (with the possible exception of compilers that question ambiguous expressions). Forcing us to ultimately conclude, first that the author doesn't know what he's talking about, and second that he isn't asking for anything more than what computer scientists are already working on.
- gdp 17y ago
  I think you're still fundamentally understanding what makes a specification different from "code". A specification is to a program as a building plan is to a house. I spend less effort on drawing the plan that I do into the house, although I wouldn't put anything into the plan that I don't want to end up in the house that will (eventually) be built. Similarly, once the house is built, I can verify (presumably using a tape measure) that my house implements my building plans. But I can't live inside a blueprint. So, while this is not a formal definition, I think a good (informal) means of distinguishing a specification from a program is that if the specification could be substituted for the program it is specifying, then it's probably not a specification in any useful sense. This is to negate the usual argument that "my poorly-hacked C code is the specification for my program". The "push a button" argument is a bit of a red herring. "Pushing a button" is a convenient metaphor for "perform some low-effort, largely-mechanised process". If your complaint is that it's an over-simplification, perhaps it is worth thinking about what the intention of the article was. It's not a work of serious theoretical value - it's simply advocating an ideological position to an audience of programmers who don't already know about specification and think that it's a good idea.

by gdp 17y ago

philwelch 17y ago

Here's my point. "You should be able to compile spec" is a useless argument, because anything we can compile would either be English (which we shouldn't compile) or a formal language (and a formal language that can be compiled is a programming language). Useful things to say include "here's a good high-level language that makes it easier to program" or "here's a language and a compiler for it that allows the compiler to ask intelligent questions about ambiguity in the code". "I want to be able to push a button and turn a specification into a program" is too vague to be useful--interpreted literally it already describes the compilers we have today, and interpreted liberally it could mean anything from "languages aren't high level enough" to "programming is too hard" to "I want to express programs with pretty pictures and by answering questionnaires" to "I want to compile English". Now, if we rule out "I want to compile English" as a very bad and stupid idea, we're left with things that, quite frankly, we've been researching the whole time (with the possible exception of compilers that question ambiguous expressions). Forcing us to ultimately conclude, first that the author doesn't know what he's talking about, and second that he isn't asking for anything more than what computer scientists are already working on.

gdp 17y ago
I think you're still fundamentally understanding what makes a specification different from "code". A specification is to a program as a building plan is to a house. I spend less effort on drawing the plan that I do into the house, although I wouldn't put anything into the plan that I don't want to end up in the house that will (eventually) be built. Similarly, once the house is built, I can verify (presumably using a tape measure) that my house implements my building plans. But I can't live inside a blueprint. So, while this is not a formal definition, I think a good (informal) means of distinguishing a specification from a program is that if the specification could be substituted for the program it is specifying, then it's probably not a specification in any useful sense. This is to negate the usual argument that "my poorly-hacked C code is the specification for my program". The "push a button" argument is a bit of a red herring. "Pushing a button" is a convenient metaphor for "perform some low-effort, largely-mechanised process". If your complaint is that it's an over-simplification, perhaps it is worth thinking about what the intention of the article was. It's not a work of serious theoretical value - it's simply advocating an ideological position to an audience of programmers who don't already know about specification and think that it's a good idea.