Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
On Sun, Dec 30, 2012 at 1:27 PM, Brandon Allbery allber...@gmail.comwrote: [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. 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). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
On Fri, Jan 4, 2013 at 7:27 PM, David Thomas davidleotho...@gmail.comwrote: 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/#comment-862 -- Kim-Ee ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
There have been lots of proposals to fix the CATCALL problems in recent years. None have been implemented (at least in ISE/GEC compilers. And tecomp has been abandonded by its author - he is now writing a series of blogs about a vapourware product called Modern Eiffel). I don't find the CATCALL problem a great problem in practice (one gets used to avoiding the problem). But it is a nasty whole in the theory of the type system. On 3 January 2013 22:07, Timon Gehr timon.g...@gmx.ch wrote: On 01/02/2013 11:19 PM, MigMit wrote: On Jan 3, 2013, at 2:09 AM, Gershom Bazerman gersh...@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/517http://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/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_20http://tecomp.sourceforge.net/index.php?file=doc/papers/lang/modern_eiffel.txt#chapter_20 __**_ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
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 miguelim...@yandex.ru On Jan 3, 2013, at 2:09 AM, Gershom Bazerman gersh...@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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Alberto. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
On 01/03/2013 10:56 AM, Alberto G. Corona wrote: Anyway, Type checking is essentially an application of set theory : (I did no search in te literature for this, It is just my perception). Not exactly. Type theory is not an application of set theory, it is an 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. If I get this right, you consider Num to be a set, and then its 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, There are quite a few that take it further than Haskell. 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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
On 01/02/2013 11:19 PM, MigMit wrote: On Jan 3, 2013, at 2:09 AM, Gershom Bazerman gersh...@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. 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.txt#chapter_20 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
On Jan 2, 2013, at 2:26 AM, Bob Hutchison hutch-li...@recursive.ca wrote: On 2013-01-01, at 3:47 PM, MigMit miguelim...@yandex.ru wrote: Well, probably one of the reasons is that I've learned Eiffel later than Haskell. But really, Design by Contract — a theory? It certainly is a useful approach, but it doesn't seem to be a theory, not until we can actually prove something about it, and Eiffel doesn't seem to offer anything in this direction. Don't confuse OOSC2 and Eiffel. Eiffel implements the ideas in OOSC2 as best as Meyer can, but they are not the same thing. Well, we were talking about Eiffel. OOSC2 deserves a few unkind words as well, but I won't go there. And, personally, I think I would be willing to call DbC a theory, or a close precursor to a theory. I don't know about DbC in general, but it's implementation in Eiffel seems to be nothing more than a few ASSERT macros, for some weird reason embedded into the language. 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 m...@mired.org wrote: MigMit miguelim...@yandex.ru wrote: On Jan 1, 2013, at 10:23 PM, Никитин Лев leon.v.niki...@pravmail.ru wrote: Eiffel, for my opinion, is a best OOP language. Meyer use a theoretical approach as it is possible in OOP. Really? Because when I studied it I had a very different impression: that behind this language there was no theory at all. And it's only feature I remember that is not present in mainstream languages is it's pre/postconditions system, which looked like an ugly hack for me. I agree with Leon. Of course, I learned it out of OOSC2, which provides the theory. When compared to mainstream OO languages like C++, Java or Python, it's on a much solider theoretical basis. Compared to something like Scheme, Haskell or even Clojure, maybe not so much. On the other hand, one persons theory is another persons hack. The theory behind the pre/post conditions is Design by Contract. The contracts are as important as the type signature, and show up in the auto-generated docs in eiffel systems. I found at least one attempt to add DbC features to Haskell. I'm not sold on it as a programming technique - the bugs it uncovers are as likely to be in the pre/post conditions as in the code. -- Sent from my Android tablet with K-9 Mail. Please excuse my swyping. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
On Jan 2, 2013, at 8:44 AM, Никитин Лев leon.v.niki...@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? 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 m...@mired.org: MigMit miguelim...@yandex.ru wrote: On Jan 1, 2013, at 10:23 PM, Никитин Лев leon.v.niki...@pravmail.ru wrote: Eiffel, for my opinion, is a best OOP language. Meyer use a theoretical approach as it is possible in OOP. Really? Because when I studied it I had a very different impression: that behind this language there was no theory at all. And it's only feature I remember that is not present in mainstream languages is it's pre/postconditions system, which looked like an ugly hack for me. I agree with Leon. Of course, I learned it out of OOSC2, which provides the theory. When compared to mainstream OO languages like C++, Java or Python, it's on a much solider theoretical basis. Compared to something like Scheme, Haskell or even Clojure, maybe not so much. On the other hand, one persons theory is another persons hack. The theory behind the pre/post conditions is Design by Contract. The contracts are as important as the type signature, and show up in the auto-generated docs in eiffel systems. I found at least one attempt to add DbC features to Haskell. I'm not sold on it as a programming technique - the bugs it uncovers are as likely to be in the pre/post conditions as in the code. -- Sent from my Android tablet with K-9 Mail. Please excuse my swyping. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
On Jan 2, 2013, at 10:52 AM, Mike Meyer m...@mired.org wrote: [Context destroyed by top posting.] MigMit miguelim...@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. I always thought the theory is something that allows us to develop some new knowledge. Just stating that comfortable chairs make programmers more productive doesn't constitute a theory. 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. I've tried to clarify my position in my response to Bob Hutchison. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
On Wed, 2 Jan 2013 13:48:07 +0400 MigMit miguelim...@yandex.ru wrote: On Jan 2, 2013, at 10:52 AM, Mike Meyer m...@mired.org wrote: MigMit miguelim...@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 miguelim...@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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
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? DbC is not the same as "assert macros". First, it has a lang semantic. There is an interesting graduated mechanism to turn off or turn on conditions' checking. Dbc is not only initeresting "concept" of lang. Meyer is considering class as a type in his type system. By the way, preconditions and postconditions of class and its subclass have to be consistient. I don't remeber all details now, as I remeber preconditions of subclass are automaticly logically 'and'ed to preconditions of superclass. This supports "concept" of "class is type" and "subclass is a same type as superclass". Other "concept" - classes are only modules. Other "concept" - "command/query separation" = dividing functions on functions that change state of object and on functions that query some info from function (sic. pure functions!). Other "concept" - polymorphic types (general types) - parametrisied types, including constrained parametrisied types (MAP [V, K - HASHABLE]). Other "concept" - solving multiple inherient problem - "name clashing" And so on. BTW. Why you think that Eiffel type system is unsafe? I don't what is a situation with java type now (not using java for several yeas), but I thought that java type system is more unsafe that eiffel type system. (They said that there were generic types in java). And BTW, smalltalk is a lang with dynamic type system. PS. In structuring programming, to prove correctness of loop construction, you have to write down precondition of loop, loop invariant, loop postcondition. You have to (mathamaticly) prove: if precondition holds than invariant holds (and in result we get solved postcondition).___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
Opps... I forgot about Eiffel agents! PS. After participationing in this discussion I'm tempting to reread Meyer's book after 10 years interval, to have a detailed look at the eiffel from the FP position. When I read this book first I know nothing about FP. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
On 2013-01-02, at 4:41 AM, MigMit miguelim...@yandex.ru wrote: On Jan 2, 2013, at 2:26 AM, Bob Hutchison hutch-li...@recursive.ca wrote: On 2013-01-01, at 3:47 PM, MigMit miguelim...@yandex.ru wrote: Well, probably one of the reasons is that I've learned Eiffel later than Haskell. But really, Design by Contract — a theory? It certainly is a useful approach, but it doesn't seem to be a theory, not until we can actually prove something about it, and Eiffel doesn't seem to offer anything in this direction. Don't confuse OOSC2 and Eiffel. Eiffel implements the ideas in OOSC2 as best as Meyer can, but they are not the same thing. Well, we were talking about Eiffel. OOSC2 deserves a few unkind words as well, but I won't go there. And, personally, I think I would be willing to call DbC a theory, or a close precursor to a theory. I don't know about DbC in general, but it's implementation in Eiffel seems to be nothing more than a few ASSERT macros, for some weird reason embedded into the language. Hmm. I must disagree with you here. I've used three Eiffel systems, ISE, Small/SmartEiffel, and Tower. They all implemented DbC pretty thoroughly. In my opinion, every other implementation of DbC pale in comparison, to the point where they're hardly DbC at all. Are we talking about the same thing? There are three major components (in my opinion) to DbC: pre and post conditions, and class invariants. Pre and post conditions and invariants cannot be implemented simply as asserts. I'll have to refer you to OOSC2 for the (many) details, but a few of the more interesting aspects of these constructs are: 1) error reporting. If a precondition is violated the caller is flagged as the source of the error and error messages, stack traces, etc all reflect the caller. If a post condition is violated it's the callee who is responsible. And the error reports generated are rather good. 2) prepost 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 prepost conditions, and results for post conditions. Access to the initial state of the object is supposed to be there but I don't think all implementations support that. That's only a brief summary, it goes further than that, again I refer you to OOSC2 (and any of the Eiffel implementations I mentioned, and I don't know of any other implementations). This is nothing like a few assert macros. So, I think, you're saying take away the contracts and the outcome of compilation won't be any different. Whereas take away the types and Haskell is stopped cold. And that difference makes contracts a 'hack' but types not a 'hack'? I wasn't clear enough, sorry. I'm sure it's due to sleep deprivation. Or coffee deprivation. See, there are two parts of Eiffel, as I see it. First one is the contracts part. Second is… well, everything else. Second part seems to be doing all the real job, while the first one is doing something invisible, something that leaves no trace in the final result. Which doesn't mean it's unimportant, of course. The contracts part is designed to help the other part do it's job, but not to do the job by itself. Now, there are two problems with that: 1) The real job part needs helping. And a lot of it, actually, one doesn't need to look very closely to see that Eiffel type system is extremely unsafe (for the statically type language). Feel free to enlighten me about these obvious and extremely unsafe aspects of Eiffel's type system. Personally, I can't say I ever noticed. 2) The contracts part does a very poor job. Instead of really improving the inherent unsafety, it resorts to testing. And… What constitutes a 'good' job? 'Resorts' to testing. I have to admit to resorting to testing on occasion myself. Frequent occasion. Routinely even. :-) 2') ...not even the real, thorough testing — contracts system would be quite happy if the program works on the developer's machine. Which is the works for me approach certain languages gets rightfully blamed for. Really? You believe that automated testing and contracts are why software bugs *are not* found? Seems to me you're ignoring everything that happens between an empty directory and a working program. Contracts help in that process (I say but can't prove). I agree. They do help — but there are lots of things that help in this transition. Versioning systems. Collaboration tools. Bug tracking software. Text editors. Even debuggers. You should read OOSC2. You'll find that this is completely consistent with it. Don't forget that the 'C' in OOSC2 is 'contraction'. Cheers, Bob Pre and post
Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
On 2013-01-02, at 7:56 AM, Bob Hutchison hutch-li...@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'. 'Construction' of course… the automated spell checker is not my friend :-( ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
Hi, 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? Learn or not to learn? I would say: yes! There is whole new universe 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. Get a book (big and heavy!), forget all about programming and read it 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? I would say, any know knowledge has impact on your life. Programming skills also. * Will I learn new programming strategies that I can use back in the Haskell world? Here I can't say much, I'm just starting with Haskell, but if you would go with C++, then you will also learn some C by the way, FFI is waiting.. Thanks in advance for your kind responses, I hope it was helpful. Emanuel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
On 2013-01-02, at 1:52 AM, Mike Meyer m...@mired.org wrote: [Context destroyed by top posting.] MigMit miguelim...@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. Eiffel programmers certainly consider the prepost 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 prepost 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 prepost 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
Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
On Jan 2, 2013, at 4:24 PM, Никитин Лев leon.v.niki...@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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
2) prepost 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. Yes, I forgot about that. Thanks. 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. Correct me if I'm wrong, but isn't it true that methods can be removed in subclasses? If that's not extreme, I don't know what is. 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? Well, a sound type system would certainly help. 'Resorts' to testing. I have to admit to resorting to testing on occasion myself. Frequent occasion. Routinely even. :-) You routinely try to overcome language weakness with tests? 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? Is that what I said? 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. I've never said it's not. But all of these tools are external to the language, which means that they can be easily replaced if a better alternative surfaces. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
On Jan 3, 2013, at 2:09 AM, Gershom Bazerman gersh...@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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
On 2012-12-31, at 4:26 PM, Rico Moorman rico.moor...@gmail.com 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 hutch-li...@recursive.ca wrote: On 2012-12-30, at 2:58 PM, Daniel Díaz Casanueva dhelta.d...@gmail.com 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 KR 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,
Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
Eiffel, for my opinion, is a best OOP language. Meyer use a theoretical approach as it is possible in OOP. 01.01.2013, 23:56, "Bob Hutchison" hutch-li...@recursive.ca:On 2012-12-31, at 4:26 PM, Rico Moorman rico.moor...@gmail.com 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: usingfunctions as a basis for the architecture of software systems. This will not only lead us toappreciate 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 prematureoperation 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 MoormanOn Mon, Dec 31, 2012 at 6:13 PM, Bob Hutchison hutch-li...@recursive.ca wrote:On 2012-12-30, at 2:58 PM, Daniel Díaz Casanueva dhelta.d...@gmail.com 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 KR 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,BobThanks in advance
Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
MigMit miguelim...@yandex.ru wrote: On Jan 1, 2013, at 10:23 PM, Никитин Лев leon.v.niki...@pravmail.ru wrote: Eiffel, for my opinion, is a best OOP language. Meyer use a theoretical approach as it is possible in OOP. Really? Because when I studied it I had a very different impression: that behind this language there was no theory at all. And it's only feature I remember that is not present in mainstream languages is it's pre/postconditions system, which looked like an ugly hack for me. I agree with Leon. Of course, I learned it out of OOSC2, which provides the theory. When compared to mainstream OO languages like C++, Java or Python, it's on a much solider theoretical basis. Compared to something like Scheme, Haskell or even Clojure, maybe not so much. On the other hand, one persons theory is another persons hack. The theory behind the pre/post conditions is Design by Contract. The contracts are as important as the type signature, and show up in the auto-generated docs in eiffel systems. I found at least one attempt to add DbC features to Haskell. I'm not sold on it as a programming technique - the bugs it uncovers are as likely to be in the pre/post conditions as in the code. -- Sent from my Android tablet with K-9 Mail. Please excuse my swyping. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
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 m...@mired.org wrote: MigMit miguelim...@yandex.ru wrote: On Jan 1, 2013, at 10:23 PM, Никитин Лев leon.v.niki...@pravmail.ru wrote: Eiffel, for my opinion, is a best OOP language. Meyer use a theoretical approach as it is possible in OOP. Really? Because when I studied it I had a very different impression: that behind this language there was no theory at all. And it's only feature I remember that is not present in mainstream languages is it's pre/postconditions system, which looked like an ugly hack for me. I agree with Leon. Of course, I learned it out of OOSC2, which provides the theory. When compared to mainstream OO languages like C++, Java or Python, it's on a much solider theoretical basis. Compared to something like Scheme, Haskell or even Clojure, maybe not so much. On the other hand, one persons theory is another persons hack. The theory behind the pre/post conditions is Design by Contract. The contracts are as important as the type signature, and show up in the auto-generated docs in eiffel systems. I found at least one attempt to add DbC features to Haskell. I'm not sold on it as a programming technique - the bugs it uncovers are as likely to be in the pre/post conditions as in the code. -- Sent from my Android tablet with K-9 Mail. Please excuse my swyping. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
On 2013-01-01, at 3:47 PM, MigMit miguelim...@yandex.ru wrote: Well, probably one of the reasons is that I've learned Eiffel later than Haskell. But really, Design by Contract — a theory? It certainly is a useful approach, but it doesn't seem to be a theory, not until we can actually prove something about it, and Eiffel doesn't seem to offer anything in this direction. Don't confuse OOSC2 and Eiffel. Eiffel implements the ideas in OOSC2 as best as Meyer can, but they are not the same thing. And, personally, I think I would be willing to call DbC a theory, or a close precursor to a theory. And by hack I meant not the presence of pre/postconditions, but the fact that they don't affect anything else. Strip all of them away, and you'll have the program which is, essentially, the same (and, in fact, pre/postconditions are supposed to be removed in the final version of the program). Compare this to Haskell types, for example: an untyped version of Haskell won't be able to choose between two class instances, so, that would be an entirely different language. So, I think, you're saying take away the contracts and the outcome of compilation won't be any different. Whereas take away the types and Haskell is stopped cold. And that difference makes contracts a 'hack' but types not a 'hack'? Seems to me you're ignoring everything that happens between an empty directory and a working program. Contracts help in that process (I say but can't prove). Call that a 'hack' if you want, but I'll take as many of those kinds of hacks as I can get if they're anywhere near as good as contracts. Pre and post conditions with class invariants are neither types nor unit test, something in between. With the wonderful properties of 'useful' and 'executable'. Sometimes you just have to settle for the hacks. Cheers, Bob On Jan 1, 2013, at 11:41 PM, Mike Meyer m...@mired.org wrote: MigMit miguelim...@yandex.ru wrote: On Jan 1, 2013, at 10:23 PM, Никитин Лев leon.v.niki...@pravmail.ru wrote: Eiffel, for my opinion, is a best OOP language. Meyer use a theoretical approach as it is possible in OOP. Really? Because when I studied it I had a very different impression: that behind this language there was no theory at all. And it's only feature I remember that is not present in mainstream languages is it's pre/postconditions system, which looked like an ugly hack for me. I agree with Leon. Of course, I learned it out of OOSC2, which provides the theory. When compared to mainstream OO languages like C++, Java or Python, it's on a much solider theoretical basis. Compared to something like Scheme, Haskell or even Clojure, maybe not so much. On the other hand, one persons theory is another persons hack. The theory behind the pre/post conditions is Design by Contract. The contracts are as important as the type signature, and show up in the auto-generated docs in eiffel systems. I found at least one attempt to add DbC features to Haskell. I'm not sold on it as a programming technique - the bugs it uncovers are as likely to be in the pre/post conditions as in the code. -- Sent from my Android tablet with K-9 Mail. Please excuse my swyping. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
On 12/31/12 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? I'm not Bob nor Mike, and haven't read the text in question, but when 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
I said "theoratical", but not "mathematical" or "a scientific" theory. Meyer have built a quite coherent construction in comparison with other OOP langs. 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" m...@mired.org:MigMit miguelim...@yandex.ru wrote:On Jan 1, 2013, at 10:23 PM, Никитин Лев leon.v.niki...@pravmail.ruwrote: Eiffel, for my opinion, is a best OOP language. Meyer use atheoretical 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 onlyfeature I remember that is not present in mainstream languages is it'spre/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
Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
[Context destroyed by top posting.] MigMit miguelim...@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. -- 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
Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
Daniel Díaz Casanueva wrote: 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? 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 -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
Disclaimer: My own experience with OO is limited. On 30/12/2012, Daniel Díaz Casanueva dhelta.d...@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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
On Mon, Dec 31, 2012 at 7:46 AM, Strake strake...@gmail.com wrote: Disclaimer: My own experience with OO is limited. Mine isn't quite so much... On 30/12/2012, Daniel Díaz Casanueva dhelta.d...@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. 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. mike ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
On 2012-12-30, at 2:58 PM, Daniel Díaz Casanueva dhelta.d...@gmail.com 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 KR 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
Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
Since you have done a significant amount of work with Haskell, I must presume you have a solid understanding of monads. If so, I can suggest reading http://stackoverflow.com/questions/2704652/monad-in-plain-english-for-the-oop-programmer-with-no-fp-background/13656209#13656209 It is for the OO programmer, but it does a good job of clarifying some issues. In particular, a class hierarchy is analogous to a stack of monads (made with monad transformers). That is to say, a class attaches 'methods' to an 'object' (i.e., a context, which might include data). Different languages use different monads to attach methods to objects -- for example, JavaScript uses prototype-based object orientation, which is very much analogous to the Haskell pattern: data SomeData = ... defaultData :: SomeData defaultData = ... setName :: Name - SomeData - SomeData setName = ... namedData :: SomeData namedData = setName (Name Pete) defaultData Typically, an object oriented language provides an enriched IO monad which provides method dispatch based on context, state for free by setting variables (i.e., the dreaded side-effect), and so on. From a functional perspective, this is all syntactic sugar for a complicated monad transformer stack: type OO a = ClassT a (StateT a IO) a Typical object oriented languages are procedural in nature, and use explicit looping to handle iterating over data structures. Typically, all work is done in the same monad and it is impossible to define your own monads using best practices for that OO language. On Sun, Dec 30, 2012 at 11:58 AM, Daniel Díaz Casanueva dhelta.d...@gmail.com wrote: 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
Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
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 hutch-li...@recursive.cawrote: On 2012-12-30, at 2:58 PM, Daniel Díaz Casanueva dhelta.d...@gmail.com 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 KR 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
On Mon, Dec 31, 2012 at 4:26 PM, Rico Moorman rico.moor...@gmail.comwrote: 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? Procedures. They're coming at it from the standpoint of C / Algol / Pascal, where functions are more or less your only real way to organize code; not talking about functional programming. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Object Oriented programming for Functional Programmers
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
Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
On Sun, 30 Dec 2012, Daniel D??az Casanueva dhelta.d...@gmail.com wrote: 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. There are several different things called object oriented 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. * 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
Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
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 30.12.2012, в 23:58, Daniel Díaz Casanueva dhelta.d...@gmail.com написал(а): 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
Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
Sorry for the stupid mistake — when I said Daniel in the previous message, I've meant Jay. Отправлено с iPad 30.12.2012, в 23:58, Daniel Díaz Casanueva dhelta.d...@gmail.com написал(а): 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
Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
I think it is always a good idea to learn languages that make your-favorite-paradigm hard. There are a lot of Aha moments to be had from forcing your brain to come at a problem from another angle. 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. On Sun, Dec 30, 2012 at 11:58 AM, Daniel Díaz Casanueva dhelta.d...@gmail.com wrote: 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
Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
On Sun, Dec 30, 2012 at 3:45 PM, Eli Frey eli.lee.f...@gmail.com 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 allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
On Mon, Dec 31, 2012 at 1:28 AM, Daniel Díaz Casanueva dhelta.d...@gmail.com wrote: 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? 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-o-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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
On Mon, Dec 31, 2012 at 7:30 AM, Rustom Mody rustompm...@gmail.com 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-o-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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
On Mon, 31 Dec 2012, MigMit miguelim...@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 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-protocols oo--JS. 30.12.2012, ?? 23:58, Daniel D??az Casanueva dhelta.d...@gmail.com ??(??): 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
Since no one's mentioned it yet, you might consider learning Scala. A good starting point is http://www.artima.com/pins1ed/index.html (note that the free edition is outdated but still a good introduction). 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. On Sun, Dec 30, 2012 at 6:12 PM, Jay Sulzberger j...@panix.com wrote: On Mon, 31 Dec 2012, MigMit miguelim...@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 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_functionhttp://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_Systemhttp://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_**problemhttp://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://www.ibm.com/developerworks/java/library/j-clojure-protocols/ http://stackoverflow.com/**questions/4509782/simple-** explanation-of-clojure-**protocolshttp://stackoverflow.com/questions/4509782/simple-explanation-of-clojure-protocols oo--JS. 30.12.2012, в 23:58, Daniel Díaz Casanueva dhelta.d...@gmail.com написал(а): 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
Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
There's OOHaskell, which you can google for. The name's such a nice example of an aptronym: it's the Overlooked Object-oriented Haskell. -- Kim-Ee On Mon, Dec 31, 2012 at 2:58 AM, Daniel Díaz Casanueva dhelta.d...@gmail.com wrote: 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
