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. And, personally, I think I would be willing to call DbC a theory, or a close precursor to a theory. > > And by "hack" I meant not the presence of pre/postconditions, but the fact > that they don't affect anything else. Strip all of them away, and you'll have > the program which is, essentially, the same (and, in fact, pre/postconditions > are supposed to be removed in the final version of the program). > Compare this to Haskell types, for example: an untyped version of Haskell > won't be able to choose between two class instances, so, that would be an > entirely different language. 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'? 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). Call that a 'hack' if you want, but I'll take as many of those kinds of hacks as I can get if they're anywhere near as good as contracts. 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
