[Haskell-cafe] Object Oriented programming for Functional Programmers
MigMit
miguelimo38 at yandex.ru
Tue Jan 1 21:47:56 CET 2013
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.
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.
On Jan 1, 2013, at 11:41 PM, Mike Meyer <mwm at mired.org> wrote:
>
>
> MigMit <miguelimo38 at yandex.ru> wrote:
>> On Jan 1, 2013, at 10:23 PM, Никитин Лев <leon.v.nikitin at 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.
More information about the Haskell-Cafe
mailing list