Fingers of the same hand can't be on both the top and bottom row.
I don't know about that one. Try typing "nice" on a qwerty. I find it quite natural that the index and middle fingers of both hands hit the "ni" and "ce" pairs in quick succession.
I'm sure there are plenty of starving Russians who could think of something better to do with that money.
Grr. This same argument is repeated over and over, ad nauseum, by people who apparently think they only purpose of the human species is to survive in the largest possible numbers with the most uneventful possible lives.
Granted, we need to take care of the less fortunate. However, if we don't spend money on science and exploration until everyone in the world is 100% equal in every sense of the world, then we will never spend money on science and exploration, and we will stagnate as a species.
Ok, I think I may be wasting my time. I thought you were just unfamiliar with DbC, but it seems to me you have made up your mind to believe that DbC is something it's not, and to argue against it based on faults it doesn't posess. You have taken a gratuitously pessimistic view of everything I say, to the point that some of your comments actually contradict what I have said.
I hope I'm wrong, and that we can continue to have a rational discussion about this.
So it is slow the first 2 years, before More's law makes it not matter? That is not a very good selling point.
Yes, it sure isn't a good selling point if you pull this two-year time frame out of your ass. What if I told you the time frame is more like six weeks? That would be more in line with my experience.
Furthermore, even if you never disable assertion checks, DbC makes it clear exactly where they are necessary, so you don't end up with duplicate redundant checks.
And IF statements are not because they are not weird and funky enough to stand out?
I'm not sure what your point is here. Mine is that you can't disable error checking code unless you know which error checks can safely be disabled. Sure, you can grep for "if", but you need to know the difference between error checks that trap bugs in the program, versus those that catch valid error conditions like user errors.
For instance, in a C compiler, you should eventually be able to disable internal data structure consistency checks, but you can never disable parse error checks. In most software, such as business apps, the line between bugs and actual error conditions is not so clear.
The way you tell error conditions from bugs is Design by Contract. To the extent that you can tell these two things apart, you are using DbC, whether you have chosen to do it consciously or not.
DbC is not an implementation technique to check for errors; it's a design methodology to delineate precisely the responsibilities of each class/module/function in a system.
Yeah yeah. I have had this argument before, and how DBC is so *subletly* different that it does not really matter.
Use what is already available and stop adding goofy little syntax to a language to make it funkier and funkier. Reinvent something really different, not a glorified IF statement.
This kind of logic is hard to argue with. You dismiss my statement that Design by Contract is more than just an IF statement, and then you claim that because it's just an IF statement, it's worthless. Well, I agree that there's no point in adding glorified IF statements to a language, but I can only emphasize once again that DbC is a design methodology. (Why do you think they call it Design by Contract?)
I have already told you that I use DbC to design C code. C obviously doesn't have any special contract syntax, do I'm not sure how you could believe that DbC is just a syntax issue.
There are mountains of resources on the internet describing the DbC technique, and if you want to ignore it and argue against a straw man instead, that's your perogative.
To add this kind of checking code everywhere throughout the system would be prohibitively slow, even if the errors you are checking for never happen. In contrast, once certain bugs are rare enough, assertion checks can be disabled, and no longer add any performance overhead. Furthermore, even if you never disable assertion checks, DbC makes it clear exactly where they are necessary, so you don't end up with duplicate redundant checks.
What you have shown is not Design by Contract. DbC is not an implementation technique to check for errors; it's a design methodology to delineate precisely the responsibilities of each class/module/function in a system. Yours is an example of defensive programming, which is basically the opposite of DbC.
Have a look at some of the Design by Contract literature on the web. I promise, it will be time well spent, even if you don't end up using it.
Maybe in scientific computing where the interface is simple, but the computations are complex. However, biz apps tend to be the other way around.
That does not match my experience, but let's assume you're right. Then, the fact that an interface is complex makes it that much more important to document it in a rigorous way; and the fact that this is difficult to do certainly doesn't mean that it shouldn't be done.
I have applied DbC successfully to business apps and system software. I have never written any scientific software, so I can't comment on that.
Preconditions and postconditions are nothing more than a precise way to specify what something does.
Try comments. Well-worded comments are not going to beat the usefulness of some machine-readable notation precisely because it is tuned for the machine instead for people.
I'll ignore the freudian slip, and assume you meant that well-worded comments are going to beat the usefulness of assertions. In that case, I disagree with that too:
Nobody ever said assertions in DbC need to be executable. DbC is a design methodology, based on the principle that you should know what the parts of your system are supposed to do. I use DbC when I write my C code, and my contracts take the form of comments.
Forcing comments to be executable makes them less ambiguous. In this way, Eiffel-style assertions are often preferable to the comments that usually pass for interface documentation.
Executable contracts are continually double-checked against the implementation code to make sure they agree. Comments can drift and become inaccurate over time.
The same argument regarding redundancy could be used against type annotations...
I can live without those. I tend more toward scriptish langs anyhow these days.
Good for you. The point of my comparison with type annotations (plus, more importantly, variable declarations and multi-character variable names, which you have ellided) was that redundancy is not always bad. The redundancy argument could also be used against comments; I hope you won't argue that comments are contrary to the "say it once" principle?
Ok, so what do you do against a site that disallows browsers without a Referer header, and only allows requests with a Referer that contains a special cooked-up URL with a random number in it, that changes every hour?
This is basically using the Referer header as another form of cookie.
SLOC is not a good measure of how "good" software is; merely of how complex it is, and how long it takes to develop. Studies have shown that SLOC is better at this than most other metrics:
...lines of code has commonly been found to outperform many of the more
complex composite measures of software development.
Cg is almost guaranteed to be efficient in hardware, and any Renderman program can be translated to Cg, by hand or by a tool that someone's developing. Once that happens, all the moviemaking can take place in Cg.
Let's try that another way, shall we?
Machine code is almost guaranteed to be efficient in hardware, and any C program can be translated to machine code, by hand or by a tool that someone's developing. Once that happens, all the development can take place in machine code.
I don't think so. I don't know nothin 'bout graphics in the movie industry, but why wouldn't everyone continue to code in Renderman, and then translate it automatically to Gc at the end?
Oh man, this is the funniest thing I have read in a while. You almost made me burst out laughing out loud here at work, which would have been very embarrassing...
Regarding Design-by-Contract, it is hard to implement such for many types of business rules. It takes more code to state the contract than it does to implement it in many cases.
This is the same objection as "how do I get from here to there without goto". If you design your application with contracts in mind, your contracts are never so complicated as to become a burden. Likewise, if you design your app with relational tables in mind, those probably tend to stay relatively simple too.
You end up have to change 2 things instead of one when new requirements come: the implementation *and* the contract verification code. Thus, you increase the chance of errors. It often violates the once-and-only-once rule of factoring.
Yes, this is often stated as a flaw in Design by Contract. I disagree with it. Firstly, there is no contract verification code; only the contract. When a modification affects a contract, you're in for a lot of trouble (even more so when you're not using DbC, and therefore may not realize that the contract actually has changed), and the effort of modifying the contract itself reminds a programmer of that. Contracts only need to be changed for exactly those situations in which the work of changing the contract itself vanishes in comparison with the labour required to propagate that modification to the rest of the system.
There are a number of other reasons I disagree with your assessment:
The contract and the code do not say the same thing, except for trivial cases. Unfortunately, the kinds of cases shown to beginners must be trivial, so that is all they see.
In a system designed using DbC, the contracts are far simpler than the implementation. Let's say they're 5 times simpler. Then, even assuming they are entirely redundant (which they aren't), that's only a 20% growth in code size. It's well worth it for DbC's benefits.
Finding a solution to a problem is generally harder than demonstrating the solution to be correct. This is the basis for the conjecture that P != NP. It is also the basis for DbC: namely, contracts are easier to write than programs, and can demonstrate that a program is working correctly.
Whatever redundancy there is is a good thing in this case. Stating certain things twice, in two different ways, and having the computer check them against each other, helps to locate errors. The same argument regarding redundancy could be used against type annotations, or variable declarations, or even multi-letter variable names, but most would argue that these kinds of redundancy help program correcness, rather than hindering it.
The most convincing argument in favour of DbC, I think, is Bertrand Meyer's "law of the excluded miracle": if the author of a class/procedure/module doesn't know what it's supposed to do, then the odds that it will do it properly are vanishingly small. Preconditions and postconditions are nothing more than a precise way to specify what something does.
Thanks for the reference. I have never seen relational programming advanced as a general-purpose paragigm for software construction, so I'll find it interesting to investigate.
My personal opinion regarding OO is that people are disappointed in it for a number of reasons:
It has been oversold as a panacea, so people become disappointed when they discover that they still need to think.
It has been represented very poorly by at least one language, C++, which has convinced many that OO is unworkable on large, complex projects.
Popular OO languages and approaches miss out on Design by Contract, making them far less effective.
The majority of programmers are simply not skilled enough to architect large enough projects to evaluate a paradigm's scalability. (This same assertion, in a different form, is what led Fred Brooks to promote the surgeon team in The Mythical Man Month twenty years ago.) It is my feeling that skillfully-applied OO wins over some other paradigms (equally skillfully-applied) at the high end of complexity, though I could just be another of those unskilled programmers relying on blind faith in OO.:-)
Perhaps a realistic example is in order. Shape, animal, and device driver toy examples don't scale to real things that I actually encounter.
Those are toy examples of OO, so of course I won't use those to demonstrate how information hiding is orthogonal to OO.:-)
A nontrivial example won't fit here, so I'll have to refer you to Parnas's original article on the topic. Its example could still be considered trivial by today's standards, but it's far better than anything I could fit in this space. It makes no reference to OO whatsoever. In fact, it's decidedly non-OO, with modules like "circular shifter" and "alphabetizer" that are most certainly procedural abstractions.
If you want a bigger example, there's my Master's thesis work, especially my defence presentation (PowerPoint slides). I consider it a good example of a successful application of information hiding principles, and it's about 23,000 LOC, so it's big enough to be considered nontrivial. It's also OO, so it doesn't prove that OO is orthogonal to information hiding, but I feel that its success arises from information hiding more than OO (especially since it's written in C and so makes no use of inheritance).
One can show that 3rd-generation languages can code the same thing with less code and be more transportable to other platforms than assembler.
How does one show that? Do you have a reference for such a study?
The 3rd-generation-versus-assembly is the most clear-cut case of programming language expressive power there is, and yet it's still quite hard to "prove" in any meaningful way.
Relational tables are a protocol and organizational philosophy. They allow, for example, one to get GOF-like patterns with mere formulas instead of painstaking hand-referencing needed in OOP.
That's interesting. Do you have any references for this?
OOP has never been proven to be objectively superior, neither WRT code size, nor reuse, nor less change under change-impact analyses.
Name a discipline that has been proven in such a way.
The trick to procedural is good table schema design IMO.
No offence intended, but IMHO that's retarded. Most of your system shouldn't have a clue that there even are tables. Plus, this falls flat for systems that are not based on tables. If you don't mind my saying so, it sounds like you have written software in a fairly narrow application domain.
You're right, of course, that it is too easy to say "you should have designed it right in the first place", and I tried not to say just that, though I may have failed.:-)
I tried to give some advice on how to tell whether a module system is good (that is, by information hiding); and further, to answer his question, my advice would be to refactor whenever he sees that information is not being hidden properly by the system's modules.
If 1/10th of those are capable of supporting life (a pessimistic view when you consider that at least one out of four in our solar system is capable, not to mention mars and europa)...
Try this:
"If 1/10th of all mammals on Earth have highschool diplomas (a pessimistic view when you consider that at least 2/3 of the mammals in my apartment have diplomas)..."
These sound like the wrong questions to me. It reminds me of someone's (perhaps Dijkstra's?) story of the response he received when he recommended abolishing gotos. Someone said "ok, I'll buy that; so what do I do if I'm at this point in the program, and I want to get to that point?"
The trouble with such a question is that it has no answer. Dijkstra's argument was not that one should take existing programs and remove the gotos; rather, that programs written using only structured elements (sequencing, conditionals, loops) are more comprehensible, and don't require any gotos because there is a more elegant way to achieve the same effect. Thus, as you can see, there really is no answer to the question; the questionner's approach was fundamentally flawed.
Likewise, software organization is not done in terms of functions; rather, it is done in terms of information-hiding modules. To ask when one huge function should be split into to, or when two similar functions should be merged, indicates to me that the design might be flawed. Sometimes that's unavoidable; for instance, if you are involved in a project written by someone else. In that case, you do indeed need to make this kind of decision.
However, true modular programming does not mean taking huge lumbering hunks of code and splitting them into modules. It means writing modules using the principles of information hiding to avoid making huge lumbering hunks of code in the first place.
This, of course, is easier said than done. It's not that hard to avoid gotos, because the use of Dijkstra's structured programming techniques makes them unnecessary. In contrast, writing good modules is hard, and without superhuman foresight, some modules are bound to be pretty crummy. These will need to be rewritten in order to achieve good information hiding properties.
So, there's your answer: don't put the cart before the horse. Don't expect that someone will tell you that you need to split a function when it gets beyond X number of lines. Rather, look at the integrity of the system's modules. If I can leave you with one piece of advice, I hope it is this: design module interfaces not according to what services they provide, but what information they hide. Modules for which you can't find a succinct statement (12 words or less, with no ifs, ands, or ors) of what information they hide are poorly designed, and need an overhaul. A symptom of this may be that your functions are redundant, or too long, but the core problem is one of poor module design.
Hi. I'm a Slashdot-reading Linux advocate, and I think it's outrageous that anyone could be so ignorant as to think that OpenSSH is not secure just because it is Open Source (tm). (Note that it's not freeware. Allow me to list ten differences between freeware and Open Source (tm)...)
Furthermore, OpenSSH is definitely industry-proven and supported. Here are some links to back this up:...
Hey, that's cool. I don't want to minimize the importance of this tool either. The point--I forget where I read it--about trying to imagine using a traditional paint program with the monitor turned off really makes you realize just how hard drawing would be without something like this.
Ok, that's all cool. I'm just reacting to the implicit suggestion that exponential algorithms are a-ok if we just give them enough time. The very nature of exponential algorithms is that extra time doesn't help much.
I have been moded down for the parent post, so apparently my comment is subject to misinterpretation as making fun of the blind. I don't care about the former (as I have reached the karma cap), but the latter bothers me, so I suppose I should explain myself.
I simply meant that Mr. James Landay was grossly overselling the capabilities of this new drawing tool. If I hadn't actually seen the art that had been produced by the tool, his description would have led me to believe it looked more like this or this.
Slashdot Mirror
Granted, we need to take care of the less fortunate. However, if we don't spend money on science and exploration until everyone in the world is 100% equal in every sense of the world, then we will never spend money on science and exploration, and we will stagnate as a species.
I hope I'm wrong, and that we can continue to have a rational discussion about this.
Yes, it sure isn't a good selling point if you pull this two-year time frame out of your ass. What if I told you the time frame is more like six weeks? That would be more in line with my experience. I'm not sure what your point is here. Mine is that you can't disable error checking code unless you know which error checks can safely be disabled. Sure, you can grep for "if", but you need to know the difference between error checks that trap bugs in the program, versus those that catch valid error conditions like user errors.For instance, in a C compiler, you should eventually be able to disable internal data structure consistency checks, but you can never disable parse error checks. In most software, such as business apps, the line between bugs and actual error conditions is not so clear.
The way you tell error conditions from bugs is Design by Contract. To the extent that you can tell these two things apart, you are using DbC, whether you have chosen to do it consciously or not.
This kind of logic is hard to argue with. You dismiss my statement that Design by Contract is more than just an IF statement, and then you claim that because it's just an IF statement, it's worthless. Well, I agree that there's no point in adding glorified IF statements to a language, but I can only emphasize once again that DbC is a design methodology. (Why do you think they call it Design by Contract?)I have already told you that I use DbC to design C code. C obviously doesn't have any special contract syntax, do I'm not sure how you could believe that DbC is just a syntax issue.
There are mountains of resources on the internet describing the DbC technique, and if you want to ignore it and argue against a straw man instead, that's your perogative.
- To add this kind of checking code everywhere throughout the system would be prohibitively slow, even if the errors you are checking for never happen. In contrast, once certain bugs are rare enough, assertion checks can be disabled, and no longer add any performance overhead. Furthermore, even if you never disable assertion checks, DbC makes it clear exactly where they are necessary, so you don't end up with duplicate redundant checks.
- What you have shown is not Design by Contract. DbC is not an implementation technique to check for errors; it's a design methodology to delineate precisely the responsibilities of each class/module/function in a system. Yours is an example of defensive programming, which is basically the opposite of DbC.
Have a look at some of the Design by Contract literature on the web. I promise, it will be time well spent, even if you don't end up using it.I have applied DbC successfully to business apps and system software. I have never written any scientific software, so I can't comment on that.
I'll ignore the freudian slip, and assume you meant that well-worded comments are going to beat the usefulness of assertions. In that case, I disagree with that too:- Nobody ever said assertions in DbC need to be executable. DbC is a design methodology, based on the principle that you should know what the parts of your system are supposed to do. I use DbC when I write my C code, and my contracts take the form of comments.
- Forcing comments to be executable makes them less ambiguous. In this way, Eiffel-style assertions are often preferable to the comments that usually pass for interface documentation.
- Executable contracts are continually double-checked against the implementation code to make sure they agree. Comments can drift and become inaccurate over time.
Good for you. The point of my comparison with type annotations (plus, more importantly, variable declarations and multi-character variable names, which you have ellided) was that redundancy is not always bad. The redundancy argument could also be used against comments; I hope you won't argue that comments are contrary to the "say it once" principle?Ok, so what do you do against a site that disallows browsers without a Referer header, and only allows requests with a Referer that contains a special cooked-up URL with a random number in it, that changes every hour?
This is basically using the Referer header as another form of cookie.
Oh man, this is the funniest thing I have read in a while. You almost made me burst out laughing out loud here at work, which would have been very embarrassing...
I can see it now...
"Why is this computer so lousy? It has been running plenty of... 'Lindows'??"
Now with vitamin R.
There are a number of other reasons I disagree with your assessment:
- The contract and the code do not say the same thing, except for trivial cases. Unfortunately, the kinds of cases shown to beginners must be trivial, so that is all they see.
- In a system designed using DbC, the contracts are far simpler than the implementation. Let's say they're 5 times simpler. Then, even assuming they are entirely redundant (which they aren't), that's only a 20% growth in code size. It's well worth it for DbC's benefits.
- Finding a solution to a problem is generally harder than demonstrating the solution to be correct. This is the basis for the conjecture that P != NP. It is also the basis for DbC: namely, contracts are easier to write than programs, and can demonstrate that a program is working correctly.
- Whatever redundancy there is is a good thing in this case. Stating certain things twice, in two different ways, and having the computer check them against each other, helps to locate errors. The same argument regarding redundancy could be used against type annotations, or variable declarations, or even multi-letter variable names, but most would argue that these kinds of redundancy help program correcness, rather than hindering it.
The most convincing argument in favour of DbC, I think, is Bertrand Meyer's "law of the excluded miracle": if the author of a class/procedure/module doesn't know what it's supposed to do, then the odds that it will do it properly are vanishingly small. Preconditions and postconditions are nothing more than a precise way to specify what something does.My personal opinion regarding OO is that people are disappointed in it for a number of reasons:
- It has been oversold as a panacea, so people become disappointed when they discover that they still need to think.
- It has been represented very poorly by at least one language, C++, which has convinced many that OO is unworkable on large, complex projects.
- Popular OO languages and approaches miss out on Design by Contract, making them far less effective.
- The majority of programmers are simply not skilled enough to architect large enough projects to evaluate a paradigm's scalability. (This same assertion, in a different form, is what led Fred Brooks to promote the surgeon team in The Mythical Man Month twenty years ago.) It is my feeling that skillfully-applied OO wins over some other paradigms (equally skillfully-applied) at the high end of complexity, though I could just be another of those unskilled programmers relying on blind faith in OO.
:-)
Thanks again for the discussion.A nontrivial example won't fit here, so I'll have to refer you to Parnas's original article on the topic. Its example could still be considered trivial by today's standards, but it's far better than anything I could fit in this space. It makes no reference to OO whatsoever. In fact, it's decidedly non-OO, with modules like "circular shifter" and "alphabetizer" that are most certainly procedural abstractions.
If you want a bigger example, there's my Master's thesis work, especially my defence presentation (PowerPoint slides). I consider it a good example of a successful application of information hiding principles, and it's about 23,000 LOC, so it's big enough to be considered nontrivial. It's also OO, so it doesn't prove that OO is orthogonal to information hiding, but I feel that its success arises from information hiding more than OO (especially since it's written in C and so makes no use of inheritance).
How does one show that? Do you have a reference for such a study?The 3rd-generation-versus-assembly is the most clear-cut case of programming language expressive power there is, and yet it's still quite hard to "prove" in any meaningful way.
That's interesting. Do you have any references for this?You're right, of course, that it is too easy to say "you should have designed it right in the first place", and I tried not to say just that, though I may have failed. :-)
I tried to give some advice on how to tell whether a module system is good (that is, by information hiding); and further, to answer his question, my advice would be to refactor whenever he sees that information is not being hidden properly by the system's modules.
I don't get your sig. What's so remarkable about that uptime report? I don't see it.
Yes, but they don't all lie on the same line.
See the problem?
These sound like the wrong questions to me. It reminds me of someone's (perhaps Dijkstra's?) story of the response he received when he recommended abolishing gotos. Someone said "ok, I'll buy that; so what do I do if I'm at this point in the program, and I want to get to that point?"
The trouble with such a question is that it has no answer. Dijkstra's argument was not that one should take existing programs and remove the gotos; rather, that programs written using only structured elements (sequencing, conditionals, loops) are more comprehensible, and don't require any gotos because there is a more elegant way to achieve the same effect. Thus, as you can see, there really is no answer to the question; the questionner's approach was fundamentally flawed.
Likewise, software organization is not done in terms of functions; rather, it is done in terms of information-hiding modules. To ask when one huge function should be split into to, or when two similar functions should be merged, indicates to me that the design might be flawed. Sometimes that's unavoidable; for instance, if you are involved in a project written by someone else. In that case, you do indeed need to make this kind of decision.
However, true modular programming does not mean taking huge lumbering hunks of code and splitting them into modules. It means writing modules using the principles of information hiding to avoid making huge lumbering hunks of code in the first place.
This, of course, is easier said than done. It's not that hard to avoid gotos, because the use of Dijkstra's structured programming techniques makes them unnecessary. In contrast, writing good modules is hard, and without superhuman foresight, some modules are bound to be pretty crummy. These will need to be rewritten in order to achieve good information hiding properties.
So, there's your answer: don't put the cart before the horse. Don't expect that someone will tell you that you need to split a function when it gets beyond X number of lines. Rather, look at the integrity of the system's modules. If I can leave you with one piece of advice, I hope it is this: design module interfaces not according to what services they provide, but what information they hide. Modules for which you can't find a succinct statement (12 words or less, with no ifs, ands, or ors) of what information they hide are poorly designed, and need an overhaul. A symptom of this may be that your functions are redundant, or too long, but the core problem is one of poor module design.
Sheesh. Shame on Cliff for posting this troll.
Hey, that's cool. I don't want to minimize the importance of this tool either. The point--I forget where I read it--about trying to imagine using a traditional paint program with the monitor turned off really makes you realize just how hard drawing would be without something like this.
Ok, that's all cool. I'm just reacting to the implicit suggestion that exponential algorithms are a-ok if we just give them enough time. The very nature of exponential algorithms is that extra time doesn't help much.
I simply meant that Mr. James Landay was grossly overselling the capabilities of this new drawing tool. If I hadn't actually seen the art that had been produced by the tool, his description would have led me to believe it looked more like this or this.