5 ms·

I'm not claiming typeclasses are classes, but more like modules and that modules achieve at least some of OO. Entity-like identity is a notably more difficult t

by tel 12y ago

I'm not claiming typeclasses are classes, but more like modules and that modules achieve at least some of OO. Entity-like identity is a notably more difficult thing to pull off, but still is easily embedded in IO or ST. I'm not saying it's a complete OO implementation, but instead that it's not so far as to be completely unconfusable, though it might be hard to, say, do Smalltalk-in-Haskell.

seanmcdirmid 12y ago
Typeclasses don't give you any specific to OO: they are abstractions over values and that's about it. You wouldn't be able to emulate an existing OO system in Haskell, and anyways, it wouldn't bring you closer to "talking about" and "thinking in terms of" objects. My point that OOP is essentially "thinking in terms of named objects" whereas most of what Haskell focuses on is "expressing math by composing anonymous values." I believe this starting from a design perspective is the best way to highlight the real differences between OOP and pure FP.
- tel 12y ago
  I disagree, but I think we'd have to go to definitions to make headway on this conversation, so I'll back out. As final thoughts: while type classes give abstraction over values, (a) those values encompass HKTs so they can also be effectual in various ways and (b) universally quantified bounded types are a basically final algebras and codata goes a long way toward modeling objects. Between those two I think you can give OO in Haskell a run.
  - seanmcdirmid 12y ago
    We then have to argue about what objects really are, and there isn't much consensus :) I don't think my design-oriented linguistic definition is very popular, but it contrasts nicely with pure functional programming; otherwise there is a lot of overlap and I don't think we can say anything very interesting about their differences.
    - tel 12y ago
      Yep, exactly :) I don't find definitional wars interesting, and I'd, in the stream of everyday things, be very sympathetic to "OO and FP are different because they were built from different POVs". The only reason I am being a stickler is that I'm pretty interested in the idea that both FP and OO have a representation in type theory/category theory/logic and thus can be put into common representation. Haskell definitely isn't the best OO language, but if you squint hard enough you can see OO in it much like you can see FP in C's function pointers: painfully. Seeing FP in C helps you examine the implementation challenges of FP. Seeing OO in Haskell helps you pick apart the different semantic pieces which build to form OO.
      - seanmcdirmid 12y ago
        I would go farther and say Haskell is the only popular general purpose language that can get away without exposing programmers to object-like abstractions in the general case. Of course, these languages are general enough that you could probably shove whatever paradigm you wanted on top of them, but they do optimize for a particular kind of paradigm. A type theorist's definition of OO will be quite different from a generalist's. For type theory, various kinds of polymorphisms mostly overlap between paradigms (e.g. generics and structural subtyping are useful in OOP), but nominal typing is both commonly associated with OOP and relatively useless in FP languages to be a distinguishing feature. This also dovetails with my named-oriented definition of OOP: objects have identity, but their types have identity also. If you come at it from the FP perspective, identity for objects AND types aren't very desirable...there are no meaningful names in math!
        tel 12y ago
        That's an interesting claim—that Haskell doesn't need object-like abstractions. I think it's really worth examining. I've said in the past the Haskell (and the ML-family) is possibly the only language which takes seriously initial data. That said, it still needs jerry-rigged abstract types to be efficient and I'm happy calling codata "object-like". So really what I believe is that Haskell does a better job of being OO-FP than Scala does. I think there's still a happier medium between the two, though. I'm also really eager to explore the type theorist's definition of OO in order to tease and bend the generalists definition. I'm not sure I completely agree about the idea of names that you outline, though. Existential types (and their dualized universal presentation) present unique types which could be named. State-transformer style (and the state-like monads) present a notion of identity-as-entity. Again from the perspective of Haskell being a stab in the direction of a type theorists FP-OO language I find all of these features really interesting.

by tel 12y ago

seanmcdirmid 12y ago

Typeclasses don't give you any specific to OO: they are abstractions over values and that's about it. You wouldn't be able to emulate an existing OO system in Haskell, and anyways, it wouldn't bring you closer to "talking about" and "thinking in terms of" objects. My point that OOP is essentially "thinking in terms of named objects" whereas most of what Haskell focuses on is "expressing math by composing anonymous values." I believe this starting from a design perspective is the best way to highlight the real differences between OOP and pure FP.

tel 12y ago
I disagree, but I think we'd have to go to definitions to make headway on this conversation, so I'll back out. As final thoughts: while type classes give abstraction over values, (a) those values encompass HKTs so they can also be effectual in various ways and (b) universally quantified bounded types are a basically final algebras and codata goes a long way toward modeling objects. Between those two I think you can give OO in Haskell a run.
- seanmcdirmid 12y ago
  We then have to argue about what objects really are, and there isn't much consensus :) I don't think my design-oriented linguistic definition is very popular, but it contrasts nicely with pure functional programming; otherwise there is a lot of overlap and I don't think we can say anything very interesting about their differences.
  - tel 12y ago
    Yep, exactly :) I don't find definitional wars interesting, and I'd, in the stream of everyday things, be very sympathetic to "OO and FP are different because they were built from different POVs". The only reason I am being a stickler is that I'm pretty interested in the idea that both FP and OO have a representation in type theory/category theory/logic and thus can be put into common representation. Haskell definitely isn't the best OO language, but if you squint hard enough you can see OO in it much like you can see FP in C's function pointers: painfully. Seeing FP in C helps you examine the implementation challenges of FP. Seeing OO in Haskell helps you pick apart the different semantic pieces which build to form OO.
    - seanmcdirmid 12y ago
      I would go farther and say Haskell is the only popular general purpose language that can get away without exposing programmers to object-like abstractions in the general case. Of course, these languages are general enough that you could probably shove whatever paradigm you wanted on top of them, but they do optimize for a particular kind of paradigm. A type theorist's definition of OO will be quite different from a generalist's. For type theory, various kinds of polymorphisms mostly overlap between paradigms (e.g. generics and structural subtyping are useful in OOP), but nominal typing is both commonly associated with OOP and relatively useless in FP languages to be a distinguishing feature. This also dovetails with my named-oriented definition of OOP: objects have identity, but their types have identity also. If you come at it from the FP perspective, identity for objects AND types aren't very desirable...there are no meaningful names in math!
      - tel 12y ago
        That's an interesting claim—that Haskell doesn't need object-like abstractions. I think it's really worth examining. I've said in the past the Haskell (and the ML-family) is possibly the only language which takes seriously initial data. That said, it still needs jerry-rigged abstract types to be efficient and I'm happy calling codata "object-like". So really what I believe is that Haskell does a better job of being OO-FP than Scala does. I think there's still a happier medium between the two, though. I'm also really eager to explore the type theorist's definition of OO in order to tease and bend the generalists definition. I'm not sure I completely agree about the idea of names that you outline, though. Existential types (and their dualized universal presentation) present unique types which could be named. State-transformer style (and the state-like monads) present a notion of identity-as-entity. Again from the perspective of Haskell being a stab in the direction of a type theorists FP-OO language I find all of these features really interesting.