On 2013-01-02, at 4:41 AM, MigMit <miguelim...@yandex.ru> wrote: > > On Jan 2, 2013, at 2:26 AM, Bob Hutchison <hutch-li...@recursive.ca> wrote: > >> >> On 2013-01-01, at 3:47 PM, MigMit <miguelim...@yandex.ru> wrote: >> >>> Well, probably one of the reasons is that I've learned Eiffel later than >>> Haskell. >>> >>> But really, "Design by Contract" — a theory? It certainly is a useful >>> approach, but it doesn't seem to be a theory, not until we can actually >>> prove something about it, and Eiffel doesn't seem to offer anything in this >>> direction. >> >> Don't confuse OOSC2 and Eiffel. Eiffel implements the ideas in OOSC2 as best >> as Meyer can, but they are not the same thing. > > Well, we were talking about Eiffel. OOSC2 deserves a few unkind words as > well, but I won't go there. > >> >> And, personally, I think I would be willing to call DbC a theory, or a close >> precursor to a theory. > > I don't know about DbC in general, but it's implementation in Eiffel seems to > be nothing more than a few ASSERT macros, for some weird reason embedded into > the language.
Hmm. I must disagree with you here. I've used three Eiffel systems, ISE, Small/SmartEiffel, and Tower. They all implemented DbC pretty thoroughly. In my opinion, every other implementation of DbC pale in comparison, to the point where they're hardly DbC at all. Are we talking about the same thing? There are three major components (in my opinion) to DbC: pre and post conditions, and class invariants. Pre and post conditions and invariants cannot be implemented simply as asserts. I'll have to refer you to OOSC2 for the (many) details, but a few of the more interesting aspects of these constructs are: 1) error reporting. If a precondition is violated the caller is flagged as the source of the error and error messages, stack traces, etc all reflect the caller. If a post condition is violated it's the callee who is responsible. And the error reports generated are rather good. 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. 3) invariants are not checked for calls within a class (self.method does not have them checked, other.method does) 4) You have access to all the parameters for pre&post conditions, and results for post conditions. Access to the initial state of the object is supposed to be there but I don't think all implementations support that. That's only a brief summary, it goes further than that, again I refer you to OOSC2 (and any of the Eiffel implementations I mentioned, and I don't know of any other implementations). This is nothing like a few assert macros. > >> So, I think, you're saying take away the contracts and the outcome of >> compilation won't be any different. Whereas take away the types and Haskell >> is stopped cold. And that difference makes contracts a 'hack' but types not >> a 'hack'? > > I wasn't clear enough, sorry. I'm sure it's due to sleep deprivation. Or > coffee deprivation. > > See, there are two parts of Eiffel, as I see it. First one is the "contracts" > part. Second is… well, everything else. Second part seems to be doing all the > "real" job, while the first one is doing something invisible, something that > leaves no trace in the final result. Which doesn't mean it's unimportant, of > course. The contracts part is designed to help the other part do it's job, > but not to do the job by itself. Now, there are two problems with that: > > 1) The "real job" part needs helping. And a lot of it, actually, one doesn't > need to look very closely to see that Eiffel type system is extremely unsafe > (for the statically type language). 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. > > 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? 'Resorts' to testing. I have to admit to resorting to testing on occasion myself. Frequent occasion. Routinely even. :-) > > 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? > >> 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. Don't forget that the 'C' in OOSC2 is 'contraction'. Cheers, Bob > >> Pre and post conditions with class invariants are neither types nor unit >> test, something in between. With the wonderful properties of 'useful' and >> 'executable'. >> >> Sometimes you just have to settle for the hacks. >> >> Cheers, >> Bob >> >>> >>> On Jan 1, 2013, at 11:41 PM, Mike Meyer <m...@mired.org> wrote: >>> >>>> >>>> >>>> MigMit <miguelim...@yandex.ru> wrote: >>>>> On Jan 1, 2013, at 10:23 PM, Никитин Лев <leon.v.niki...@pravmail.ru> >>>>> wrote: >>>>>> Eiffel, for my opinion, is a best OOP language. Meyer use a >>>>> theoretical approach as it is possible in OOP. >>>>> Really? Because when I studied it I had a very different impression: >>>>> that behind this language there was no theory at all. And it's only >>>>> feature I remember that is not present in mainstream languages is it's >>>>> pre/postconditions system, which looked like an ugly hack for me. >>>> >>>> I agree with Leon. Of course, I learned it out of OOSC2, which provides >>>> the theory. When compared to "mainstream" OO languages like C++, Java or >>>> Python, it's on a much solider theoretical basis. Compared to something >>>> like Scheme, Haskell or even Clojure, maybe not so much. >>>> >>>> On the other hand, one persons theory is another persons hack. The theory >>>> behind the pre/post conditions is "Design by Contract". The contracts are >>>> as important as the type signature, and show up in the auto-generated docs >>>> in eiffel systems. I found at least one attempt to add DbC features to >>>> Haskell. I'm not sold on it as a programming technique - the bugs it >>>> uncovers are as likely to be in the pre/post conditions as in the code. >>>> >>>> >>>> -- >>>> Sent from my Android tablet with K-9 Mail. Please excuse my swyping. >>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe@haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
