[Haskell-cafe] Object Oriented programming for Functional Programmers
Daniel Díaz Casanueva
But all these languages were in my life as secondary languages, being Haskell my predominant preference. Haskell was the first programming language I learned, and subsequent languages never seemed so natural and worthwhile to me. In fact, every time I had to use another language, I created a combinator library in Haskell to write it (this was the reason that brought me to start with the HaTeX library). Of course, this practice wasn't always the best approach.
Jay Sulzberger
programming". Here is what Alan Kay once said about C++:
Actually I made up the term "object-oriented", and I can tell
you I did not have C++ in mind.
Above quote from
http://en.wikiquote.org/wiki/Alan_Kay
[page was last modified on 30 November 2012, at 16:06]
For me the most important things about "objects" are:
1. In the World of the Programming System there is a version of
Lisp's eq?, ah that word is the Scheme word.
2. Really, objects are what are now called "agents".
The word "inheritance" does not appear in the first 600^W300
pages of my Ideal Textbook on the Theory of Objects in
Programming.
oo--JS.
MigMit
Also, as Daniel told you already, don't start from C++, it really has very little to do with OOP. It's primary merit is a very powerful system of macros (called "templates" in C++ world), not objects. If you want something mainstream, Java would be a good choice, and C# even better one (although it would be more convenient for you if you use Windows).
Or you can try OCaml, which is functional enough for you not to feel lost, and object-oriented as well.
Отправлено с iPad
30.12.2012, в 23:58, Daniel Díaz Casanueva <dhelt...@gmail.com> написал(а):
> _______________________________________________
> Haskell-Cafe mailing list
> Haskel...@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________
Haskell-Cafe mailing list
Haskel...@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
MigMit
Отправлено с iPad
30.12.2012, в 23:58, Daniel Díaz Casanueva <dhelt...@gmail.com> написал(а):
> Hello, Haskell Cafe folks.
Eli Frey
As for things to watch out for.
There is a very strong duality between TypeClasses and existential polymorphism in OO. Both require a way to dynamically look up the correct implementation for the type you are operating upon. In Haskell we use Typeclasses which place this lookup table on the functions that have existential constraints on them.
> mconcat :: Monad m => [m] -> m
> mconcat = foldl mappend []
We can think of `mconcat` having a little lookup table inside of itself, and whenever we pass it a concrete `[m]`, `mappend` gets looked up and we get the implementation for `m`. Typeclasses are just mappings from types to functions
In OO on the other hand, the lookup table is attached to the datastructure. We can think of the Object as a mapping from function names to functions that operate on that Object. Python, Javascript, Ruby, and of course Smalltalk make this quite explicit.
Aside from Object Orientation, it is probably a good idea to learn some C for a bit too. C is a good language to play in and try and implement more advanced language features. Once you reallize that objects are just lookup tables of functions bound with a data-structure, you can implement your own in C, or you can make closures as functions bundled with (some) of their arguments, or you can implement interesting datastructures, or so many other fun things. A good understanding of tagged unions has helped me in many a convo with an OO head.
Brandon Allbery
> mconcat :: Monad m => [m] -> m
> mconcat = foldl mappend []
We can think of `mconcat` having a little lookup table inside of itself, and whenever we pass it a concrete `[m]`, `mappend` gets looked up and we get the implementation for `m`. Typeclasses are just mappings from types to functions
Aside from Object Orientation, it is probably a good idea to learn some C for a bit too. C is a good language to play in and try and implement more advanced language features. Once you reallize that objects are just lookup tables of functions bound with a data-structure, you can implement your own in C, or you can make closures as functions bundled with (some) of their arguments, or you can implement interesting datastructures, or so many other fun things. A good understanding of tagged unions has helped me in many a convo with an OO head.
Eli Frey
From: Eli Frey <eli.le...@gmail.com>
Date: Sun, Dec 30, 2012 at 1:56 PM
Subject: Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
To: Brandon Allbery <allb...@gmail.com>
I'll admit this doesn't HAVE to be the implementation. Often time the compiler can monomorphise the types and "perform the lookup" at compile time.
But what's going on here tho.
> {-# LANGUAGE ExistentialQuantification #-}
>
> printShowable :: Showable -> IO ()
> printShowable (Showable x) = print x
>
> main = mapM printShowable [ Showable "bob", Showable 3, Showable Nothing ]
If we take `mapM printShowable` and just give it an arbitrary list, it has to lookup the correct implementations of `print` as it walks down that list at run-time. I believe similar things motivate vtables in c++/java. I don't have a strong intuition about how dynamically typed OO langs deal with this, but I'm sure structural typing has similar issues.
Timon Gehr
The Showable constructor has two parameters. The 'Show' instance for 'a'
(passed implicitly) and an 'a' (passed explicitly). When pattern
matching, that instance gets unwrapped together with the payload. It is
then implicitly passed to 'print', which finally uses it to look up the
correct implementation of 'show'.
Rustom Mody
* Is it really worthwhile for me to learn OO-programming?So my questions for you all are:Well, my curiosity is bringing me to learn a new general purpose programming language. Haskellers are frequently comparing Object-Oriented languages with Haskell itself, but I have never programmed in any OO-language! (perhaps this is an uncommon case) I thought it could be good to me (as a programmer) to learn C/C++. Many interesting courses (most of them) use these languages and I feel like limited for being a Haskell programmer. It looks like I have to learn imperative programming (with side effects all over around) in some point of my programming life.But, why I am writing this to you, haskellers?Hello, Haskell Cafe folks.My programming life (which has started about 3-4 years ago) has always been in the functional paradigm. Eventually, I had to program in Pascal and Prolog for my University (where I learned Haskell). I also did some PHP, SQL and HTML while building some web sites, languages that I taught to myself. I have never had any contact with JavaScript though.
But all these languages were in my life as secondary languages, being Haskell my predominant preference. Haskell was the first programming language I learned, and subsequent languages never seemed so natural and worthwhile to me. In fact, every time I had to use another language, I created a combinator library in Haskell to write it (this was the reason that brought me to start with the HaTeX library). Of course, this practice wasn't always the best approach.
Ive been collecting material regarding (confusions around) OO. Its far from complete but the references may be useful, eg
- the Rees list on the different things that OO means to different people
- the fundamental philosophical differences between commitment to declarativeness and imperativeness -- in philosophical language rationalism and empiricism
As I said, its still in the early stage of bits and pieces being collected...
http://blog.languager.org/2012/07/we-dont-need-no-ooooo-orientation-2.html
* If so, where should I start? There are plenty of "functional programming for OO programmers" but I have never seen "OO programming for functional programmers".
In the C++ world Stepanov is almost on par with Stroupstrup. His STL has transformed C++ practices more than anything else
Good to read his views on OOP
http://en.wikipedia.org/wiki/Alexander_Stepanov#Criticism_of_OOP
http://www.the-magus.in
http://blog.languager.org
Rustom Mody
Ive been collecting material regarding (confusions around) OO. Its far from complete but the references may be useful, eg
- the Rees list on the different things that OO means to different people
- the fundamental philosophical differences between commitment to declarativeness and imperativeness -- in philosophical language rationalism and empiricism
As I said, its still in the early stage of bits and pieces being collected...
http://blog.languager.org/2012/07/we-dont-need-no-ooooo-orientation-2.html
* If so, where should I start? There are plenty of "functional programming for OO programmers" but I have never seen "OO programming for functional programmers".
In the C++ world Stepanov is almost on par with Stroupstrup. His STL has transformed C++ practices more than anything else
Good to read his views on OOP
http://en.wikipedia.org/wiki/Alexander_Stepanov#Criticism_of_OOP
In a field like ours its as important to be able to wear a technical/mathematical hat as a social or political one.
And when the latter, its good to be able to participate in a discussion in which inheritance, UML etc etc figures.
Jay Sulzberger
On Mon, 31 Dec 2012, MigMit <migue...@yandex.ru> wrote:
> Well, "functional programmer" is a relatively broad term. If
> you're coming from academia, so that for you Haskell is some
> sort of lambda-calculus, spoiled by practical aspects, then I'd
> suggest Luca Cardelli's book "Theory of Objects".
>
> Also, as Daniel told you already, don't start from C++, it
> really has very little to do with OOP. It's primary merit is a
> very powerful system of macros (called "templates" in C++
> world), not objects. If you want something mainstream, Java
> would be a good choice, and C# even better one (although it
> would be more convenient for you if you use Windows).
>
> Or you can try OCaml, which is functional enough for you not to
> feel lost, and object-oriented as well.
>
> Отправлено с iPad
Smalltalk, Common Lisp, and Erlang. My guess is that Haskell's
type classes are a mechanism for creating something like Common
Lisp's "generic functions". I know too little about Haskell to
say whether type classes immediately give you "single dispatch"
things, or "multiple dispatch" things.
These two Wikipedia articles are useful, I think:
http://en.wikipedia.org/wiki/Generic_function
[page was last modified on 15 November 2012 at 03:50]
http://en.wikipedia.org/wiki/Common_Lisp_Object_System
[page was last modified on 15 December 2012 at 23:57]
The Diamond Problem and its cousin(s) are worth looking at:
http://en.wikipedia.org/wiki/Diamond_problem#The_diamond_problem
[page was last modified on 27 December 2012 at 04:53]
http://www.ibm.com/developerworks/java/library/j-clojure-protocols/
http://stackoverflow.com/questions/4509782/simple-explanation-of-clojure-protocols
oo--JS.
Jay Sulzberger
http://www.gigamonkeys.com/book/object-reorientation-generic-functions.html
oo--JS.
Eric Rasmussen
Scala has a mix of functional and OO programming styles, though (having come first from Haskell) I'd say it favors the OO side. If you approach it as OO with some nice functional touches (higher level list operations, immutability, recursively defined data structures, and pattern matching), it can be very fun to work with.
Scala's type system is also more expressive than the other OO languages I've worked with, which is a big plus if you're coming from Haskell. Learning about subtyping and variance annotations via Scala gives you tools for reasoning about objects that you won't get from dynamically typed OO languages.
Kim-Ee Yeoh
Heinrich Apfelmus
Personally, I don't think that learning an imperative OO language will
"expand your mind" in a way that Haskell does. I have started with
Pascal and later C, but once I learned about Haskell, I switched to it
immediately for virtually all my programming tasks and never looked back.
The only thing that OO languages are good for are "legacy" systems,
where no Haskell compiler is readily available. If you have a concrete
project in mind, like an Android or iPhone app, or a client-heavy web
application, it is certainly worthwhile to learn the relevant language
(Java, Objective-C, JavaScript) in order to make your ideas a reality.
But other than that, you already know Pascal and programming in these
languages is not very different.
Best regards,
Heinrich Apfelmus
Strake
On 30/12/2012, Daniel Díaz Casanueva <dhelt...@gmail.com> wrote:
> My programming life (which has started about 3-4 years ago) has always been
> in the functional paradigm. Eventually, I had to program in Pascal and
> Prolog for my University (where I learned Haskell). I also did some PHP,
> SQL and HTML while building some web sites, languages that I taught to
> myself. I have never had any contact with JavaScript though.
>
> ...
>
> I thought it could be good to me (as a programmer) to learn C/C++.
> It looks like I have to learn imperative programming (with side effects all over around) in some point of my programming life.
Have to, no. Ought to, yes. As Turing-equivalent computers are
essentially imperative, imperative code is nearest to the actions of
the machine. Ergo asm may seem the best choice, but not so: C is the
wiser choice, as it is machine-agnostic, widely used, and often clear
and effective.
I never used pascal, and after I read this:
http://www.lysator.liu.se/c/bwk-on-pascal.html
I care not to do.
> So my questions for you all are:
>
> * Is it really worthwhile for me to learn OO-programming?
Likely. Some code is most readily written in objective style.
> * If so, where should I start? There are plenty of "functional programming
> for OO programmers" but I have never seen "OO programming for functional
> programmers".
Smalltalk.
> * Is it true that learning other programming languages leads to a better
> use of your favorite programming language?
Yes. Either one gains an awareness of certain biases and assumptions
made while using prior languages, or else the new language becomes
one's favorite (^_~)
> * Will I learn new programming strategies that I can use back in the
> Haskell world?
Maybe. I honestly can't say a priori, but it's a win to know the
alternatives. I have done some OO, and a few times while writing in
Haskell, the objective model came to mind first, tho in many cases it
is cumbersome in Haskell.
Cheers,
Strake
Mike Meyer
> Disclaimer: My own experience with OO is limited.
> On 30/12/2012, Daniel Díaz Casanueva <dhelt...@gmail.com> wrote:
>> My programming life (which has started about 3-4 years ago) has always been
>> in the functional paradigm. Eventually, I had to program in Pascal and
>> Prolog for my University (where I learned Haskell). I also did some PHP,
>> SQL and HTML while building some web sites, languages that I taught to
>> myself. I have never had any contact with JavaScript though.
>>
>> ...
>>
>> I thought it could be good to me (as a programmer) to learn C/C++.
>> It looks like I have to learn imperative programming (with side effects all over around) in some point of my programming life.
>>
>> * Is it really worthwhile for me to learn OO-programming?
> Likely. Some code is most readily written in objective style.
new set of tools for approaching programming problems. Of course, the
single worst thing you can do is try and force a paradigm onto a
language that isn't meant for it.
>> * If so, where should I start? There are plenty of "functional programming
>> for OO programmers" but I have never seen "OO programming for functional
>> programmers".
> Smalltalk.
because it means you can use Meyer's (no relation) Object Oriented
Software Construction as a text. Unfortunately, you'll have to buy a
dead trees copy of that text. It not only covers OO programming, but
explains why things are the way they are, why the way C++ is is wrong,
and provides an introduction to design-by-contract as well.
<mike
Bob Hutchison
Well, my curiosity is bringing me to learn a new general purpose programming language. Haskellers are frequently comparing Object-Oriented languages with Haskell itself, but I have never programmed in any OO-language! (perhaps this is an uncommon case) I thought it could be good to me (as a programmer) to learn C/C++. Many interesting courses (most of them) use these languages and I feel like limited for being a Haskell programmer. It looks like I have to learn imperative programming (with side effects all over around) in some point of my programming life.
So my questions for you all are:
* Is it really worthwhile for me to learn OO-programming?
As for languages I'd suggest Smalltalk or Eiffel, perhaps both. The big advantage to Eiffel is that you have Object Oriented Software Construction (second edition (not first)) to work from. Every OO language has to answer to the issues brought up in OOSC2 (and they don't/can't). Eiffel's inheritance mechanism is also one of the few that let you use inheritance to do useful things (OOSC2 names 16 or 18 different uses for inheritance… it's not just for 'is-a' relationships). Eiffel also has a contract system that's powerful enough to be useful. Smalltalk's advantage is that it will also introduce you to the idea of a programming 'system', for lack of better words. Smalltalk works in a live system, as you are writing code you are modifying live and already executing code. Once you realize that the 'best' editor in Smalltalk is the debugger (and what 'a good debugger' actually means) you'll understand test-driven-development's origins. This is very different from Haskell. Actually, you should probably learn both languages.
I don't think C++ will help you learn OO, or much of anything else either. Vigorously avoid is my advice.
C you're probably going to have to learn sooner or later but wait until you have to. And it's not OO at all. Though, if you learn K&R C (pre-ansi C) you'll get a better understanding of why people liked OO so much :-)
Ruby might be an easy route to OO too. I like the language quite a lot, but I'm not sure I'd recommend it for your purposes.
* If so, where should I start? There are plenty of "functional programming for OO programmers" but I have never seen "OO programming for functional programmers".
* Is it true that learning other programming languages leads to a better use of your favorite programming language?
* Will I learn new programming strategies that I can use back in the Haskell world?
Cheers,
Bob
Thanks in advance for your kind responses,
Daniel Díaz.
Alexander Solla
Rico Moorman
We should first examine the merits and limitations of the traditional approach: using
functions as a basis for the architecture of software systems. This will not only lead us to
appreciate why we need something else — object technology — but also help us avoid,
when we do move into the object world, certain methodological pitfalls such as premature
operation ordering, which have been known to fool even experienced O-O developers.
Brandon Allbery
We should first examine the merits and limitations of the traditional approach: using
functions as a basis for the architecture of software systems. This will not only lead us to
Because you both have more experience with this piece of literature, how would you interpret it? With a grain of salt or would function really mean procedure from the viewpoint of the author?
Bob Hutchison
Hello Bob and Mike,Reading a little within the suggested book I came across the following statement.We should first examine the merits and limitations of the traditional approach: using
functions as a basis for the architecture of software systems. This will not only lead us to
appreciate why we need something else — object technology — but also help us avoid,
when we do move into the object world, certain methodological pitfalls such as premature
operation ordering, which have been known to fool even experienced O-O developers.Because you both have more experience with this piece of literature, how would you interpret it? With a grain of salt or would function really mean procedure from the viewpoint of the author?
Никитин Лев
,
MigMit
On Jan 1, 2013, at 10:23 PM, Никитин Лев <leon.v....@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.
Of course, my memory could fail me, but I doubt my tutorial did; I remember it being written by Meyer himself.
Mike Meyer
MigMit <migue...@yandex.ru> wrote:
>On Jan 1, 2013, at 10:23 PM, Никитин Лев <leon.v....@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.
MigMit
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.
Bob Hutchison
On 2013-01-01, at 3:47 PM, MigMit <migue...@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
wren ng thornton
> Hello Bob and Mike,
>
> Reading a little within the suggested book I came across the following
> statement.
>
>> We should first examine the merits and limitations of the traditional
>> approach: using
>> functions as a basis for the architecture of software systems. This will
>> not only lead us to
>> appreciate why we need something else — object technology — but also help
>> us avoid,
>> when we do move into the object world, certain methodological pitfalls
>> such as premature
>> operation ordering, which have been known to fool even experienced O-O
>> developers.
>
> Because you both have more experience with this piece of literature, how
> would you interpret it? With a grain of salt or would function really mean
> procedure from the viewpoint of the author?
you encounter "function" in most any imperative or OO setting, it almost
certainly means a first-order procedure. No mathematical functions. No
higher-order thingamabobs that you can pass to or return from other
thingamabobs. Just an address in code with an expected stack frame
configuration associated with it.
As for learning object orientation, I'd second the suggestion of
Smalltalk. I'll leave the religious wars aside, but "OOP" means very
different things to very different people. Most people use the term
whilst referring to C++ and Java, but most people recognize that the
ideological framework is best attained by Smalltalk (and related
languages like Ruby). So, if you're interested in learning the ideology,
then Smalltalk is a great place to get it.
Also, Smalltalk has the "become" method, which is amazing magic.
--
Live well,
~wren
Никитин Лев
Mike Meyer
[Context destroyed by top posting.]
MigMit <migue...@yandex.ru> wrote:
>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.
You just stated (briefly, and not very rigorously) the theory: DbC is a useful approach to programing. Note that it's a theory about *programming*, not the resulting program.
>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.
Type classes are the wrong feature to look at. Type signatures are closer to what DbC is. Are type signatures a hack to get around deficiencies in the type inferencing engine? After all, you can strip all of them away and have essentially the same program.
Personally, I think the answer is "no", and for the same reason. We add type signatures to top level functions because it helps document the function, and to help isolate type errors during compilation. They makes *programming* easier, even if they don't change the program at all. Pre and Post conditions (and class invariants - they're also part of DbC!) serve pretty much the same function. They help document the classes and methods, and tools that generate class/method documentation from source always include them. They're as important as the type signature. They also help isolate bugs, in that you get told explicitly that routine foo passed in an invalid parameter to bar rather than an exception somewhere deep in the guts of bar that you have to work back from to find foo.
As I said before, I'm not sure I agree that the latter is worth the cost of using them for anything complex. The bugs they uncover are as likely to be in the pre/post conditions as in the code proper. The documentation benefit is unquestionable, though. And if some condition is worth documenting, then having it as executable documentation means it gets tested with the rest of the code, so you know the documentation is correct. Which means that just adding conditions to a language misses most of the benefit of DbC. You need to fix the documentation system as well.
This is the kind of theory that you'll find in OOSC: why the features that are there help make programming easier. Not theories about how they make the resulting program better. Those two have a lot in common, though. Anything that makes witing correct code easier generally results in a better program.
MigMit
On Jan 2, 2013, at 2:26 AM, Bob Hutchison <hutch...@recursive.ca> wrote:
>
> On 2013-01-01, at 3:47 PM, MigMit <migue...@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.
> 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).
2) The "contracts" part does a very poor job. Instead of really improving the inherent unsafety, it resorts to testing. And...
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.
> 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.
MigMit
On Jan 2, 2013, at 8:44 AM, Никитин Лев <leon.v....@pravmail.ru> wrote:
> I said "theoratical", but not "mathematical" or "a scientific" theory.
Than what kind of theory did you mean?
> <image1.gif> Meyer have built a quite coherent construction in comparison with other OOP langs.
More than Smalltalk, for example?
MigMit
On Jan 2, 2013, at 10:52 AM, Mike Meyer <m...@mired.org> wrote:
>
>
> [Context destroyed by top posting.]
> MigMit <migue...@yandex.ru> wrote:
>> 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.
>
> You just stated (briefly, and not very rigorously) the theory: DbC is a useful approach to programing. Note that it's a theory about *programming*, not the resulting program.
> Type classes are the wrong feature to look at. Type signatures are closer to what DbC is. Are type signatures a hack to get around deficiencies in the type inferencing engine? After all, you can strip all of them away and have essentially the same program.
Mike Meyer
MigMit <migue...@yandex.ru> wrote:
> On Jan 2, 2013, at 10:52 AM, Mike Meyer <m...@mired.org> wrote:
> > MigMit <migue...@yandex.ru> wrote:
> >> 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.
> > You just stated (briefly, and not very rigorously) the theory: DbC is a useful approach to programing. Note that it's a theory about *programming*, not the resulting program.
> Well, you can call that a theory, for sure. But I think it's usually called an "observation".
An "observation" is what you make to decide if a theory is true or
not. In order to make the observation (at least for theories about
helping programmers) you need an implementation so you can observe
people using it.
> I always thought the theory is something that allows us to develop
> some new knowledge.
Yup. Deciding whether or not the theory is true *is* a development of
new knowledge. I can say for a certainty that the documentation aspect
of DbC makes me more productive. The testing aspect of it needs more
testing (sorry).
> Just stating that "comfortable chairs make programmers more
> productive" doesn't constitute a theory.
Well, it's not very rigorous, and I can think of some
counterexamples. On the other hand, if you reparaphrased (sic) it as
"Chairs that encourage good posture make programmers more productive",
then you have a honest-to-goodness theory. Better yet, it's one that's
been thoroughly tested in ergonomics labs around the world.
At this point, we're arguing about the semantics of the word
"theory".
On Wed, 2 Jan 2013 13:41:54 +0400
MigMit <migue...@yandex.ru> wrote:
> 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.
Either you used a particularly poor implementation of Eiffel, or you
didn't look at the implementation beyond writing them out. Every
Eiffel system I've used included tools that computed the contracts on
a method or class (remember, class invariants apply to subclasses,
etc.) and displayed them. Those are just as much part of DbC as the
"assert macros".
If you ignore that usage, you've correctly described things. At least
as well as saying that a function call implementation is a goto that
records a return address, for some weird reason embedded into the
language. Or <higher level construct> is just <implementation method>,
for some weird reason embedded into the language.
The "weird reason" is pretty much always the same: the construct in
question carries more semantic meaning than the implementation
method. Functions capture the notion of a distinct, reusable chunk of
code, that can have properties all it's own. This is a major step up
from just having a goto variant with an otog that undoes it.
Likewise, pre and post (and invariant) conditions capture the notion
of a contract. They express the terms of the contract implemented by
some specific bit of code. The contract is part of the interface to
that code. If you're actually doing DbC, it's no less important than
the rest of the interface. Like, for instance, the type signature.
Personally, I don't believe in turning off the conditions, for much
the same reason I don't believe in turning off array bounds
checking. I think it's better to get the right answer later than to
get the wrong answer now.
<mike
--
Mike Meyer <m...@mired.org> http://www.mired.org/
Independent Software developer/SCM consultant, email for more information.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
Никитин Лев
Никитин Лев
Bob Hutchison
On 2013-01-02, at 4:41 AM, MigMit <migue...@yandex.ru> wrote:
>
> On Jan 2, 2013, at 2:26 AM, Bob Hutchison <hutch...@recursive.ca> wrote:
>
>>
>> On 2013-01-01, at 3:47 PM, MigMit <migue...@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
Bob Hutchison
On 2013-01-02, at 7:56 AM, Bob Hutchison <hutch...@recursive.ca> wrote:
>
> You should read OOSC2. You'll find that this is completely consistent with it. Don't forget that the 'C' in OOSC2 is 'contraction'.
Emanuel Koczwara
First, I see (posts on this mailing list) that OO ideas are well known
in functional community :)
>
> So my questions for you all are:
>
>
> * Is it really worthwhile for me to learn OO-programming?
>
>
to discover: UML, design patterns, classes and objects, data structures
based on 'pointers' (and you can modify them, surprise!) and of course
many algorithms that work on this structures (please note, that many
books about algorithms and data structures take imperative approach), OO
databases, many many many libraries for almost any thing! and finally,
you will be able to try stable, well known and widely used tools (think
about GUIs, game engines, embedded systems, mobile devices and all this
fascinating stuff you can do with them).
> * If so, where should I start? There are plenty of "functional
> programming for OO programmers" but I have never seen "OO programming
> for functional programmers".
>
with fresh mind. Do _all_ exercises from that book.
>
> * Is it true that learning other programming languages leads to a
> better use of your favorite programming language?
>
>
skills also.
> * Will I learn new programming strategies that I can use back in the
> Haskell world?
>
would go with C++, then you will also learn some C by the way, FFI is
waiting..
>
> Thanks in advance for your kind responses,
>
Emanuel
Bob Hutchison
On 2013-01-02, at 1:52 AM, Mike Meyer <m...@mired.org> wrote:
>
>
> [Context destroyed by top posting.]
> MigMit <migue...@yandex.ru> wrote:
>> 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.
>
> You just stated (briefly, and not very rigorously) the theory: DbC is a useful approach to programing. Note that it's a theory about *programming*, not the resulting program.
>
>> 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.
>
> Type classes are the wrong feature to look at. Type signatures are closer to what DbC is. Are type signatures a hack to get around deficiencies in the type inferencing engine? After all, you can strip all of them away and have essentially the same program.
DbC is closely related to the management of state, and so to the object as a whole not just the parameters to a method. Now, I'm no expert in Haskell so treat the next part of this paragraph accordingly... putting invariants and conditions on monads, in particular to the entry and exit from do notation might be interesting. No particular ideas as to how you'd do that, or even if it'd be useful, but it seems to me to be a bit closer to the level of abstraction where DbC is at in Eiffel.
>
> Personally, I think the answer is "no", and for the same reason. We add type signatures to top level functions because it helps document the function, and to help isolate type errors during compilation. They makes *programming* easier, even if they don't change the program at all. Pre and Post conditions (and class invariants - they're also part of DbC!) serve pretty much the same function. They help document the classes and methods, and tools that generate class/method documentation from source always include them. They're as important as the type signature. They also help isolate bugs, in that you get told explicitly that routine foo passed in an invalid parameter to bar rather than an exception somewhere deep in the guts of bar that you have to work back from to find foo.
>
> As I said before, I'm not sure I agree that the latter is worth the cost of using them for anything complex. The bugs they uncover are as likely to be in the pre/post conditions as in the code proper. The documentation benefit is unquestionable, though. And if some condition is worth documenting, then having it as executable documentation means it gets tested with the rest of the code, so you know the documentation is correct. Which means that just adding conditions to a language misses most of the benefit of DbC. You need to fix the documentation system as well.
MigMit
On Jan 2, 2013, at 4:24 PM, Никитин Лев <leon.v....@pravmail.ru> wrote:
>
> Well, we can say "concepts" in place of "theory". And I'm comparing Eiffel with other OOP lang, not with some langs based on a solid math theory (lambda calcules for FP langs, for example). ok?
I agree that there are certain concepts, or ideas, that Eiffel is built on. If that is what you meant, sure, I have no problem with that.
Of course, there are plenty of languages based on some specific ideas. For example, take the following concepts: 1) it's better to do something instead of failing, even if it doesn't make any sense; 2) global is better then local; 3) for every feature that can be implemented in two ways there should be a switch that the user can set as xe wishes. Implement these as fully as possible — and you'll get PHP.
So, somehow I doubt that being based on some set of ideas is a very strong selling point.
> BTW. Why you think that Eiffel type system is unsafe?
Well, if I remember correctly, if you call some method of a certain object, and this call compiles, you can't be certain that this object actually has this method. Could be that this object belongs to some subclass which removes this method.
MigMit
> 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?
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.
Gershom Bazerman
>
>> BTW. Why you think that Eiffel type system is unsafe?
> Well, if I remember correctly, if you call some method of a certain object, and this call compiles, you can't be certain that this object actually has this method. Could be that this object belongs to some subclass which removes this method.
>
arguments with subtyping in a principled way. This is apparently known
as the "catcall" problem. See, e.g., this article:
http://www.eiffelroom.org/node/517
--Gershom
MigMit
On Jan 3, 2013, at 2:09 AM, Gershom Bazerman <gers...@gmail.com> wrote:
> On 1/2/13 4:29 PM, MigMit wrote:
>>
>>> BTW. Why you think that Eiffel type system is unsafe?
>> Well, if I remember correctly, if you call some method of a certain object, and this call compiles, you can't be certain that this object actually has this method. Could be that this object belongs to some subclass which removes this method.
>>
>
> Eiffel doesn't handle the relationship of co- and contra-variance of arguments with subtyping in a principled way. This is apparently known as the "catcall" problem. See, e.g., this article: http://www.eiffelroom.org/node/517
Alberto G. Corona
Alberto.
Timon Gehr
> Anyway, Type checking is essentially an application of set theory : (I
> did no search in te literature for this, It is just my perception).
alternative to set theory.
> When
> I say (+) :: Num a => a -> a -> a . I mean that (+) takes two elements
> of the set of Num typeclass and return another.
inhabitants would need to be be types, thus this describes a type-level
mapping.
This is a more accurate description, (but there might be a better one):
(+) : (a : Type)->(i : (Num a : Prop))->(x : a)->(y : a)->(z : a)
(+) is a mapping from types 'a' to mappings from proofs 'i' of the
proposition that 'a' is an instance of the 'Num' type class to a curried
function that takes two arguments of type 'a' and produces a result of
type 'a'.
> This is in principle a
> weak restriction, because many functions do it as well, for example (*).
>
> A propery check or a contract would be much more restrictive and thus
> would detect much more program errors. But it seems that no other
> language but haskell took this set theoretical analysis so exhaustively,
http://wiki.portal.chalmers.se/agda/pmwiki.php
> and without it, a property check is like detecting microscopic cracks in
> nuclear waste vessel without first making sure that the cover has been
> sealed.
>
Timon Gehr
>
> On Jan 3, 2013, at 2:09 AM, Gershom Bazerman <gers...@gmail.com> wrote:
>
>> On 1/2/13 4:29 PM, MigMit wrote:
>>>
>>>> BTW. Why you think that Eiffel type system is unsafe?
>>> Well, if I remember correctly, if you call some method of a certain object, and this call compiles, you can't be certain that this object actually has this method. Could be that this object belongs to some subclass which removes this method.
>>>
>>
>> Eiffel doesn't handle the relationship of co- and contra-variance of arguments with subtyping in a principled way. This is apparently known as the "catcall" problem. See, e.g., this article: http://www.eiffelroom.org/node/517
>
> Yes, variance is another big source of unsafety, that's for sure. And another reason I think there is no real "theory" behind Eiffel, just a bunch of features (or "concepts") boiled together.
>
http://tecomp.sourceforge.net/index.php?file=doc/papers/proof/
The resulting language appears to be type safe:
http://tecomp.sourceforge.net/index.php?file=doc/papers/lang/modern_eiffel.txt#chapter_20
David Thomas
[T]he "Monad m =>" in the signature really means "hey, compiler, pass me the appropriate implementation of Monad so I can figure out what I'm doing with this type m". It's not a built in table, it's a hidden parameter.
Kim-Ee Yeoh
Well, "hidden" - it *is* right there in the type signature still, it just doesn't *look* like an argument.
It also might be optimized away in static cases (certainly, it *could* happen, whether does or is even worthwhile is another question).
