This page looks to be a good introduction to CLOS: http://www.gigamonkeys.com/book/object-reorientation-generic-functions.html oo--JS. On Sun, 30 Dec 2012, Jay Sulzberger wrote:

On Mon, 31 Dec 2012, MigMit 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

Name typo, should be "Jay", noted.

...

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

For systems to look at I recommend Simula, some early version, 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-pro...

oo--JS.

30.12.2012, в 23:58, Daniel Díaz Casanueva написал(а):

...

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.

But, why I am writing this to you, haskellers?

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?

* 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?

Thanks in advance for your kind responses, Daniel Díaz. _______________________________________________ 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

On Sun, Dec 30, 2012 at 3:45 PM, Eli Frey wrote:

...

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

Except not quite... the "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. 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.

A perhaps strange suggestion in this vein: dig up the source code for Xt, the old X11 Toolkit, and the Xaw widget library that is built atop it. (It's part of the X11 source tree, since most of the basic X11 utilities and xterm are based on it.) It implements a primitive object system in C. Gtk+ does the same, but hides much of the implementation behind macros and relies on tricky casting etc. behind the scenes for performance; in Xt, the basic machinery is more easily visible for inspection and much easier to understand even if you're not all that familiar with C. If you go this way, once you've figured out what Xt is doing you might go on to see the more advanced concepts in how Gtk+ does it. And once you've done this, you'll have a good idea of what Objective-C and C++ (minus templates) are doing under the covers. (Mostly C++, since ObjC is more or less Smalltalk's OO on top of X, whereas the core concepts of C++ are not so very different from what Xt does.) If you really want to dig in further, you might want to try to find the source to cfront, the original C++ implementation which was a preprocessor for the C compiler. It'll be missing a lot of modern C++ features, but the core is there. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

On Fri, Jan 4, 2013 at 7:27 PM, David Thomas wrote:

Well, "hidden" - it *is* right there in the type signature still, it just doesn't *look* like an argument.

If you squint hard enough, (=>) looks like (->). Or maybe the other way round. Whatever. :)

It also might be optimized away in static cases (certainly, it *could* happen, whether does or is even worthwhile is another question).

The optimization at stake is specialization. Given (Num a => a), specialize it to Int or Double or X so that it's memoizably first-class, which is where functions still fall down [1]. All functions are values but data values still play nicer than others. Isn't fixing this the real cure for the monomorphism restriction? [1] http://lukepalmer.wordpress.com/2009/07/07/emphasizing-specialization/#comme... -- Kim-Ee

On Mon, Dec 31, 2012 at 7:30 AM, Rustom Mody wrote:

...

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

Just realized that the resultant anti-OOP direction of my earlier mail is stronger than is good for a young computer scientist. 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.

On Mon, Dec 31, 2012 at 7:46 AM, Strake wrote:

Disclaimer: My own experience with OO is limited.

Mine isn't quite so much...

On 30/12/2012, Daniel Díaz Casanueva 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. 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.

Learning a new paradigm is almost always a good idea. It gives you a 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.

That's a good functional start. Personally, I'd go with Eiffel, 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.

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? Thank you very much in advance. Best regards, Rico Moorman On Mon, Dec 31, 2012 at 6:13 PM, Bob Hutchison wrote:

On 2012-12-30, at 2:58 PM, Daniel Díaz Casanueva wrote:

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?

Yes. And you should learn OO *very* well. And remember, OO doesn't really get interesting until the program gets big.

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?

That's been my experience. And it'll be harder to name your favourite language too.

* Will I learn new programming strategies that I can use back in the Haskell world?

Probably.

Cheers, Bob

Thanks in advance for your kind responses, Daniel Díaz. _______________________________________________ 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

On 2012-12-31, at 4:26 PM, Rico Moorman wrote:

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?

He is talking about functions/procedures as in C, Pascal, Algol… structured programming basically. The first edition was written in 1988, the second about 10 years later. However, today, I *think* he might include functions as found in modern functional languages in this, and as you read on in the book you'll see why I say this. I've been considering re-reading OOSC2 for a while now (it is, believe it or not, a fun book… well, maybe that's just me) and keep Haskell and ML in mind while reading it. Meyer is trying to thoroughly explain the reasoning behind OO in this book, it isn't really a critique of anything especially (except indirectly other OO languages). Meyer can be scathing but you'll have to look elsewhere for the best/worst/most fun of that. Haskell, as it matures, is going to have to have an answer for everything in this book (answers may include 'pass' as Meyer does with Eiffel on a few issues–there's no shame in admitting Haskell, or anything else, doesn't have all the answers)… he's talking about issues that are independent of programming language. Cheers, Bob

Thank you very much in advance.

Best regards,

Rico Moorman

On Mon, Dec 31, 2012 at 6:13 PM, Bob Hutchison wrote: On 2012-12-30, at 2:58 PM, Daniel Díaz Casanueva wrote:

...

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?

Yes. And you should learn OO *very* well. And remember, OO doesn't really get interesting until the program gets big.

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?

That's been my experience. And it'll be harder to name your favourite language too.

...

* Will I learn new programming strategies that I can use back in the Haskell world?

Probably.

Cheers, Bob

...

Thanks in advance for your kind responses, Daniel Díaz. _______________________________________________ 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

On Jan 1, 2013, at 10:23 PM, Никитин Лев 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.

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 wrote:

MigMit wrote:

...

...

Eiffel, for my opinion, is a best OOP language. Meyer use a

On Jan 1, 2013, at 10:23 PM, Никитин Лев wrote: 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.

On Jan 2, 2013, at 2:26 AM, Bob Hutchison wrote:

On 2013-01-01, at 3:47 PM, MigMit 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.

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 wrote:

...

MigMit wrote:

...

...

Eiffel, for my opinion, is a best OOP language. Meyer use a

On Jan 1, 2013, at 10:23 PM, Никитин Лев wrote: 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

On 2013-01-02, at 7:56 AM, Bob Hutchison 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'.

'Construction' of course… the automated spell checker is not my friend :-(

[Context destroyed by top posting.] MigMit 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. -- Sent from my Android tablet with K-9 Mail. Please excuse my swyping.

On Wed, 2 Jan 2013 13:48:07 +0400 MigMit wrote:

On Jan 2, 2013, at 10:52 AM, Mike Meyer wrote:

...

MigMit 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 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. http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

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 --Gershom

Anyway, Type checking is essentially an application of set theory : (I did no search in te literature for this, It is just my perception). When I say (+) :: Num a => a -> a -> a . I mean that (+) takes two elements of the set of Num typeclass and return another. 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, 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. 2013/1/2 MigMit

On Jan 3, 2013, at 2:09 AM, Gershom Bazerman 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. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- Alberto.

On 01/02/2013 11:19 PM, MigMit wrote:

On Jan 3, 2013, at 2:09 AM, Gershom Bazerman 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.

There seem to be efforts to fix this: 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.t...

On 2013-01-02, at 1:52 AM, Mike Meyer wrote:

[Context destroyed by top posting.] MigMit 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.

Eiffel programmers certainly consider the pre&post conditions and invariants to be part of the signature. 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.

I can only speak from personal experience here. I used Eiffel as my primary programming language in the 1990's for about 10 years. I wrote a lot of code in Eiffel, and I used pre&post conditions and class invariants extensively (and loop invariants surprisingly often). Some of that code would certainly be described as 'complex'. Yes, documentation is a huge part of what DbC gives you, but a peculiarly aggressive kind of documentation that tells you when you're doing it wrong. The biggest problem I had with writing pre&post conditions and class invariants was missing part of what should be specified and so letting things pass that shouldn't have. The next biggest problem was being overly specific (I sometimes do the same thing with type signatures in Haskell I'm afraid). Bugs in the code of the conditions and invariants was not much of a problem I found (I can't recall any). It does take a while to learn how to write the conditions and how to accommodate DbC concepts when you write a class or class hierarchy. And, occasionally, the balancing act between DbC and unit tests is tricky.

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. -- 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

On Jan 2, 2013, at 8:44 AM, Никитин Лев wrote:

I said "theoratical", but not "mathematical" or "a scientific" theory.

Than what kind of theory did you mean?

Meyer have built a quite coherent construction in comparison with other OOP langs.

More than Smalltalk, for example?

BTW, when I started study haskell i had similar question: is it possible to add DbC to haskell? Does haskell need DbC? For example, class invariants may be expressed in DbC construction (fmap id = id for Functior, for example).

02.01.2013, 02:41, "Mike Meyer" : MigMit wrote:

On Jan 1, 2013, at 10:23 PM, Никитин Лев 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