About DbC, pros & cons

[Walter Bright]

Brad Roberts wrote:
> On Thu, 30 Sep 2010, bearophile wrote:
>> That critique is right, but wrong too. Contracts are a kind of type 
>> system. They put limits and add rigidity between the interfaces (not 
>> meant in their D language meaning) between code subunits. Dynamic type 
>> systems allow faster updates when parts change, while strict type 
>> systems, unittests and Dbc increase your confidence that the code does 
>> what you want and reduce unwanted interactions between subsistems of 
>> your program, and at the same time they introduce long-distance coupling 
>> among those subsystems. So in the end life is about trade-offs. Even 
>> unittests may add such rigidity that has a cost.
>>
>> If you have to write code that guides the Space Shuttle you want it to 
>> be perfect, and you want to use DbC enforced statically, while if you 
>> want to write software that deals with ever mutating commercial 
>> realities, you prefer something like C# or Python that allows you to 
>> change your code with less work.
>>
>> D looks designed more for numerical code, where rules don't change or 
>> change slowly, and less fit for commercial code that needs to be changed 
>> often.
> 
> I disagree with this logic.  The additional checking you can do with 
> contracts makes it easier to make changes with confidence about catching 
> unwanted side effects.  That both raises your confidence and reduces the 
> time spent studying code to find unwanted side effects or debugging 
> because you missed them.  They're found quickly.


I agree with Brad. DbC is not about making your code rigid, inflexible, 
resistant to change, nit-picky, etc. It is about making the requirements of a 
function checkable.

For example, passing -1 to a sqrt() function that is defined to take only 
positive values, and having something unexpected happen as a result, is not 
making sqrt *flexible*, it is about having a *bug* in your program.

Perhaps counter-intuitively, the more of this that is checkable, the *more* 
flexible your source code becomes, and the faster it is to develop code with it. 
The reason is because it removes the fear of changing code because with no 
checks, you can't be sure you didn't break it.