Re: [Haskell-cafe] How to fulfill the code-reuse destiny of OOP?
On Sun, Nov 1, 2009 at 2:57 AM, Gregory Collins g...@gregorycollins.netwrote: Doing OO-style programming in Haskell is difficult and unnatural, it's true (although technically speaking it is possible). That said, nobody's yet to present a convincing argument to me why Java gets a free pass for lacking closures and typeclasses. I might be wrong, but doesn't Java's concepts of inner classes and interfaces together with adapter classes can be used to replace closures and typeclasses in a way? An inner class allows you to implicitly capture the parent object (environment), just like a closure does in a sense. Interfaces group together methods, like type classes do. Although I'm actually a C# fanboy for doing industrial programming, I think the Java designers did an excellent job, finding a good balance in language features, ease of use and readability, and although C# does offer closures and many more FP constructs, I really miss the above Java constructs. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to fulfill the code-reuse destiny of OOP?
On 13 Jan 2010, at 09:51, Peter Verswyvelen wrote: On Sun, Nov 1, 2009 at 2:57 AM, Gregory Collins g...@gregorycollins.net wrote: Doing OO-style programming in Haskell is difficult and unnatural, it's true (although technically speaking it is possible). That said, nobody's yet to present a convincing argument to me why Java gets a free pass for lacking closures and typeclasses. I might be wrong, but doesn't Java's concepts of inner classes and interfaces together with adapter classes can be used to replace closures and typeclasses in a way? Inner classes are not a semantic replacement for closures, even if you discount horrific syntax. Inner classes do not close over their lexical environment. Martin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] How to fulfill the code-reuse destiny of OOP?
The problem with interfaces as a replacement for type classes is that they only provide dispatch based on the specific type of the first argument (i.e. the receiver). Type classes allow you to dispatch based on return type, and on the instantiations of generic parameters. Neither of these things is reasonably possible with interfaces. For example you can't directly implement the Read type class with interfaces. Neither can you implement a function of type [a] - ... where the dispatch is based on the instantiation of a - even if you can add an interface to the [] generic type, you might not have a concrete object of type a to dispatch from if the empty list is passed as an argument. From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Peter Verswyvelen Sent: 13 January 2010 09:52 To: Gregory Collins Cc: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] How to fulfill the code-reuse destiny of OOP? On Sun, Nov 1, 2009 at 2:57 AM, Gregory Collins g...@gregorycollins.net wrote: Doing OO-style programming in Haskell is difficult and unnatural, it's true (although technically speaking it is possible). That said, nobody's yet to present a convincing argument to me why Java gets a free pass for lacking closures and typeclasses. I might be wrong, but doesn't Java's concepts of inner classes and interfaces together with adapter classes can be used to replace closures and typeclasses in a way? An inner class allows you to implicitly capture the parent object (environment), just like a closure does in a sense. Interfaces group together methods, like type classes do. Although I'm actually a C# fanboy for doing industrial programming, I think the Java designers did an excellent job, finding a good balance in language features, ease of use and readability, and although C# does offer closures and many more FP constructs, I really miss the above Java constructs. === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to fulfill the code-reuse destiny of OOP?
On Jan 13, 2010, at 11:00 AM, Sittampalam, Ganesh wrote: Type classes allow you to dispatch based on return type, and on the instantiations of generic parameters. Neither of these things is reasonably possible with interfaces. There is recent work that generalises the capabilities of interfaces in Java: http://www.informatik.uni-freiburg.de/~wehr/publications/WehrLammelThiemann2007.html http://www.informatik.uni-freiburg.de/~wehr/publications/WehrThiemann2009.html http://www.informatik.uni-freiburg.de/~wehr/publications/Wehr2009.html Seeing type-class features in Java disguise highlights the differences between the two concepts that you mention. Sebastian -- Underestimating the novelty of the future is a time-honored tradition. (D.G.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to fulfill the code-reuse destiny of OOP?
Yes that is true, but often in Haskell I had to use type annotations when the dispatch is based on the return type, so it also has some tradeoffs. Don't get me wrong, I see the advantages of Haskell's type classes and closures, and I love these. But in Java - if you stay close to OO, and don't try to do FP - you can accomplish a lot, albeit with a lot of boilerplate. IMO, it's not because you have less lines of code in Haskell, that the code becomes more readable per se. I'm not a Java expert, but I have no troubles at all reading Java code, even though that code is typically twice as long as similar C# code, and maybe ten times as long as Haskell or ML code (at least if the side effects are kept local enough, which is good practice in OO anyway). But after many years of playing with Haskell, I still fail to read and understand a lot of Haskell code (maybe because it is written by people with a much higher IQ than mine I guess) On Wed, Jan 13, 2010 at 11:00 AM, Sittampalam, Ganesh ganesh.sittampa...@credit-suisse.com wrote: The problem with interfaces as a replacement for type classes is that they only provide dispatch based on the specific type of the first argument (i.e. the receiver). Type classes allow you to dispatch based on return type, and on the instantiations of generic parameters. Neither of these things is reasonably possible with interfaces. For example you can't directly implement the Read type class with interfaces. Neither can you implement a function of type [a] - ... where the dispatch is based on the instantiation of a - even if you can add an interface to the [] generic type, you might not have a concrete object of type a to dispatch from if the empty list is passed as an argument. From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Peter Verswyvelen Sent: 13 January 2010 09:52 To: Gregory Collins Cc: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] How to fulfill the code-reuse destiny of OOP? On Sun, Nov 1, 2009 at 2:57 AM, Gregory Collins g...@gregorycollins.net wrote: Doing OO-style programming in Haskell is difficult and unnatural, it's true (although technically speaking it is possible). That said, nobody's yet to present a convincing argument to me why Java gets a free pass for lacking closures and typeclasses. I might be wrong, but doesn't Java's concepts of inner classes and interfaces together with adapter classes can be used to replace closures and typeclasses in a way? An inner class allows you to implicitly capture the parent object (environment), just like a closure does in a sense. Interfaces group together methods, like type classes do. Although I'm actually a C# fanboy for doing industrial programming, I think the Java designers did an excellent job, finding a good balance in language features, ease of use and readability, and although C# does offer closures and many more FP constructs, I really miss the above Java constructs. == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to fulfill the code-reuse destiny of OOP?
Peter Verswyvelen bugf...@gmail.com writes: On Sun, Nov 1, 2009 at 2:57 AM, Gregory Collins g...@gregorycollins.net wrote: Doing OO-style programming in Haskell is difficult and unnatural, it's true (although technically speaking it is possible). That said, nobody's yet to present a convincing argument to me why Java gets a free pass for lacking closures and typeclasses. I might be wrong, but doesn't Java's concepts of inner classes and interfaces together with adapter classes can be used to replace closures and typeclasses in a way? Maybe, in the same sense that a lawnmower engine strapped to a skateboard is a replacement for a car: it takes you ten times as long to get to your destination and you're cold and wet when you get there. G -- Gregory Collins g...@gregorycollins.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to fulfill the code-reuse destiny of OOP?
On Wed, Jan 13, 2010 at 4:56 AM, Martin Coxall pseudo.m...@me.com wrote: On 13 Jan 2010, at 09:51, Peter Verswyvelen wrote: On Sun, Nov 1, 2009 at 2:57 AM, Gregory Collins g...@gregorycollins.net wrote: Doing OO-style programming in Haskell is difficult and unnatural, it's true (although technically speaking it is possible). That said, nobody's yet to present a convincing argument to me why Java gets a free pass for lacking closures and typeclasses. I might be wrong, but doesn't Java's concepts of inner classes and interfaces together with adapter classes can be used to replace closures and typeclasses in a way? Inner classes are not a semantic replacement for closures, even if you discount horrific syntax. Inner classes do not close over their lexical environment. Martin Anonymous classes in Java close over their lexical environment (can refer to variables in that lexical environment, with values bound at the time of instance construction) with the caveat that only local variables/parameters marked as 'final' may be referred to. Aside from the horrible syntax, this is the key distinction between them, and, say, Ruby closures. Referring to mutable variables from inside a closure has its drawbacks, making the horrible syntax the biggest stumbling block to using them IMHO (other than runtime overhead, which I believe is also an issue). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to fulfill the code-reuse destiny of OOP?
Anonymous classes in Java close over their lexical environment (can refer to variables in that lexical environment, with values bound at the time of instance construction) with the caveat that only local variables/parameters marked as 'final' may be referred to. Aside from the horrible syntax, this is the key distinction between them, and, say, Ruby closures. Referring to mutable variables from inside a closure has its drawbacks, making the horrible syntax the biggest stumbling block to using them IMHO (other than runtime overhead, which I believe is also an issue). Yes, this. Which makes them basically unusable where you might want proper closures. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to fulfill the code-reuse destiny of OOP?
I am not saying that the code has to be in OO style. When I say OO is general, I mean I am thinking in OO style. This reflects on modeling, program structure, even code organization. Style is how we present things. I think that is less important than how we think about things. On Sun, Nov 1, 2009 at 9:57 AM, Gregory Collins g...@gregorycollins.net wrote: Tom Davie tom.da...@gmail.com writes: On 10/31/09, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: After all, I never think OO as an oppsite way to all other things. The idea is so general that if you say I cannot use it in Haskell at all, that would make me feel weird. The only difference between languages is, some are easy to be in OO style, some are not. Wow, someone drank the cool aid! Doing OO-style programming in Haskell is difficult and unnatural, it's true (although technically speaking it is possible). That said, nobody's yet to present a convincing argument to me why Java gets a free pass for lacking closures and typeclasses. G. -- Gregory Collins g...@gregorycollins.net -- 竹密岂妨流水过 山高哪阻野云飞 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to fulfill the code-reuse destiny of OOP?
Magicloud wrote: I am not saying that the code has to be in OO style. When I say OO is general, I mean I am thinking in OO style. This reflects on modeling, program structure, even code organization. Style is how we present things. I think that is less important than how we think about things. Style is irrelevant to the larger theorems of the universe which tells us that OOP must be granular in architecture (composability will force it, else code has to be re-written), thus I cross link this thread to Base classes can be _ELIMINATED_ with interfaces: http://www.haskell.org/pipermail/haskell-cafe/2009-November/068432.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to fulfill the code-reuse destiny of OOP?
Somehow, I agree with you. I think inherit is not evil, the people use it wrong is. The problem here is, inherit is naked right now. So people could use it wrong. On Fri, Oct 30, 2009 at 7:42 PM, Yaakov Nemoy loupgaroubl...@gmail.com wrote: 2009/10/30 Peter Verswyvelen bugf...@gmail.com: The following is purely my own experience, I have no links to papers of clever people :) I think none of the inheritance techniques work perfectly. E.g. describing everything with OO interfaces (=a extensible record of function pointers) is also problematic IMHO, at least when you have side effects. The problem with an interface (with side effects) is that people using the interface tend to depend on the side effects that a particular implementation of that interface performs. So in order to describe the contract for implementers of an interface, one often has to go into great detail. Also in Haskell it is required that an implementers follows the contract when implementing a type class, e.g. when writing a monad, you must make sure it follows the monad laws. But at least in Haskell, this can be proven, while in OO, one has to hope that the side effects of an implementation won't cause weird behavior elsewhere. In practice, this seems to work, most of the time :) The evolution of industrial OO the way I see it, is strange. You start with assembler, in which it is obvious to extend records. Then comes C, which makes extending records hard to do without casting and macros. Then C++, which offers insane ways of extending them (virtual base classes, multiple inheritance, mixins using templates, ...). Then to make software components more loosely coupled and maintainable, Corba COM enters the picture, and you only use interfaces to communicate with other objects. Of course COM uses reference counting, so reusable components is actually just an illusion; in order to avoid memory leaks, you need to know how objects are connected, which depends on the implementation... In the meantime Java becomes a succes. Java is basically back to basics: it tries to address some of the flaws of complicated OO, has garbage collection, promises multi-platform caps, and it is very easy to understand, so people embrace it. Then C# comes along, which initially is almost the same as Java, except is has closures, but it evolves towards a functional language with side effects (even Haskell's FRP will be available in .NET 4.0, with the Rx framework!). Then to manage large and complicated software, things like dependency injection and inversion of control are introduced, and... we're basically back to COM in a sense, but now with garbage collection. So I have the impression that OO is running in circles, and every iteration tries to pick up some goodies of the previous one, but where will it end? Luckily humans seem to have the ability to get things done, whatever primitive or flawed tools we get. I guess the brain itself it the best programming language ;) Looking at this from a feedback circuit perspective, it seems like that industrial programming is just swinging back and forth between two extremes. It appears that at every step someone runs into the limitations of doing things one way and finds a way to orthogonally combine other designs together. For example, there's been alot of work on implementing other languages on top of Java, such as Jython, so different programming methods can be mixed into enterprise Java code. It all swings back and forth because more than one design and paradigm is needed and no single language can really support it all at once. -Yaakov Nemoy ___ 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] How to fulfill the code-reuse destiny of OOP?
After all, I never think OO as an oppsite way to all other things. The idea is so general that if you say I cannot use it in Haskell at all, that would make me feel weird. The only difference between languages is, some are easy to be in OO style, some are not. 2009/10/31 Andrew Coppin andrewcop...@btinternet.com: Rogan Creswick wrote: On Thu, Oct 29, 2009 at 6:54 PM, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: My concern here is about the data member inheriting. In OOP, when I inherit a class, I also got the members of it. But in haskell, how to inherit a data? In my experience (almost entirely with Java), it is usually a bad idea to inherit from a class in order to reuse data storage that the parent class provides. Encapsulation (or a decorator, if you prefer) is often a safer choice. ...otherwise phrased in OO circles as people over-use inheritance and under-use collaboration. That said, I'm sure I won't be the first person here to say that generally, if you want to write a Haskell program, you should forget all about OOP and figure out how to structure it to make the best use of Haskell. It's a very different approach to program construction, and it requires a different way of thinking. ___ 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] How to fulfill the code-reuse destiny of OOP?
On 10/31/09, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: After all, I never think OO as an oppsite way to all other things. The idea is so general that if you say I cannot use it in Haskell at all, that would make me feel weird. The only difference between languages is, some are easy to be in OO style, some are not. Wow, someone drank the cool aid! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to fulfill the code-reuse destiny of OOP?
Yoda Master tells understands he you not, inheritance naked can be how, you clarify please asks he to. 2009/10/31 Magicloud Magiclouds magicloud.magiclo...@gmail.com: Somehow, I agree with you. I think inherit is not evil, the people use it wrong is. The problem here is, inherit is naked right now. So people could use it wrong. On Fri, Oct 30, 2009 at 7:42 PM, Yaakov Nemoy loupgaroubl...@gmail.com wrote: 2009/10/30 Peter Verswyvelen bugf...@gmail.com: The following is purely my own experience, I have no links to papers of clever people :) I think none of the inheritance techniques work perfectly. E.g. describing everything with OO interfaces (=a extensible record of function pointers) is also problematic IMHO, at least when you have side effects. The problem with an interface (with side effects) is that people using the interface tend to depend on the side effects that a particular implementation of that interface performs. So in order to describe the contract for implementers of an interface, one often has to go into great detail. Also in Haskell it is required that an implementers follows the contract when implementing a type class, e.g. when writing a monad, you must make sure it follows the monad laws. But at least in Haskell, this can be proven, while in OO, one has to hope that the side effects of an implementation won't cause weird behavior elsewhere. In practice, this seems to work, most of the time :) The evolution of industrial OO the way I see it, is strange. You start with assembler, in which it is obvious to extend records. Then comes C, which makes extending records hard to do without casting and macros. Then C++, which offers insane ways of extending them (virtual base classes, multiple inheritance, mixins using templates, ...). Then to make software components more loosely coupled and maintainable, Corba COM enters the picture, and you only use interfaces to communicate with other objects. Of course COM uses reference counting, so reusable components is actually just an illusion; in order to avoid memory leaks, you need to know how objects are connected, which depends on the implementation... In the meantime Java becomes a succes. Java is basically back to basics: it tries to address some of the flaws of complicated OO, has garbage collection, promises multi-platform caps, and it is very easy to understand, so people embrace it. Then C# comes along, which initially is almost the same as Java, except is has closures, but it evolves towards a functional language with side effects (even Haskell's FRP will be available in .NET 4.0, with the Rx framework!). Then to manage large and complicated software, things like dependency injection and inversion of control are introduced, and... we're basically back to COM in a sense, but now with garbage collection. So I have the impression that OO is running in circles, and every iteration tries to pick up some goodies of the previous one, but where will it end? Luckily humans seem to have the ability to get things done, whatever primitive or flawed tools we get. I guess the brain itself it the best programming language ;) Looking at this from a feedback circuit perspective, it seems like that industrial programming is just swinging back and forth between two extremes. It appears that at every step someone runs into the limitations of doing things one way and finds a way to orthogonally combine other designs together. For example, there's been alot of work on implementing other languages on top of Java, such as Jython, so different programming methods can be mixed into enterprise Java code. It all swings back and forth because more than one design and paradigm is needed and no single language can really support it all at once. -Yaakov Nemoy ___ 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 -- Eugene Kirpichov Web IR developer, market.yandex.ru ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to fulfill the code-reuse destiny of OOP?
Tom Davie tom.da...@gmail.com writes: On 10/31/09, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: After all, I never think OO as an oppsite way to all other things. The idea is so general that if you say I cannot use it in Haskell at all, that would make me feel weird. The only difference between languages is, some are easy to be in OO style, some are not. Wow, someone drank the cool aid! Doing OO-style programming in Haskell is difficult and unnatural, it's true (although technically speaking it is possible). That said, nobody's yet to present a convincing argument to me why Java gets a free pass for lacking closures and typeclasses. G. -- Gregory Collins g...@gregorycollins.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to fulfill the code-reuse destiny of OOP?
Gregory Collins wrote: Tom Davie tom.da...@gmail.com writes: On 10/31/09, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: After all, I never think OO as an oppsite way to all other things. The idea is so general that if you say I cannot use it in Haskell at all, that would make me feel weird. The only difference between languages is, some are easy to be in OO style, some are not. Wow, someone drank the cool aid! Doing OO-style programming in Haskell is difficult and unnatural, it's true (although technically speaking it is possible). That said, nobody's yet to present a convincing argument to me why Java gets a free pass for lacking closures and typeclasses. G. Because most programmers have never heard of closures and typeclasses, and thus have no idea how useful they are? :-( BTW using existential types in Haskell you can mimic OO to a pretty decent degree, at least as far as interfaces are concerned. Mike ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to fulfill the code-reuse destiny of OOP?
On Sun, Nov 1, 2009 at 2:00 AM, Michael Vanier mvanie...@gmail.com wrote: Gregory Collins wrote: Tom Davie tom.da...@gmail.com writes: On 10/31/09, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: After all, I never think OO as an oppsite way to all other things. The idea is so general that if you say I cannot use it in Haskell at all, that would make me feel weird. The only difference between languages is, some are easy to be in OO style, some are not. Wow, someone drank the cool aid! Doing OO-style programming in Haskell is difficult and unnatural, it's true (although technically speaking it is possible). That said, nobody's yet to present a convincing argument to me why Java gets a free pass for lacking closures and typeclasses. G. Because most programmers have never heard of closures and typeclasses, and thus have no idea how useful they are? :-( BTW using existential types in Haskell you can mimic OO to a pretty decent degree, at least as far as interfaces are concerned. I kind of wish we had some convenience notation for doing value-based dispatch like that Something like foo :: [ Show ] - String foo xs = concatMap show xs foo [ 5, True, 1.3 ] 5True1.3 (where wrapping a class up in angle brackets makes it into an existentially qualified wrapper, which is instantiated in the class itself -- maybe we need explicit conversion from e.g. Int to Show though...) You don't need it very often, but I wonder if that's because there genuinely isn't a need, or if you tend to avoid writing code in ways which would need it (ask a Java programmer, and they'll probably tell you that the need for type classes and closures don't come up very often - which is clearly untrue for a Haskell programmer). -- Sebastian Sylvan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to fulfill the code-reuse destiny of OOP?
On 30/10/09 05:32, Rogan Creswick wrote:
On Thu, Oct 29, 2009 at 6:54 PM, Magicloud Magiclouds
magicloud.magiclo...@gmail.com wrote:
My concern here is about the data member inheriting. In OOP, when I
inherit a class, I also got the members of it. But in haskell, how to
inherit a data?
[..]
The point of that whole rant is that extending data-bearing classes isn't
necessarily a good idea, so before trying to find a way to do it with
haskell, it may be better to just encapsulate another data type, which is
trivial:
data InnerThing = A | B | C
data OuterThing = Outer { innerThing :: InnerThing, otherField :: Int }
IIRC James Gosling once said that if he were to design Java today he would
leave out classes. I suppose partly due to many of the issues with data
inheritance.
/M
--
Magnus Therning(OpenPGP: 0xAB4DFBA4)
magnus＠therning．org Jabber: magnus＠therning．org
http://therning.org/magnus identi.ca|twitter: magthe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to fulfill the code-reuse destiny of OOP?
Magnus Therning wrote: IIRC James Gosling once said that if he were to design Java today he would leave out classes. I suppose partly due to many of the issues with data inheritance. This sounds interesting. Can you link us to an article, please? Thanks, Martijn. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to fulfill the code-reuse destiny of OOP?
On this subject, I think, any content inherit would lead to trouble somehow. But is that the reason that we should totally cut them loose? I mean the way of programming developing is easier making (writing), easier maintaining. In fact, I think this is a fork in front of me: Before any new thoughts/ideas of programming theroy came out, I have to choose between much less code (and in this case, better organized code/object structure. I mean the code level, not the bunch of documents come along.) and easier maintenance. Of course, I would be very glad if we could have better solution. On Fri, Oct 30, 2009 at 3:46 PM, Martijn van Steenbergen mart...@van.steenbergen.nl wrote: Magnus Therning wrote: IIRC James Gosling once said that if he were to design Java today he would leave out classes. I suppose partly due to many of the issues with data inheritance. This sounds interesting. Can you link us to an article, please? Thanks, Martijn. ___ 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] How to fulfill the code-reuse destiny of OOP?
2009/10/30 Martijn van Steenbergen mart...@van.steenbergen.nl: Magnus Therning wrote: IIRC James Gosling once said that if he were to design Java today he would leave out classes. I suppose partly due to many of the issues with data inheritance. This sounds interesting. Can you link us to an article, please? Thanks, Martijn. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe http://peter.michaux.ca/articles/transitioning-from-java-classes-to-javascript-prototypes (Under Second Tactic) -- Deniz Dogan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to fulfill the code-reuse destiny of OOP?
On Fri, Oct 30, 2009 at 7:46 AM, Martijn van Steenbergen mart...@van.steenbergen.nl wrote: Magnus Therning wrote: IIRC James Gosling once said that if he were to design Java today he would leave out classes. I suppose partly due to many of the issues with data inheritance. This sounds interesting. Can you link us to an article, please? I actually managed to find it again :-) http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html It seems I was wrong in my assumption about data inheritance, implementation inheritance is just as evil. /M -- Magnus Therning(OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to fulfill the code-reuse destiny of OOP?
Magnus == Magnus Therning mag...@therning.org writes: Magnus It seems I was wrong in my assumption about data Magnus inheritance, implementation inheritance is just as Magnus evil. Both are fine. -- Colin Adams Preston Lancashire ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to fulfill the code-reuse destiny of OOP?
The following is purely my own experience, I have no links to papers of clever people :) I think none of the inheritance techniques work perfectly. E.g. describing everything with OO interfaces (=a extensible record of function pointers) is also problematic IMHO, at least when you have side effects. The problem with an interface (with side effects) is that people using the interface tend to depend on the side effects that a particular implementation of that interface performs. So in order to describe the contract for implementers of an interface, one often has to go into great detail. Also in Haskell it is required that an implementers follows the contract when implementing a type class, e.g. when writing a monad, you must make sure it follows the monad laws. But at least in Haskell, this can be proven, while in OO, one has to hope that the side effects of an implementation won't cause weird behavior elsewhere. In practice, this seems to work, most of the time :) The evolution of industrial OO the way I see it, is strange. You start with assembler, in which it is obvious to extend records. Then comes C, which makes extending records hard to do without casting and macros. Then C++, which offers insane ways of extending them (virtual base classes, multiple inheritance, mixins using templates, ...). Then to make software components more loosely coupled and maintainable, Corba COM enters the picture, and you only use interfaces to communicate with other objects. Of course COM uses reference counting, so reusable components is actually just an illusion; in order to avoid memory leaks, you need to know how objects are connected, which depends on the implementation... In the meantime Java becomes a succes. Java is basically back to basics: it tries to address some of the flaws of complicated OO, has garbage collection, promises multi-platform caps, and it is very easy to understand, so people embrace it. Then C# comes along, which initially is almost the same as Java, except is has closures, but it evolves towards a functional language with side effects (even Haskell's FRP will be available in .NET 4.0, with the Rx framework!). Then to manage large and complicated software, things like dependency injection and inversion of control are introduced, and... we're basically back to COM in a sense, but now with garbage collection. So I have the impression that OO is running in circles, and every iteration tries to pick up some goodies of the previous one, but where will it end? Luckily humans seem to have the ability to get things done, whatever primitive or flawed tools we get. I guess the brain itself it the best programming language ;) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to fulfill the code-reuse destiny of OOP?
2009/10/30 Peter Verswyvelen bugf...@gmail.com: The following is purely my own experience, I have no links to papers of clever people :) I think none of the inheritance techniques work perfectly. E.g. describing everything with OO interfaces (=a extensible record of function pointers) is also problematic IMHO, at least when you have side effects. The problem with an interface (with side effects) is that people using the interface tend to depend on the side effects that a particular implementation of that interface performs. So in order to describe the contract for implementers of an interface, one often has to go into great detail. Also in Haskell it is required that an implementers follows the contract when implementing a type class, e.g. when writing a monad, you must make sure it follows the monad laws. But at least in Haskell, this can be proven, while in OO, one has to hope that the side effects of an implementation won't cause weird behavior elsewhere. In practice, this seems to work, most of the time :) The evolution of industrial OO the way I see it, is strange. You start with assembler, in which it is obvious to extend records. Then comes C, which makes extending records hard to do without casting and macros. Then C++, which offers insane ways of extending them (virtual base classes, multiple inheritance, mixins using templates, ...). Then to make software components more loosely coupled and maintainable, Corba COM enters the picture, and you only use interfaces to communicate with other objects. Of course COM uses reference counting, so reusable components is actually just an illusion; in order to avoid memory leaks, you need to know how objects are connected, which depends on the implementation... In the meantime Java becomes a succes. Java is basically back to basics: it tries to address some of the flaws of complicated OO, has garbage collection, promises multi-platform caps, and it is very easy to understand, so people embrace it. Then C# comes along, which initially is almost the same as Java, except is has closures, but it evolves towards a functional language with side effects (even Haskell's FRP will be available in .NET 4.0, with the Rx framework!). Then to manage large and complicated software, things like dependency injection and inversion of control are introduced, and... we're basically back to COM in a sense, but now with garbage collection. So I have the impression that OO is running in circles, and every iteration tries to pick up some goodies of the previous one, but where will it end? Luckily humans seem to have the ability to get things done, whatever primitive or flawed tools we get. I guess the brain itself it the best programming language ;) Looking at this from a feedback circuit perspective, it seems like that industrial programming is just swinging back and forth between two extremes. It appears that at every step someone runs into the limitations of doing things one way and finds a way to orthogonally combine other designs together. For example, there's been alot of work on implementing other languages on top of Java, such as Jython, so different programming methods can be mixed into enterprise Java code. It all swings back and forth because more than one design and paradigm is needed and no single language can really support it all at once. -Yaakov Nemoy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to fulfill the code-reuse destiny of OOP?
Rogan Creswick wrote: On Thu, Oct 29, 2009 at 6:54 PM, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: My concern here is about the data member inheriting. In OOP, when I inherit a class, I also got the members of it. But in haskell, how to inherit a data? In my experience (almost entirely with Java), it is usually a bad idea to inherit from a class in order to reuse data storage that the parent class provides. Encapsulation (or a decorator, if you prefer) is often a safer choice. ...otherwise phrased in OO circles as people over-use inheritance and under-use collaboration. That said, I'm sure I won't be the first person here to say that generally, if you want to write a Haskell program, you should forget all about OOP and figure out how to structure it to make the best use of Haskell. It's a very different approach to program construction, and it requires a different way of thinking. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to fulfill the code-reuse destiny of OOP?
On Thu, Oct 29, 2009 at 6:54 PM, Magicloud Magiclouds
magicloud.magiclo...@gmail.com wrote:
My concern here is about the data member inheriting. In OOP, when I
inherit a class, I also got the members of it. But in haskell, how to
inherit a data?
In my experience (almost entirely with Java), it is usually a bad idea
to inherit from a class in order to reuse data storage that the parent
class provides. Encapsulation (or a decorator, if you prefer) is
often a safer choice. If you really do need to meet the interface
provided by the parent class, while adding functionality (*and* you
can't just implement that interface independently of extending the
parent class), then it's often possible to still use a decorator, and
provide limited visibility accessors to the encapsulated field you
need (say, to pass into some unmodifiable legacy API). When you get
down to it, it's extremely hard to design a full-fledged class so that
extending it actually makes sense, and can be done in a useful and
safe manner. Extending concrete classes also brings along some
non-trivial maintenance headaches as well, since you now need to be
aware of changes to (some of) the non-public APIs when libraries are
upgraded, etc... it's a mess. This is a large part of why the
majority of the concrete classes in the Google Collections library are
final -- the limited benefit of extensibility isn't worth the design
and maintenance.
The point of that whole rant is that extending data-bearing classes
isn't necessarily a good idea, so before trying to find a way to do it
with haskell, it may be better to just encapsulate another data type,
which is trivial:
data InnerThing = A | B | C
data OuterThing = Outer { innerThing :: InnerThing, otherField :: Int }
--Rogan
--
竹密岂妨流水过
山高哪阻野云飞
___
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
