Hi,
I think when people talk about OOP, especially the inheriting, their focus mainly is on functions (methods). 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"? -- 竹密岂妨流水过 山高哪阻野云飞 _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
On Thu, Oct 29, 2009 at 6:54 PM, Magicloud Magiclouds
<[hidden email]> 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 > [hidden email] > http://www.haskell.org/mailman/listinfo/haskell-cafe > _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
On 30/10/09 05:32, Rogan Creswick wrote:
> On Thu, Oct 29, 2009 at 6:54 PM, Magicloud Magiclouds > <[hidden email]> 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 [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
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 [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Magicloud Magiclouds
Magicloud Magiclouds wrote > In OOP, when I inherit a class, I also got the members of it. > But in haskell, how to inherit a "data"? Although any OOP system has by definition, objects, not all of them have classes. The best example of a classless (also called 1-level, or prototype-based) OO system is Self, which is still alive. An object is essentially a record of data members. An extended object (an object of an extended class, for a class-based OOP) is an extended record. They could be quite convenient: we can add a new field to an existing record without re-writing the complete declaration and re-using lots of the functions that dealt with the old records. The old code would just work on extended records, ignoring the added field. (I am simplifying a bit.) Lots has been written about extensible records in Haskell; some techniques (such as parameterizing a record type by a tail) have been rediscovered several times. Still a good survey of many various ways to implement extensible records in Haskell is Section 3 of http://homepages.cwi.nl/~ralf/OOHaskell/paper.pdf It is long, as everything else in that paper. _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Martijn van Steenbergen-2
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 <[hidden email]> 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 > [hidden email] > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- 竹密岂妨流水过 山高哪阻野云飞 _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Martijn van Steenbergen-2
2009/10/30 Martijn van Steenbergen <[hidden email]>:
> 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 > [hidden email] > 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 [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Martijn van Steenbergen-2
On Fri, Oct 30, 2009 at 7:46 AM, Martijn van Steenbergen
<[hidden email]> 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 [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
>>>>> "Magnus" == Magnus Therning <[hidden email]> 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 [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
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 [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
2009/10/30 Peter Verswyvelen <[hidden email]>:
> 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 [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Rogan Creswick
Rogan Creswick wrote:
> On Thu, Oct 29, 2009 at 6:54 PM, Magicloud Magiclouds > <[hidden email]> 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 [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by loupgaroublond@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 <[hidden email]> wrote: > 2009/10/30 Peter Verswyvelen <[hidden email]>: >> 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 > [hidden email] > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- 竹密岂妨流水过 山高哪阻野云飞 _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Andrew Coppin
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 <[hidden email]>: > Rogan Creswick wrote: >> On Thu, Oct 29, 2009 at 6:54 PM, Magicloud Magiclouds >> <[hidden email]> 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 > [hidden email] > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- 竹密岂妨流水过 山高哪阻野云飞 _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
On 10/31/09, Magicloud Magiclouds <[hidden email]> 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 [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Magicloud Magiclouds
Yoda Master tells understands he you not, inheritance naked can be
how, you clarify please asks he to. 2009/10/31 Magicloud Magiclouds <[hidden email]>: > 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 <[hidden email]> wrote: >> 2009/10/30 Peter Verswyvelen <[hidden email]>: >>> 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 >> [hidden email] >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > > > -- > 竹密岂妨流水过 > 山高哪阻野云飞 > _______________________________________________ > Haskell-Cafe mailing list > [hidden email] > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Eugene Kirpichov Web IR developer, market.yandex.ru _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Thomas Davie
Tom Davie <[hidden email]> writes:
> On 10/31/09, Magicloud Magiclouds <[hidden email]> 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 <[hidden email]> _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
Gregory Collins wrote:
> Tom Davie <[hidden email]> writes: > > >> On 10/31/09, Magicloud Magiclouds <[hidden email]> 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. > 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 [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
On Sun, Nov 1, 2009 at 2:00 AM, Michael Vanier <[hidden email]> wrote:
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" 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 [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
In reply to this post by Gregory Collins-3
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 <[hidden email]> wrote: > Tom Davie <[hidden email]> writes: > >> On 10/31/09, Magicloud Magiclouds <[hidden email]> 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 <[hidden email]> > -- 竹密岂妨流水过 山高哪阻野云飞 _______________________________________________ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe |
Free forum by Nabble | Edit this page |