digitalmars.D - About DbC, pros & cons
- bearophile (12/12) Sep 30 2010 A small article about design by contracts in C# dotnet 4. The comments a...
- Brad Roberts (10/35) Sep 30 2010 I disagree with this logic. The additional checking you can do with
- Walter Bright (11/37) Sep 30 2010 I agree with Brad. DbC is not about making your code rigid, inflexible,
- bearophile (4/8) Oct 01 2010 This true is right. In the end we have to write very large D programs th...
- retard (6/27) Oct 02 2010 A modern developer would actually use Python to write code for the space...
- Walter Bright (13/18) Oct 02 2010 That's a misunderstanding of what I wrote. I wrote that to get safer sys...
- retard (5/27) Oct 02 2010 And how is static type system any better in this regard? Multiple
- Walter Bright (4/33) Oct 02 2010 I didn't say they did.
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
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
Brad Roberts wrote:On Thu, 30 Sep 2010, bearophile wrote: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.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.
Sep 30 2010
bearophile <bearophileHUGS lycos.com> 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
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
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
Sat, 02 Oct 2010 10:25:25 -0700, Walter Bright wrote:retard wrote: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) ?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
retard wrote:Sat, 02 Oct 2010 10:25:25 -0700, Walter Bright wrote:I didn't make any comment about that.retard wrote:And how is static type system any better in this regard?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.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