2) pre&post conditions and class invariants have defined behaviour in cases of inheritance, even/especially multiple inheritance. They are combined non-trivially in subclasses. Without this I don't think you have DbC.
Yes, I forgot about that. Thanks.
Feel free to enlighten me about these obvious and extremely unsafe aspects of Eiffel's type system. Personally, I can't say I ever noticed.
Correct me if I'm wrong, but isn't it true that methods can be removed in subclasses? If that's not extreme, I don't know what is.
2) The "contracts" part does a very poor job. Instead of really improving the inherent unsafety, it resorts to testing. And…
What constitutes a 'good' job?
Well, a sound type system would certainly help.
'Resorts' to testing. I have to admit to resorting to testing on occasion myself. Frequent occasion. Routinely even. :-)
You routinely try to overcome language weakness with tests?
2') ...not even the real, thorough testing — contracts system would be quite happy if the program works on the developer's machine. Which is the "works for me" approach certain languages gets rightfully blamed for.
Really? You believe that automated testing and contracts are why software bugs *are not* found?
Is that what I said? I believe that testing means a lot more than just making sure the program works on the developer's computer. I believe that system that encourages the "works for me" approach is one of the reasons software bugs are not found.
Seems to me you're ignoring everything that happens between an empty directory and a working program. Contracts help in that process (I say but can't prove).
I agree. They do help — but there are lots of things that help in this transition. Versioning systems. Collaboration tools. Bug tracking software. Text editors. Even debuggers.
You should read OOSC2. You'll find that this is completely consistent with it.
I've never said it's not. But all of these tools are external to the language, which means that they can be easily replaced if a better alternative surfaces.