3 ms·
Disagree, there's a lot of ambiguity in English that makes for bad specifications. Example: take even the word "tomorrow". Does tomorrow mean at midnight tonig
by rpwilcox 13y ago
Disagree, there's a lot of ambiguity in English that makes for bad specifications.
Example: take even the word "tomorrow". Does tomorrow mean at midnight tonight, or tomorrow morning? Does it mean 24 hours from now, or does it mean a far future time? Does "tomorrow" include weekends or holidays? In what timezone is this happening?
The Beach Boy's song: "Will you love me tomorrow?": Is that asking if the singers love will still have the same feelings about them tomorrow (less than 24 hours from now), or is the singer asking if their love will still adore them many years from now, (when they're 64, for example, to pick another oldey).
Which is of course why civilians think developers are pedantic, and of course we are, because to implement specifications on Turning machines we need to answer these slightly outrageous questions. "Turn on the sprinkling system tomorrow" is a trivial specification for a human, but not so for computers.
Tomorrow is just the example that comes to mind, there are thousands of other words whose meanings are vague. This is why creating specifications for computers, from "civilian English" is hard.
- jackgavigan 13y agoThe fact that some people use the language in a vague or unspecific manner does not invalidate English's suitability as a language for writing specs. I doubt I've ever used "tomorrow" in a spec. I'd use "next business day" or "T+1" (with the calendar defined). In my experience, writing a spec is an iterative process, where the developers review a draft of the spec and make comments, ask questions, point out ambiguity, etc., which provides the feedback for the next version off the spec. That process loops until everyone is happy, at which point the spec (or, at least, a portion of it) is finalised and the developers start work.