stability

[Derek Parnell]

On Fri, 29 Feb 2008 14:24:44 -0800, Walter Bright wrote:

> Edward Diener wrote:
>> Without a specification for each language release a computer language 
>> just ends up being a small club of those in the know rather than a 
>> useful product for end-users to create modules and applications.
> 
> Nearly all major languages had detailed and accurate specifications 
> produced for them only *after* they became widely adopted.
> 
> Languages that start out with a detailed and accurate specification tend 
> to be failures.
> 
> Some reasons:
> 
> 1) It's exceedingly hard work to do a spec. That makes it not worthwhile 
> unless there are very large forces to make it worthwhile (like a huge 
> user base).
> 
> 2) It takes a long time to produce a spec, so long that the language may 
> become obsolete before it has a chance (cue Ada).
> 
> 3) Producing a spec in advance means you've frozen in place design 
> decisions that may turn out to be horribly, horribly wrong, but yet the 
> language is stuck with them (cue exported templates).

This position applies if one assumes that a specification is not developed
in conjunction with 'prototyping' and peer reviews. It also assumes that a
specification must be 'final' before development can commence. That is a
recipe for disaster.

Another model is where the specification is developed iteratively, a 'step'
in front of code development. Feedback from the code and the applications
practical usage goes back into the next iteration of the specification. In
the initial stages the specification can be in wild oscillation as ideas
are attempted then modified or rejected. However, what soon occurs is a
specification that is acceptable and only subject to incremental changes
that tend to be non-breaking ones. And in the meantime, the application
development is nearly always aligned to the written specification, which
makes bug determination much easier to do.

One of the reasons we have specifications is because it fits the needs of a
difference audience than the actual code does. For example, most formal
test cases are developed from specifications and not by reading the code.
Test case developed by reading the code tend to test what the code does
rather than test what the code is supposed to do.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell