www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - About DbC, pros & cons

reply bearophile <bearophileHUGS lycos.com> writes:

the article show some interesting critique to the DbC that look more
interesting than the article itself:

http://www.infoq.com/news/2008/11/Code-Contracts

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


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.

------------------------



Public Sub Add(value as Object) 
Contract.Ensure(Count = Contract.OldValue(Count) + 1) 



possible to do in D too :-) Old values are useful in DbC.

Bye,
bearophile
Sep 30 2010
next sibling parent reply Brad Roberts <braddr slice-2.puremagic.com> writes:
On Thu, 30 Sep 2010, bearophile wrote:


 after the article show some interesting critique to the DbC that look 
 more interesting than the article itself:
 
 http://www.infoq.com/news/2008/11/Code-Contracts
 
 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 

 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. The general theory that the earlier you find a bug the cheaper it is to fix it applies quite well here. Later, Brad
Sep 30 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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 

 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.
Sep 30 2010
parent bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:

 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.
This true is right. In the end we have to write very large D programs that use DbC, in different fields (commercial software, numerics scientific code, and so on) and then we will be able to see the advantages and disadvantages of DbC in the various kinds of code. Bye, bearophile
Oct 01 2010
prev sibling parent reply retard <re tard.com.invalid> writes:
Thu, 30 Sep 2010 19:13:18 -0400, bearophile wrote:


 after the article show some interesting critique to the DbC that look
 more interesting than the article itself:
 
 http://www.infoq.com/news/2008/11/Code-Contracts
 
 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

 change your code with less work.
A modern developer would actually use Python to write code for the space shuttle. Walter had this article about hardware/software reliability. If you write 20 implementations of the same program in Python and let the computers vote, you'll get much safer systems than with statically typed languages.
Oct 02 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
retard wrote:
 A modern developer would actually use Python to write code for the space 
 shuttle. Walter had this article about hardware/software reliability. If 
 you write 20 implementations of the same program in Python and let the 
 computers vote, you'll get much safer systems than with statically typed 
 languages.
That's a misunderstanding of what I wrote. I wrote that to get safer systems, the redundant systems must be independent of each other - the more independent, the better. For example: 1. different CPUs 2. different hardware 3. different programming languages 4. different algorithms 5. different programming teams Static or dynamic typing has nothing to do with it, unless you use one in one system and the other in the other. 20 implementations in Python may all fail to the same problem with the Python runtime.
Oct 02 2010
parent reply retard <re tard.com.invalid> writes:
Sat, 02 Oct 2010 10:25:25 -0700, Walter Bright wrote:

 retard wrote:
 A modern developer would actually use Python to write code for the
 space shuttle. Walter had this article about hardware/software
 reliability. If you write 20 implementations of the same program in
 Python and let the computers vote, you'll get much safer systems than
 with statically typed languages.
That's a misunderstanding of what I wrote. I wrote that to get safer systems, the redundant systems must be independent of each other - the more independent, the better. For example: 1. different CPUs 2. different hardware 3. different programming languages 4. different algorithms 5. different programming teams Static or dynamic typing has nothing to do with it, unless you use one in one system and the other in the other. 20 implementations in Python may all fail to the same problem with the Python runtime.
And how is static type system any better in this regard? Multiple implementations satisfies points 5), 4), and partially or fully 3) above (assuming we use several different dynamic languages). How can static type systems guarantee 1) and 2) ?
Oct 02 2010
parent Walter Bright <newshound2 digitalmars.com> writes:
retard wrote:
 Sat, 02 Oct 2010 10:25:25 -0700, Walter Bright wrote:
 
 retard wrote:
 A modern developer would actually use Python to write code for the
 space shuttle. Walter had this article about hardware/software
 reliability. If you write 20 implementations of the same program in
 Python and let the computers vote, you'll get much safer systems than
 with statically typed languages.
That's a misunderstanding of what I wrote. I wrote that to get safer systems, the redundant systems must be independent of each other - the more independent, the better. For example: 1. different CPUs 2. different hardware 3. different programming languages 4. different algorithms 5. different programming teams Static or dynamic typing has nothing to do with it, unless you use one in one system and the other in the other. 20 implementations in Python may all fail to the same problem with the Python runtime.
And how is static type system any better in this regard?
I didn't make any comment about that.
 Multiple 
 implementations satisfies points 5), 4), and partially or fully 3) above 
 (assuming we use several different dynamic languages). How can static 
 type systems guarantee 1) and 2) ?
I didn't say they did. I'm wondering what you read that led you to these questions?
Oct 02 2010