|
|
12
|
|
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.pdfIt 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
|
|
|
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
|
|
|
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
|
|
|
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
|
|
|
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.
>
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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
|
|
|
On Sun, Nov 1, 2009 at 2:00 AM, Michael Vanier <[hidden email]> wrote:
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.
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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
|
|
|
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
|
12
|
Locked
