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.
